[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22883: Authenticating a Git checkout
From: |
Ludovic Courtès |
Subject: |
bug#22883: Authenticating a Git checkout |
Date: |
Sat, 04 Jun 2016 13:17:53 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
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’.