From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0 Subject: bug#22883: Authenticating a Git checkout Date: Sat, 4 Jun 2016 12:45:16 +0000 Message-ID: <20160604122003.GA12299@khazad-dum> References: <87io14sqoa.fsf@dustycloud.org> <87h9ep8gxk.fsf@gnu.org> <20160426001359.GA23088@jasmine> <874majg0z8.fsf@gnu.org> <87bn3iz1xc.fsf_-_@gnu.org> <87bn3hwpgo.fsf@gnu.org> <87wpm519um.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="b5gNqxB1S1yM7hjW" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41650) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b9EyY-000393-J9 for bug-guix@gnu.org; Sat, 04 Jun 2016 13:03:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b9EyU-0002b7-Ce for bug-guix@gnu.org; Sat, 04 Jun 2016 13:03:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:42241) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b9EyU-0002ar-9D for bug-guix@gnu.org; Sat, 04 Jun 2016 13:03:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: Content-Disposition: inline In-Reply-To: <87wpm519um.fsf@gnu.org> 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: 22883@debbugs.gnu.org --b5gNqxB1S1yM7hjW Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2016-06-04(01:17:53+0200), Ludovic Court=C3=A8s wrote: > Hi! > > Mike Gerwitz skribis: > > > 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 h= ave 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. > > Yeah, it wouldn=E2=80=99t be too hard to add to Git proper, I think, but = we > can even live without it initially. > > >> Second, even if it did, it would be a shallow check: as Mike notes in > >> with the =E2=80=98si= gnchk=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 presu= mably less > >> than a minute on a repo the size of Guix=E2=80=99s, and we could also = stop 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. > > Agreed. > > >> 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= : 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 you > > can have a keyring trusting only the appropriate Guix > > hackers. Otherwise, I agree. > > Oh right, we could do something like: > > gpgv --keyring guix-developers.keyring foo > > (I realize GSRC uses this idiom already when authenticating source > tarballs: > .) > > >> 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 --verif= y=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? > > Something as simple as this: > > --8<---------------cut here---------------start------------->8--- > $ git config gpg.program 'gpgv --keyring /dev/null' > $ git verify-commit HEAD > error: cannot run gpgv --keyring /dev/null: No such file or directory > error: could not run gpg. > --8<---------------cut here---------------end--------------->8--- > > :-/ > > >> 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 believe, but haven=E2=80=99t checked carefully, that GPGME is too high-= level; > libgcrypt is too low-level (it does not implement OpenPGP.) > > > [*]: 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. > > We have incomplete libgcrypt bindings: > > http://git.savannah.gnu.org/cgit/guix.git/tree/guix/pk-crypto.scm > > This is used for the authentication of substitutes: > > https://www.gnu.org/software/guix/manual/html_node/Substitutes.html > > Thanks for your feedback! > > Ludo=E2=80=99. > > > Aside from other problems, Couldn't we create a separate gpg(-1,-2) package which installs its own GPG= _HOME_DIR and keyring (gpg2 or gpg1 must be present for that, for future purposes a gpg2 would be best I think)? One example: https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Features#Validated_Port= age_tree_snapshots I know this isn't similar to what we want to do, but it might serve as an e= xample. The method described in the link downloads an auto-signed tarball snapshot = of the portage directory via webrsync. The keys are also visible on the wiki and i= t is up to users to put trust in them, as this method is considered optional. The source used for this is https://gitweb.gentoo.org/proj/gentoo-keys.git/= tree/README.md Maybe this helps a bit. -- =E2=99=A5=E2=92=B6 ng0 4096R/13212A27975AF07677A29F7002A296150C201823 --b5gNqxB1S1yM7hjW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXUs1bAAoJEAKilhUMIBgj7OgP/3/o5pRZA+o/IixERZnZLCVF YJNRYrqGo05myJSjF1SudwJ5F2WIQLnBwkiwet7d5dTRkFseDdbcWsLyW3c58ccC laLzau1J4rCo3DlN+SqEnShQeSpLu2SnJ2IGT8hJeUh7SvveIbisSj4Wk43a6Zo1 GCplzRfyNEm09ZHJ1D+x6LxfjTex5C1/GYIN2T7rz6DhPWUZWr742TMdoXwrfChO BI/IEANtcVFWdl68yHYnosC6X6PlgN8O/01cSXrcl9XPWNiglmkx3q4EnIjC09+9 ksfGx2DmE+Dse7L2aR8EXTwnHjGk9tzY+F2C0n2TBjckSfmYEDRocTUC4nbXr/LF IBXPjytayHV4TVTqBiZ7YOgblQ119AoLo/XpGsa7vh7IAl3iUHryE6B2/ZoPiOVo vb41mitZyIeuaG0k3/7r7/+2JcjDgJHo8ECd/lMz905/2IUGNZL8cWqUjFK4D5ae ei2KFL03sYWGqa8NZPiElLxLXa7SSpRqWdv6+ATbwGADJj/TA1QT1uhpZQuY9WIV j87blo+k+D1/xV6TZXcH8LejURXhGjMc9KC+Gvw8GTIJQ4SWECqmgwOJhcgCCcGc JpK3dprHt+z4FUZ/9gi/5wMd+BAa2o+laZnQv8PW7+NAfVhu0ywCh4MePoJfSWvI I5MfTXZmqaitWeI6HDh/ =rE0l -----END PGP SIGNATURE----- --b5gNqxB1S1yM7hjW--