From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Gerwitz Subject: bug#22883: Authenticating a Git checkout Date: Sat, 04 Jun 2016 00:24:55 -0400 Message-ID: <87bn3hwpgo.fsf@gnu.org> References: <87io14sqoa.fsf@dustycloud.org> <87h9ep8gxk.fsf@gnu.org> <20160426001359.GA23088@jasmine> <874majg0z8.fsf@gnu.org> <87bn3iz1xc.fsf_-_@gnu.org> 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]:46996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b93Az-0000hI-JK for bug-guix@gnu.org; Sat, 04 Jun 2016 00:27:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b93At-0007sd-5C for bug-guix@gnu.org; Sat, 04 Jun 2016 00:27:08 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:41307) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b93At-0007sM-2U for bug-guix@gnu.org; Sat, 04 Jun 2016 00:27:03 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87bn3iz1xc.fsf_-_@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\?\= \=\?utf-8\?Q\?\=22's\?\= message of "Fri, 03 Jun 2016 18:12:47 +0200") 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: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 22883@debbugs.gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ludo: On Fri, Jun 03, 2016 at 18:12:47 +0200, Ludovic Court=C3=A8s wrote: > First, =E2=80=98git pull=E2=80=99 doesn=E2=80=99t do it for you, you have= to pass =E2=80=98--verify=E2=80=99 and > there=E2=80=99s 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. > Second, even if it did, it would be a shallow check: as Mike notes in > with the =E2=80=98signc= hk=E2=80=99 > script, you actually have to traverse the whole commit history and > authenticate them one by one. But that=E2=80=99s OK, it runs in presumab= ly less > than a minute on a repo the size of Guix=E2=80=99s, and we could also sto= p 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. > Third, as I wrote before=C2=B9, relying on the OpenPGP web of trust to > determine whether a commit is =E2=80=9Cvalid=E2=80=9D is inappropriate: w= hat 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. > Fourth, there=E2=80=99s inversion of control: =E2=80=98git log=E2=80=99 &= co. call out to =E2=80=98gpg=E2=80=99, > so if we want to do something different than just =E2=80=98gpg --verify= =E2=80=99, we > have to put some other =E2=80=98gpg=E2=80=99 script in $PATH. Blech. What types of things are you considering? Or are you just considering the possibility? I agree that it is awkward. At the same time, making it configurable (in the git sense) can potentially be very dangerous, because a malicious script (e.g. configure) could just modify it to a noop (e.g. `true`) and circumvent signature checks. > Fifth, even if we did that, we=E2=80=99d be stuck parsing the possibly l1= 0n=E2=80=99d > output of =E2=80=98gpg=E2=80=99. Pretty fragile. In the log output? You could use --pretty and %G*. Otherwise, yes parsing GPG's output seems dangerous; surely there's a better way (like Leo mentioned). > Well no, it turns out that libgit2=C2=B3 has no support for signed commits > (the =E2=80=98signature=E2=80=99 abstraction there has nothing to do with= OpenPGP > signatures.) !? D: That's more concerning from a community mindset standpoint than anything. > 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=E2=80= =99d > need to implement OpenPGP (in Guile, maybe based on the OpenPGP library > in Bigloo?)?! What about gpgme/libgcrypt?[*] > I stumbled upon git-lockup=E2=81=B4, which uses something other than Open= PGP to > sign objects in Git. However, signatures are not stored in commits but > rather in =E2=80=9Cgit notes=E2=80=9D, which, IIUC, are mutable objects d= etached from > the rest of the object store, so not great. It seems a bit over-complicated. Without reading much into it, it doesn't strike me as much different than a detached signature, but the problem is that the signature (as you implied) can just be deleted. Git's commit/tag signatures are embedded in the actual object. git-lockup also seems to hash "(branch,commitid) pairs", which signs considerably less data than Git's signature would (unless it actually signs the full object, not a string referencing it). I'll have to read over your first reference (your message) and its references; now I'm curious. [*]: 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. =2D-=20 Mike Gerwitz Free Software Hacker+Activist | 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 iQIcBAEBAgAGBQJXUlgYAAoJEPIruBWO4w6rCAEP/i96imcaecdY2WZmOK8xUrfx lasLlfR0pEFNzvHNBH+jbPgiaSSRv8NuA9G8FMbD6QWjjnpxx0lK414Acyu3qcaR KVNtpCvQnQQ3BVYyMHjlwdlkhLs8ZpqgnNirdX60jQ6xKEn3x6A/hVa/N1s0dgLv NL0+ep3ngIglxFGDT5/h3YJPGnUCW69EN8c4wiHP6HgzymhtwVjgxFCp11GF3EKX K5JfdxR3Yv+oifqST1YBRNRiav8aJ4NxrNxUFvSh2wLZrXw2eo6soKhgliqZnthS A09gI1aF+BCUp9uCxPzKfsP60wJRnNj0/q2qyZh5geNIBf13rLnH8TiZiROAgFkM mIlqAvv1p+OwolqFCZQeYkYZdbVgAOBX3uuPoCF1ehmw+hsnXahO+pPfm0y6mfI/ xeA5dDMF9tgOdQdRtGnG99umxYoeFHGZC8buxKHQX0ibB/7VW1WVbl1KH94wGQbf Nw5DqMWArL6NYLGVr0+TyTu9KElgL6WHiKl1/21wF/8G1hANcfmrfmBxnrXBGlr8 i1HRlHu0obZZb97r50rS/kqgEwo61T2KOCF0LumwCXVTfudvCaLUSgvvGAr2LIvj 3/4Y296Rgo1I8OmbSZIWP9+9sd7ac6aoSVGSvUMxnTIUE4R+lCIi9wKoEtjEz8ae gQTIM6ah1W4dZtGNwyIC =v3dl -----END PGP SIGNATURE----- --=-=-=--