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