Git/Mtn for FreeBSD, PGP WoT Sigs, Merkel Hash Tree Based

grarpamp grarpamp at
Mon Oct 7 07:43:10 UTC 2019

On 10/4/19, Igor Mozolevsky <igor at> wrote:
> On Fri, 20 Sep 2019 at 22:01, grarpamp <grarpamp at> wrote:
>> For consideration...
>> 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...
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]

More information about the freebsd-questions mailing list