Date: Mon, 7 Oct 2019 03:43:06 -0400 From: grarpamp <grarpamp@gmail.com> To: freebsd-security@freebsd.org Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org, freebsd-current@freebsd.org Subject: Re: Git/Mtn for FreeBSD, PGP WoT Sigs, Merkel Hash Tree Based Message-ID: <CAD2Ti29R=p2g%2B=cAVqG3Un6OW4ix0JqzB5UkCkgU-cDeJgi-Vw@mail.gmail.com> In-Reply-To: <CADWvR2hTvuKnjANQjt0QbXLbYTmjc1PuFW20qWVweyuXZsVo5g@mail.gmail.com> References: <CAD2Ti2_p0Yq4VBGMnzxfJABaV94D4a0vsVMuAGgQn6Cm06p%2B_w@mail.gmail.com> <CAD2Ti28X=VMM=oHzFWBJ8b73dT9T4Wi-5ytrBSKBcj4X3Wfn7Q@mail.gmail.com> <CADWvR2hTvuKnjANQjt0QbXLbYTmjc1PuFW20qWVweyuXZsVo5g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >> >> For consideration... >> https://lists.freebsd.org/pipermail/freebsd-security/2019-September/010099.html >> >> 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. > > > <snip> > > 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! 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. > 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 Backup is separate, and indeed a fine practice to help keep for when all sorts of horrors can happen. > crypto IS NOT a substitute for good data keeping > practices. 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. > Also, what empirical data do you have for repo bitrot/transit > corruption that is NOT caught by underlying media? 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. 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. 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. 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. Cryptographic defense in depth, not prayer. [Sorry not sure which is better mail list]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAD2Ti29R=p2g%2B=cAVqG3Un6OW4ix0JqzB5UkCkgU-cDeJgi-Vw>