bug#22883: Authenticating a Git checkout

[ng0 <ng0@n0.is>]

[-- Attachment #1: Type: text/plain, Size: 5434 bytes --]

On 2016-06-04(01:17:53+0200), Ludovic Courtès wrote:
> Hi!
>
> Mike Gerwitz <mtg@gnu.org> skribis:
>
> > On Fri, Jun 03, 2016 at 18:12:47 +0200, Ludovic Courtès wrote:
> >> First, ‘git pull’ doesn’t do it for you, you have to pass ‘--verify’ and
> >> there’s no way to set it globally.
> >
> > That's unfortunate.  Does your checkout scenario include a fresh clone?
> > If so, a pull flag wouldn't help there.
> >
> > Leo mentioned a patch; I don't think that'd be too difficult (looking at
> > other config options in builtin/pull.c), and would be a great idea.  It
> > appears to pass it off to merge.c; that might be a useful area to verify
> > signatures as well (pull being a fetch && merge/rebase), in a general
> > sense.
>
> Yeah, it wouldn’t be too hard to add to Git proper, I think, but we
> can even live without it initially.
>
> >> Second, even if it did, it would be a shallow check: as Mike notes in
> >> <https://mikegerwitz.com/papers/git-horror-story> with the ‘signchk’
> >> script, you actually have to traverse the whole commit history and
> >> authenticate them one by one.  But that’s OK, it runs in presumably less
> >> than a minute on a repo the size of Guix’s, and we could also stop at
> >> signed tags to avoid redundant checks.
> >
> > Practically speaking, that's probably fine, though note that a signed
> > tag is just a signed hash of the commit it points to (with some
> > metadata), so you're trusting the integrity of SHA-1 and nothing
> > more.
> >
> > With that said, the tag points to what will hopefully be a signed
> > commit, so if you verify the signature of the tag _and_ that commit,
> > that'd be even better.  Git's use of SHA-1 makes cryptographic
> > assurances difficult/awkward.
> >
> > An occasional traversal of the entire DAG by, say, a CI script would
> > provide some pretty good confidence.  I wouldn't say it's necessary for
> > every pull.
>
> Agreed.
>
> >> Third, as I wrote before¹, relying on the OpenPGP web of trust to
> >> determine whether a commit is “valid” is inappropriate: what we want to
> >> know is whether a commit was made by an authorized person, not whether
> >> it was made by someone who happens to have an OpenPGP key directly or
> >> indirectly certified.
> >
> > If you want to keep with the convenience of the web of trust, then you
> > can have a keyring trusting only the appropriate Guix
> > hackers.  Otherwise, I agree.
>
> Oh right, we could do something like:
>
>   gpgv --keyring guix-developers.keyring foo
>
> (I realize GSRC uses this idiom already when authenticating source
> tarballs:
> <http://bzr.savannah.gnu.org/lh/gsrc/trunk/annotate/head:/gar.lib.mk#L217>.)
>
> >> Fourth, there’s inversion of control: ‘git log’ & co. call out to ‘gpg’,
> >> so if we want to do something different than just ‘gpg --verify’, we
> >> have to put some other ‘gpg’ script in $PATH.  Blech.
> >
> > What types of things are you considering?
>
> Something as simple as this:
>
> --8<---------------cut here---------------start------------->8---
> $ git config gpg.program 'gpgv --keyring /dev/null'
> $ git verify-commit HEAD
> error: cannot run gpgv --keyring /dev/null: No such file or directory
> error: could not run gpg.
> --8<---------------cut here---------------end--------------->8---
>
> :-/
>
> >> Seventh, even if it did, what would we do with the raw ASCII-armored
> >> OpenPGP signature?  GPG and GPGME are waaaay too high-level, so we’d
> >> need to implement OpenPGP (in Guile, maybe based on the OpenPGP library
> >> in Bigloo?)?!
> >
> > What about gpgme/libgcrypt?[*]
>
> I believe, but haven’t checked carefully, that GPGME is too high-level;
> libgcrypt is too low-level (it does not implement OpenPGP.)
>
> > [*]: I was actually considering writing an FFI for libgcrypt (if it
> > doesn't exist already), but it made me uncomfortable without studying
> > whether Guile can make assurances that pointer-referenced data in
> > "secure" memory will never be copied anywhere else.  I was going to
> > bring it up in the near future on the guile mailing list after I did
> > some research myself; no need to derail the discussion here.
>
> We have incomplete libgcrypt bindings:
>
>   http://git.savannah.gnu.org/cgit/guix.git/tree/guix/pk-crypto.scm
>
> This is used for the authentication of substitutes:
>
>   https://www.gnu.org/software/guix/manual/html_node/Substitutes.html
>
> Thanks for your feedback!
>
> Ludo’.
>
>
>

Aside from other problems,
Couldn't we create a separate gpg(-1,-2) package which installs its own GPG_HOME_DIR
and keyring (gpg2 or gpg1 must be present for that, for future purposes a
gpg2 would be best I think)?

One example:
https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Features#Validated_Portage_tree_snapshots

I know this isn't similar to what we want to do, but it might serve as an example.
The method described in the link downloads an auto-signed tarball snapshot of the
portage directory via webrsync. The keys are also visible on the wiki and it is up
to users to put trust in them, as this method is considered optional.
The source used for this is https://gitweb.gentoo.org/proj/gentoo-keys.git/tree/README.md

Maybe this helps a bit.

--
♥Ⓐ ng0
4096R/13212A27975AF07677A29F7002A296150C201823

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]