Gentoo Archives: gentoo-scm

From: "Robin H. Johnson" <robbat2@g.o>
To: gentoo-scm@l.g.o
Subject: Re: [gentoo-scm] gpg signing of commits, was: Progress summary, 2009/06/01
Date: Fri, 05 Jun 2009 18:55:00
Message-Id: 20090605185416.GB22927@orbis-terrarum.net
In Reply to: [gentoo-scm] gpg signing of commits, was: Progress summary, 2009/06/01 by Robert Buchholz
1 On Fri, Jun 05, 2009 at 02:59:18PM +0200, Robert Buchholz wrote:
2 > On Tuesday 02 June 2009, Robin H. Johnson wrote:
3 > > - Review commit signing
4 > > - pclouds (a former Gentoo dev) contributed this prototype:
5 > > http://thread.gmane.org/gmane.comp.version-control.git/115562/focus=
6 > >118788 - I'm not entirely convinced the above is right, as the commit
7 > > message seems to end up unsigned.
8 > I was wondering why we need GPG signing of commits at all. I was
9 > thinking about the following two arguments:
10 The commit signing I'm after is so that we can be absolutely certain who
11 introduced a given commit to the tree (who committed, AND who pushed the
12 merge/fast-forward), and have that information distributed inside the
13 tree.
14
15 This is related to the push logging issue, if you've seen the
16 discussions on tracking who committed vs. who pushed.
17
18 > 0. Intro
19 > git stores the SHA1 hashes of objects and one can check for errors in
20 > the transmission or on the disk. This makes the (unsigned) Manifest
21 > parts unnecessary. Commit signing is the equivalent of Manifest file
22 > signing we have right now.
23 Yes, it's the replacement for the existing Manifest signing. The point
24 of that is proof of origin from developer BACK to infra.
25
26
27 > 1. It's not needed for tree signing
28 > The tree signing GLEP does not require signing of either commits or
29 > Manifests. It relies on the main infra repository is not being
30 > compromised.
31 That's the external distribution portion of tree signing: infra -> world
32 It's unrelated to the problem at hand within Git.
33
34 > 2. It is not well designed (cryptographically)
35 > OpenGPG allows the usage of a set of cryptographic hash function to sign
36 > a document. This allows people to switch to a different function once
37 > attacks against one algorithm become known. This has been recently seen
38 > with SHA-1: http://www.debian-administration.org/users/dkg/weblog/48
39 I only stated that we need to offer GPG signing of commits. I did NOT
40 specify the content of commits, other than noting that the commit
41 message and the content needs to be signed together.
42
43 > The git signing, however, relies on the collision resistance of SHA-1 as
44 > that algorithm is used to identify objects in the repository. We cannot
45 > migrate away from it easily. This has been discussed upstream at length
46 > and Linus pointed out that 'the "signed tags" security does depend on
47 > the hashes being cryptographically strong.':
48 > http://thread.gmane.org/gmane.comp.version-control.git/26106/focus=26125
49 The collision is going to come along anyway.
50
51 Resigning would have to be done regardless of what we sign in Git.
52 Not sure if you followed more recent discussions than one in 2006.
53 The entire Git foodchain will suffer when it comes time to migrate away
54 from SHA-2. Presently discussions of it imply that it's to be done
55 probably as a versioned change, after the NIST hash competition comes up
56 with a viable answer.
57
58 --
59 Robin Hugh Johnson
60 Gentoo Linux Developer & Infra Guy
61 E-Mail : robbat2@g.o
62 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85

Replies