Re: Git/Mtn for FreeBSD, PGP WoT Sigs, Merkel Hash Tree Based
Please move this thread to -chat where it belongs rather than spamming 4(!!!) mailing lists with it.
PS also please don't CC me on it.
> On 7 Oct 2019, at 18:13, grarpamp <[hidden email]> wrote:
> On 10/4/19, Igor Mozolevsky <[hidden email]> wrote:
>> On Fri, 20 Sep 2019 at 22:01, grarpamp <[hidden email]> 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.
>> 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
> 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
> Cryptographic defense in depth, not prayer.
> [Sorry not sure which is better mail list]
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[hidden email]"
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum