Date: Mon, 7 Oct 2019 21:36:48 +1030 From: "O'Connor, Daniel" <darius@dons.net.au> To: grarpamp <grarpamp@gmail.com> Cc: freebsd-chat@freebsd.org Subject: Re: Git/Mtn for FreeBSD, PGP WoT Sigs, Merkel Hash Tree Based Message-ID: <A66796A7-9CDE-4D36-8C1D-5B755A993DBA@dons.net.au> In-Reply-To: <CAD2Ti29R=p2g%2B=cAVqG3Un6OW4ix0JqzB5UkCkgU-cDeJgi-Vw@mail.gmail.com> References: <CAD2Ti2_p0Yq4VBGMnzxfJABaV94D4a0vsVMuAGgQn6Cm06p%2B_w@mail.gmail.com> <CAD2Ti28X=VMM=oHzFWBJ8b73dT9T4Wi-5ytrBSKBcj4X3Wfn7Q@mail.gmail.com> <CADWvR2hTvuKnjANQjt0QbXLbYTmjc1PuFW20qWVweyuXZsVo5g@mail.gmail.com> <CAD2Ti29R=p2g%2B=cAVqG3Un6OW4ix0JqzB5UkCkgU-cDeJgi-Vw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <grarpamp@gmail.com> wrote: >=20 > On 10/4/19, Igor Mozolevsky <igor@hybrid-lab.co.uk> wrote: >> On Fri, 20 Sep 2019 at 22:01, grarpamp <grarpamp@gmail.com> 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 >> <snip> >>=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A66796A7-9CDE-4D36-8C1D-5B755A993DBA>