From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Gerwitz Subject: bug#22883: Trustable "guix pull" Date: Sat, 30 Apr 2016 00:43:55 -0400 Message-ID: <874majg0z8.fsf@gnu.org> References: <87io14sqoa.fsf@dustycloud.org> <87h9ep8gxk.fsf@gnu.org> <20160426001359.GA23088@jasmine> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56881) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1awOqC-0008CR-NP for bug-guix@gnu.org; Sat, 30 Apr 2016 02:57:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1awOpt-0007Eu-5v for bug-guix@gnu.org; Sat, 30 Apr 2016 02:57:21 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:44018) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1awOpt-0007Dt-3B for bug-guix@gnu.org; Sat, 30 Apr 2016 02:57:05 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <20160426001359.GA23088@jasmine> (Leo Famulari's message of "Mon, 25 Apr 2016 20:13:59 -0400") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Leo Famulari Cc: 22883@debbugs.gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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=E2=80=99ll be signing patches we push on behalf of contribu= tors who >> do not have commit access (reviewer=E2=80=99s responsibility). >>=20 >> Also, rebasing, amending, and cherry-picking code signed by someone else >> would lose the original signature, which isn=E2=80=99t 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: =2D-8<---------------cut here---------------start------------->8--- $ git cat-file -p 7062845 tree 7d21b900c0773d7fdc898aecff11053a910ac18d parent 2b56dc019a049b2f68ce078b243fc313fbaeacf3 author Ludovic Court=C3=A8s 1461943404 +0200 committer Ludovic Court=C3=A8s 1461945944 +0200 gpgsig -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 [...] -----END PGP SIGNATURE----- nls: Add Simplified Chinese translation. [...] =2D-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/i= ndex.php?topic=3D538.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. =2D-=20 Mike Gerwitz Free Software Hacker | GNU Maintainer & Volunteer https://mikegerwitz.com FSF Member #5804 | GPG Key ID: 0x8EE30EAB --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXJDgMAAoJEPIruBWO4w6rUocP/Rv6NmA+nUb9lcdlBIpVpqLJ f9F4q4Ov4JI4yoNwiiZQqjm0qRBZvk8yIWoGm4FNAcgfXUVXHx1lGLuF+Hyr1SK4 8Q2AlRisHleMfEkKvmccZn+CgU1D3Qq7z0BGQezZY8GhYGGbWySHNq2IlCW5JCwZ CpdN1G0QZJhaPgxNWMxeTFcarreszbWd70Hf/SYN2V+Clk8xsvqvUFcYF5mPZAUU czvcCtZ6Zoy5qtqRvDuSvqQmOEIcDedywSGE7PP+RIU8iMl/d5w/IO//2aP8T9XQ NIfxZkDnxmnZT5VlpsdwSRHZu9OcG7uIcgh+65B5mYKX5UehH33m+BdouqxgrCS8 pnPW9+2o9db7L7JcQSvwspF0zCp+UTL+3mWpjfiagy3zwF41LX3QaLgmYI1V5RnK +IE/TxTJQvYHXMHr5xfTxuMJtbpLNEuuZvMUwIvbeCFhmzBbeq7VAXWkrUFCxtjE ciNJbmOsusPMlz2h92iryqBl5S67pdSDAZvBNHrY6KG3Yj5CWCRVYuxf4SnfDhY2 Y5vvbSfEqaVesSNDnalBvqM1Rur+t70qdaIc0d6NLwSahejwhIroLCeJ7n7xbAta AyX0aL2hvtGiJyN8/AfZVINLDRnD3DaoGaQA/r9PF3Bhg1COYnPz7wbh8SNTMVcH iaLnRJ8yC/LgdfMNilbo =MRud -----END PGP SIGNATURE----- --=-=-=--