bug#22883: Authenticating a Git checkout

[ng0]

On 2016-06-04(12:45:16PM+0000), ng0 wrote:
> On 2016-06-04(01:17:53+0200), Ludovic Courtès wrote:
> > Hi!
> >
> > Mike Gerwitz <address@hidden> 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.
>


Adding to this what I just found:

http://www.tedunangst.com/flak/post/signify
https://github.com/aperezdc/signify

I am /not/ sure if this will be useful for what guix secure pull wants to 
achieve,
but maybe there's some inspiration to be found in the source.

--
♥Ⓐ ng0
For non-prism friendly talk find me on
psyced.org / loupsycedyglgamf.onion

signature.asc
Description: Digital signature