From owner-freebsd-chat@freebsd.org Mon Oct 7 11:31:36 2019 Return-Path: Delivered-To: freebsd-chat@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4680812BE35 for ; Mon, 7 Oct 2019 11:31:36 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by mx1.freebsd.org (Postfix) with ESMTP id 46myx06BTYz3PLq for ; Mon, 7 Oct 2019 11:31:32 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ppp14-2-104-13.adl-apt-pir-bras32.tpg.internode.on.net (HELO midget.dons.net.au) ([14.2.104.13]) by ipmail06.adl6.internode.on.net with ESMTP; 07 Oct 2019 21:56:19 +1030 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id x97BPw7A079336 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 7 Oct 2019 21:56:13 +1030 (ACDT) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id x97B6r44065212 for ; Mon, 7 Oct 2019 21:36:53 +1030 (ACDT) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f X-MIMEDefang-Relay-be813b1f1da6d6b27d681222cb70cc4f5b642383: 10.0.2.38 Received: from havok.dons.net.au (Havok.dons.net.au [10.0.2.38]) by ns.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id x97B6mxE065208; Mon, 07 Oct 2019 21:36:53 +0930 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Git/Mtn for FreeBSD, PGP WoT Sigs, Merkel Hash Tree Based From: "O'Connor, Daniel" In-Reply-To: Date: Mon, 7 Oct 2019 21:36:48 +1030 Cc: freebsd-chat@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: grarpamp X-Mailer: Apple Mail (2.3445.104.11) X-Spam-Score: -1 () No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 46myx06BTYz3PLq X-Spamd-Bar: ++++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of darius@dons.net.au has no SPF policy when checking 150.101.137.145) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [6.11 / 15.00]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; RWL_MAILSPIKE_GOOD(0.00)[145.137.101.150.rep.mailspike.net : 127.0.0.18]; HAS_XAW(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4739, ipnet:150.101.0.0/16, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[145.137.101.150.list.dnswl.org : 127.0.5.1]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-chat@freebsd.org]; DMARC_NA(0.00)[dons.net.au]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.999,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.99)[0.991,0]; R_SPF_NA(0.00)[]; GREYLIST(0.00)[pass,body]; IP_SCORE(2.72)[ip: (9.80), ipnet: 150.101.0.0/16(2.51), asn: 4739(1.31), country: AU(0.01)] X-Spam: Yes X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 11:31:36 -0000 Please move this thread to -chat where it belongs rather than spamming = 4(!!!) mailing lists with it. Thanks. PS also please don't CC me on it. > On 7 Oct 2019, at 18:13, grarpamp wrote: >=20 > On 10/4/19, Igor Mozolevsky wrote: >> On Fri, 20 Sep 2019 at 22:01, grarpamp wrote: >>>=20 >>> For consideration... >>> = https://lists.freebsd.org/pipermail/freebsd-security/2019-September/010099= .html >>>=20 >>> SVN really may not offer much in the way of native >>> internal self authenticating repo to cryptographic levels >>> of security against bitrot, transit corruption and repo ops, >>> external physical editing, have much signing options, etc. >>> Similar to blockchain and ZFS hash merkle-ization, >>> signing the repo init and later points tags commits, >>> along with full verification toolset, is useful function. >>=20 >>=20 >> >>=20 >> Isn't UNIX(TM) philosophy that a program should do one thing and do = it >> well? Just because people can't be bothered to learn to use multiple >> tools to do *multiple* tasks on the same dataset, is not a reason, = let >> alone "the reason," to increase any program complexity to orders of >> N^M^K^L so that one "foo checkout" does all the things one wants! >=20 > Was r353001 cryptosigned so people can verify it with > a second standalone multiple tool called "PGP", after the > first standalone multiple tool called "repo checkout"? > Was it crypto chained back into a crypto history so they could > treat it as a secure diff (the function of a third standalone multiple > tool "diff a b") instead of as entirely separate (and space wasting > set of) unlinked independant assertions / issuances as to a state? > How much time does that take over time each time vs > perhaps loading signed set of keys into repo client config. > Is LOGO and tape better because less complex tool than C and disk. >=20 >> When crypto invalidates a repo, how would it be different >> from seeing non ASCII characters in plain ASCII files, or sudden >> refusal to compile >> one way or another you'd still need to restore >> from BACKUP >=20 > Backup is separate, and indeed a fine practice to help > keep for when all sorts of horrors can happen. >=20 >> crypto IS NOT a substitute for good data keeping >> practices. >=20 > Who said that it was. However it can be a wrapper of > proof / certification / detection / assurance / integrity / test > over them... a good thing to have there, as opposed to nothing. >=20 >> Also, what empirical data do you have for repo bitrot/transit >> corruption that is NOT caught by underlying media? >=20 > Why are people even bothering to sha-2 or sign iso's, or > reproducible builds? There is some integrity function there. > Else just quit doing those too then. >=20 > Many sources people can find, just search... > = https://www.zdnet.com/article/dram-error-rates-nightmare-on-dimm-street/ > http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf > http://www.cs.toronto.edu/~bianca/papers/ASPLOS2012.pdf > https://www.jedec.org/sites/default/files/Barbara_A_summary.pdf > https://en.wikipedia.org/wiki/Data_degradation > https://en.wikipedia.org/wiki/ECC_memory > https://en.wikipedia.org/wiki/Soft_error > Already have RowHammer too, who is researching DiskHammer? > Yes, there does need to be current baseline studies made > in 2020 across all of say Google, Amazon, Facebook global > datacenters... fiber, storage, ram, etc. It is surely not zero > errors otherwise passed. >=20 > Then note all the users who do not run any media, memory, > and cables capable of detecting and or correcting garbage. > And the claims or data, about "checksums / digests / hashes" > that fall short of at least 2^128 odds that strong > crypto based repositories can provide. Many do not, > and should not, accept less as sufficient standards. > What is the worth of your data and instructions producted > with some software from some repositories from some hops. > Though error is only part of entire possible subject, still however... > Lower some risks there too by raising some crypto bars. >=20 > Be sure to expand "external physical editiing" hinted > to include malicious, even by both local and remote > adversarial actors, and or those acting outside of > established practice. Some crypto repositories require > additionally compromise of committer and or distribution > private key to impart trust downstream, all of which leaves > nice audit, instead of just sneaking in a "vi foo.rcs" or binary > equivalent. >=20 > Cryptographic defense in depth, not prayer. >=20 >=20 > [Sorry not sure which is better mail list] > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum