Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Sep 2019 23:02:29 -0000
From:      grarpamp <grarpamp@gmail.com>
To:        freebsd-security@freebsd.org
Cc:        freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org
Subject:   Git/Mtn for FreeBSD, PGP WoT Sigs, Merkel Hash Tree Based
Message-ID:  <CAD2Ti2_p0Yq4VBGMnzxfJABaV94D4a0vsVMuAGgQn6Cm06p%2B_w@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
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.

https://www.monotone.ca/
https://en.wikipedia.org/wiki/Monotone_(software)
https://git-scm.com/
https://en.wikipedia.org/wiki/Git

Maintaining the kernel's web of trust
https://lwn.net/Articles/798230/

Distributing kernel developer PGP keys via pgpkeys.git
https://lkml.org/lkml/2019/8/30/597

Signing patch flow
https://lwn.net/Articles/737093/

Compromised security happens
https://lwn.net/Articles/464233/

https://security.stackexchange.com/questions/67920/how-safe-are-signed-git-=
tags-only-as-safe-as-sha-1-or-somehow-safer
https://stackoverflow.com/questions/28792784/why-does-git-use-a-cryptograph=
ic-hash-function
http://fossil-scm.org/index.html/doc/trunk/www/hashpolicy.wiki
https://ericsink.com/vcbe/html/cryptographic_hashes.html
https://svn.haxx.se/dev/archive-2015-06/0052.shtml
http://git.661346.n2.nabble.com/Verifying-the-whole-repository-td1368311.ht=
ml
https://shattered.io/
https://www.youtube.com/watch?v=3DG8wQ88d85s4
https://en.wikipedia.org/wiki/Data_degradation
https://git-scm.com/docs/git-fsck
https://marc.info/?l=3Dgit&m=3D118143549107708
https://en.wikipedia.org/wiki/Comparison_of_version-control_software
https://en.wikipedia.org/wiki/Deterministic_compilation
https://www.monotone.ca/monotone.html#Trust-Evaluation-Hooks

How does one know their entire copy of repo obtained on
DVD, "mirror", or elsewhere cryptographically
matches the authoritative repo... that any commits
were actually signed off on... or that any reproducible
builds are even reproducing the main repo... etc...
cannot be done without secure crypto infrastructure at
the very core.

"User also knows that even if someone should break into the shared
hosting server and tamper with the database, they won=E2=80=99t be able to
inject malicious code into the project, because all revisions are signed
by the team members, and he has set his Trust Evaluation Hooks so
he doesn=E2=80=99t trust the server key for signing revisions.
In monotone, the important trust consideration is on the signed content,
rather than on the replication path by which that content arrived in your
database."


Note also CVS, which some BSD's still use (ahem: Open, Net),
is even worse than SVN with zero protection
at all in any component regarding this subject.

It really time to migrate repo tech to year 2020.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAD2Ti2_p0Yq4VBGMnzxfJABaV94D4a0vsVMuAGgQn6Cm06p%2B_w>