Ludo:
On Fri, Jun 03, 2016 at 18:12:47 +0200, Ludovic Courtès wrote:
Toggle quote (3 lines)
> 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 atother config options in builtin/pull.c), and would be a great idea. Itappears to pass it off to merge.c; that might be a useful area to verifysignatures as well (pull being a fetch && merge/rebase), in a generalsense.
Toggle quote (7 lines)
> 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 signedtag is just a signed hash of the commit it points to (with somemetadata), so you're trusting the integrity of SHA-1 and nothingmore.
With that said, the tag points to what will hopefully be a signedcommit, so if you verify the signature of the tag _and_ that commit,that'd be even better. Git's use of SHA-1 makes cryptographicassurances difficult/awkward.
An occasional traversal of the entire DAG by, say, a CI script wouldprovide some pretty good confidence. I wouldn't say it's necessary forevery pull.
Toggle quote (6 lines)
> 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 youcan have a keyring trusting only the appropriate Guixhackers. Otherwise, I agree.
Toggle quote (4 lines)
> 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? Or are you just consideringthe possibility?
I agree that it is awkward. At the same time, making it configurable(in the git sense) can potentially be very dangerous, because amalicious script (e.g. configure) could just modify it to a noop(e.g. `true`) and circumvent signature checks.
Toggle quote (3 lines)
> Fifth, even if we did that, we’d be stuck parsing the possibly l10n’d> output of ‘gpg’. Pretty fragile.
In the log output? You could use --pretty and %G*. Otherwise, yesparsing GPG's output seems dangerous; surely there's a better way (likeLeo mentioned).
Toggle quote (4 lines)
> Well no, it turns out that libgit2³ has no support for signed commits> (the ‘signature’ abstraction there has nothing to do with OpenPGP> signatures.)
!? D:
That's more concerning from a community mindset standpoint than anything.
Toggle quote (5 lines)
> 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?[*]
Toggle quote (5 lines)
> I stumbled upon git-lockup⁴, which uses something other than OpenPGP to> sign objects in Git. However, signatures are not stored in commits but> rather in “git notes”, which, IIUC, are mutable objects detached from> the rest of the object store, so not great.
It seems a bit over-complicated. Without reading much into it, itdoesn't strike me as much different than a detached signature, but theproblem is that the signature (as you implied) can just bedeleted. Git's commit/tag signatures are embedded in the actualobject. git-lockup also seems to hash "(branch,commitid) pairs", whichsigns considerably less data than Git's signature would (unless itactually signs the full object, not a string referencing it).I'll have to read over your first reference (your message) and itsreferences; now I'm curious.[*]: I was actually considering writing an FFI for libgcrypt (if itdoesn't exist already), but it made me uncomfortable without studyingwhether Guile can make assurances that pointer-referenced data in"secure" memory will never be copied anywhere else. I was going tobring it up in the near future on the guile mailing list after I didsome research myself; no need to derail the discussion here.-- Mike GerwitzFree Software Hacker+Activist | GNU Maintainer & Volunteerhttps://mikegerwitz.comFSF Member #5804 | GPG Key ID: 0x8EE30EAB