Hi! Mike Gerwitz 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 >> 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: .) >> 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’.