Skip site navigation (1)Skip section navigation (2)
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>