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 1461943404 +0200 committer Ludovic Courtès 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