From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0 Subject: bug#22883: Authenticating a Git checkout Date: Mon, 6 Jun 2016 12:20:52 +0000 Message-ID: <20160606122052.GA21849@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> <20160604122003.GA12299@khazad-dum> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b9wWY-0006Cj-0x for bug-guix@gnu.org; Mon, 06 Jun 2016 11:33:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b9wWU-0002WX-4c for bug-guix@gnu.org; Mon, 06 Jun 2016 11:33:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:44584) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b9wWU-0002WN-1H for bug-guix@gnu.org; Mon, 06 Jun 2016 11:33:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: Content-Disposition: inline In-Reply-To: <20160604122003.GA12299@khazad-dum> 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 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2016-06-04(12:45:16PM+0000), ng0 wrote: > 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= 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 clon= e? > > > 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 ver= ify > > > 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, bu= t 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=98= signchk=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 pre= sumably less > > >> than a minute on a repo the size of Guix=E2=80=99s, and we could als= o 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 f= or > > > 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 inappropria= te: what we want to > > >> know is whether a commit was made by an authorized person, not wheth= er > > >> 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 --ver= ify=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 libr= ary > > >> in Bigloo?)?! > > > > > > What about gpgme/libgcrypt?[*] > > > > I believe, but haven=E2=80=99t checked carefully, that GPGME is too hig= h-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 G= PG_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_Po= rtage_tree_snapshots > > I know this isn't similar to what we want to do, but it might serve as an= example. > The method described in the link downloads an auto-signed tarball snapsho= t of the > portage directory via webrsync. The keys are also visible on the wiki and= it 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.gi= t/tree/README.md > > Maybe this helps a bit. > Adding to this what I just found: http://www.tedunangst.com/flak/post/signify https://github.com/aperezdc/signify I am /not/ sure if this will be useful for what guix secure pull wants to a= chieve, but maybe there's some inspiration to be found in the source. -- =E2=99=A5=E2=92=B6 ng0 For non-prism friendly talk find me on psyced.org / loupsycedyglgamf.onion --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXVWqkAAoJEAKilhUMIBgj9vUP/3KqKW6XkrHKdfJOM4x8+A0q xzCfyYEFYtYtZEL8mlrg8j82sIgVIF12cH+lrLtbV4hilaedO0GHHjDPOJeA0y8J nSr1KgmLFedJnyFl69klVgzagoxD9uKwh+U90W7DkWs7LedFhQEdbUaugznBEHST 1/j6cLBRZY1ijmrUVMYpEbSpoJpOBPe4jsN/truRHOsLJvvt43gYVhjwIPnLQFTW bdDl1q/ey2zYBLjDFWFeQKik+UvDxJqa6HtEjeMD8qGg1PQv/LCEiEmviRq0NpSQ 4jrI8oXa85zJSLWWJgv1DZFUC2OdfUrUqa49KWqvyn+58RQAPn5w/dLAsjeqtzYw Kiq5OLTGlmieArthE630r87PLOCwh1Ift+RMH/1ps2LCCg9prmOhGg107QyvX67m 0RL6uKt6+M68l6EbykrwkCezqnIj1PnthMkWq3y8b+gs0aNflXJuRyCD5j2pGa6l HXUQ6HFfRuhu9M+Foe3cv0YIux+pMsy5v29Xo0P5azlybNqfmMXPFwVpoLyQChfT ROzjvsbrlNRLD0Zg6dw6+0yITzTQMwp+CtJUG8+gYbU7OzFVpAzdnldGkPbkTkKN mt88xTlZNJ7gq58wR4T0Mr1XA1rxIQlXxXfGF574gFNCXKdb95VyGIs9CXgHnxg9 eD79+POFClIi8x2jyx8/ =vzDH -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw--