bug#22883: Trustable "guix pull"

[Mike Gerwitz <mtg@gnu.org>]

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

Hey, guys.  Chris mentioned this thread to me.  I'm happy to see the
discussion!

Chris: unfortunately, my `mml-secure-openpgp-encrypt-to-self` flag
somehow got unset when I sent you my reply, so I can't read my own
message.  But I'll rewrite some of it here.

On Mon, Apr 25, 2016 at 20:13:59 -0400, Leo Famulari wrote:
>> Note that we’ll be signing patches we push on behalf of contributors who
>> do not have commit access (reviewer’s responsibility).
>> 
>> Also, rebasing, amending, and cherry-picking code signed by someone else
>> would lose the original signature, which isn’t great and should be
>> avoided, if possible.
>
> I think it's common to make minor edits when committing on behalf of
> others. For example, the committer might clean up a commit message or
> standardize indentation.
>
> How should we handle this?

You don't.

One of the core purposes of digital signatures is to ensure integrity of
the signed data: if I submit a patch, I don't want someone else
modifying it and saying it was my own, or saying it was modified without
supplying a diff; that'd be a misrepresentation; a horror story
almost. ;)

The question is for what purpose you're signing commits.  Chris
mentioned trust, but that can come in a few different forms.  Signatures
ensure:

  - Authentication: whether the commit came from a trusted source;
  - Integrity: assurance that the commit has not been modified; and
  - Non-repudiation of origin: the signer cannot deny signing it.

If you only care about authentication, then it doesn't matter if the
signature is retained---it only matters that the person who eventually
signs off on the commit is trusted.  In that case, just sign it.

If it's integrity, then make another commit that changes the
original.  I recommend this regardless, for the reason I stated above;
just branch, apply their commits, your change, and merge.

For non-repudiation assurances, you'll need to keep the original
signature as well.  This might be useful, say, in the case of issues
with copyright assignments---maybe an employer holds copyright on the
code and the employee claims he/she isn't the person that actually
submitted it.

All of this subject to the usual crypo-caveats (no compromised private
key, yadda yadda).

Now, what is being signed isn't actually the code---it's the contents of
the commit object, which includes a SHA-1 hash of the tree, parent
commit(s), author, committer, timestamp, and commit message:

--8<---------------cut here---------------start------------->8---
$ git cat-file -p 7062845
tree 7d21b900c0773d7fdc898aecff11053a910ac18d
parent 2b56dc019a049b2f68ce078b243fc313fbaeacf3
author Ludovic Courtès <ludo@gnu.org> 1461943404 +0200
committer Ludovic Courtès <ludo@gnu.org> 1461945944 +0200
gpgsig -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
[...]
 -----END PGP SIGNATURE-----

nls: Add Simplified Chinese translation.

[...]
--8<---------------cut here---------------end--------------->8---

My point with this[*] is that the GPG signature you receive isn't
meaningful in the case of a rebase---if it signed blobs or a diff, maybe
it would be.  But since rebasing will eventually cause the GPG-signed
commit to be GC'd (unless there's a ref to it), you can't modify the
commit and just reference the old diff with the original signature.

More details in a discussion with Whonix here:

  https://web.archive.org/web/20150619232904/https://www.whonix.org/forum/index.php?topic=538.msg4278#msg4278

So if you do want to clean up or squash GPG-signed changes from
contributors, or do other rebasing, then I'd either push back and tell
them to do it, or maybe have them send GPG-signed _patches_ to a public
mailing list where it can be permanently archived; then everyone can see
the original.


[*] SHA-1 was never intended to be used as a security measure in
Git---nor should it be; SHA-1 is effectively broken with the
demonstration of a freestart collision last year (where the attacker
controls the IV; but it's only a matter of time).  So if a collision can
be found for any of those signed SHA-1 hashes---or any hashes they
reference---_that actually makes sense to Git and humans_, then your
signature will still be perfectly valid.  But distribution archives are
also GPG-signed, so Git will never be the only place of reference.

I need to update my article, but I'm essentially saying that it's really
hard to have strong cryptographic assurances with Git even with signed
commits---that attack surface is simply too large, as I mentioned in the
Whonix discussion.  Realistically, it's extremely unlikely that
something will ever happen, but until Git switches to a secure hash
algorithm (...har har), don't expect full integrity.  If you're using
signatures for authorization primarily, then you don't really need to
worry.

-- 
Mike Gerwitz
Free Software Hacker | GNU Maintainer & Volunteer
https://mikegerwitz.com
FSF Member #5804 | GPG Key ID: 0x8EE30EAB

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]