GPG signing for git commit?

GPG signing for git commit?

[Chow Loong Jin]

[-- Attachment #1.1: Type: text/plain, Size: 540 bytes --]

Hi,

It crossed my mind that currently git commits cannot actually be
verified to be authentic, due to the fact that I can just set my
identity to be someone else, and then commit under their name. During
discussion on #git, Ilari, context and I figured that it would be a good
idea to get GPG signing on git commits, considering that git-tag already
has GPG signing support.

Attached is the transcript of the log, with some irrelevant bits chopped
out. Log is dated Sat, April 4, and timezone GMT +0800.

-- 
Chow Loong Jin

[-- Attachment #1.2: git-commit-sign.log --]
[-- Type: text/x-log, Size: 8998 bytes --]

04:35 <hyperair> hmm i've always wondered... is it possible to create commits under someone else's name and then push it to a git server? if it is, how does one prevent that from happening?
04:35 <hyperair> s/git server/git repo/
04:36 <Ilari> hyperair: Sure it is.
04:36 <wereHamster> hyperair: GIT_COMMITTER_NAME="Someone Else" git commit
04:36 <Ilari> UUncia: It has capability to transfer commits between repositories. Pushing (transfer to another repository), Fetching (transfer from another repository, clone/pull are built on top) and sneakernet commit transport are all supported.
04:36 <hyperair> Ilari, wereHamster: yeah i thought so, but how do you prevent someone from pushing to a git repo under your name?
04:36 <wereHamster> hyperair: you'd have to have hooks on the server side that check the commiter name
04:36 <hyperair> ah i see
04:37 <Ilari> hyperair: Then there are situations where one legimately needs to push commit with some oddball committer name.
04:37 <wereHamster> hyperair: also note that git distinguishes between committer and author
04:37 <hyperair> wereHamster: committer and author?
04:38 <hyperair> wereHamster: what's the difference?
04:38 <wereHamster> hyperair: author is the person who wrote the patch, committer is the person who created the commit
04:38 <wereHamster> so if someone sends you a patch, he/she is the author but you are the committer
04:38 <hyperair> wereHamster: how does git tell the difference?
04:39 <hyperair> wereHamster: also, supposing you weren't working by passing patches around, but rather by pushing to a main project repository, what's to stop one committer from committing under another person's name and shoving all the blame onto him?
04:39 <context> the authors are like physics students
04:39 <hyperair> or her?
04:39 <context> and the commiters are rocket scientests
04:40 <wereHamster> I think by looking at the patch headers (assuming it's sent in mbox format)
04:40 <context> hyperair: nothing.
04:40 <hyperair> context: bit insecure don't you think?
04:40 <context> hyperair: there is no way to stop it. you gave them commit access, you trust them enough
04:41 <wereHamster> there is a way to stop it: don't give them committ access ;)
04:41 <context> werehamster: ;)
04:41 <hyperair> wereHamster: you mean push access =p
04:41 <Ilari> hyperair: There are cases like: I work on some feature. I complete it and send pull request to somebody who has push privs to main repo. They pull it and since its up to date, it results fast forward. Then they push it. Again, its up to date so push succeeds. Now you have wound up with situation where topmost commit claims (correctly) that I committed it.
04:41 <context> hyperair: unless you have a propsel on how to stop it
04:42 <Circuitsoft> There isn't really a way to stop it.
04:42 <Ilari> hyperair: You could use hooks to keep logs about who pushed what.
04:42 <hyperair> i see
04:42 <Circuitsoft> Even if there were, there's nothing preventing someone else from setting their identity to you.
04:42 <context> ilari: that still doesnt work.
04:42 <context> ilari: say i pull from you, merge my changes with yours, then merge into master and push to repo
04:43 <context> how do you track the branch i pulled form you is really from you.
04:43 <hyperair> how about gpg signing every commit =p
04:43 <Ilari> context: Both "merges" are fast forwards by assumption there.
04:43 <hyperair> just like how tags can be signed, how about signing them commits
04:43 <context> hyperair: that would work.
04:43 <context> ilari: no i mean merge as in merge.
04:43 <Ilari> hyperair: Its just impractical with current tools.
04:44 <hyperair> Ilari: yeah it's impractical, but if you git git-commit signing capabilities similar to taht of git-tag's i'm sure it would work
04:44 <hyperair> Ilari: and become practical.
04:44 <Ilari> context: Unless you explicitly ask, merge when presented with situation where one of branches is in future of another will make fast forward without any new commits.
04:45 <Ilari> hyperair: There are even hacks that authenticate pushing to git:// by using signed tags.
04:46 <hyperair> Ilari: what hacks are those?
04:46 <Ilari> hyperair: They essentially implement push authentication on top of git://
04:46 <Ilari> hyperair: Not very helpful, because ssh usually does it better.
04:46 <hyperair> yeah i thought so
04:47 <Ilari> hyperair: And as tip: If you want to keep logs, current version of gitosis (last I checked) can not be used in such applications without modification.
04:48 <hyperair> Ilari: what's gitosis?
04:48 <Ilari> hyperair: Software that makes admining repo permissions in group settings easier.
04:48 <hyperair> hmm interesting
04:49 <Dashkal> Sometimes I wish I could annotate a branch.  Leave a comment on the branch itself that explains why I made it...
04:49 <Ilari> hyperair: Usually very good. But its lack of exported user identity (unless you can hack it in) is absolute showstopper if you need to keep push logs.
04:49 <hyperair> hmm
04:50 <Ilari> hyperair: But its one line change AFAICS...
04:50 <hyperair> interesting
04:50 <hyperair> Dashkal: self-explanatory names ftw.
04:51 <context> ilari: yes i know
04:51 <context> <-- not new to git
04:59 <context> hyperair: only way to trust a commit would be gpg signatures
04:59 <Dashkal> Ilari: oh?  Might have to hunt through git.git for it
04:59 <Ilari> Dashkal: pu has it.
04:59 <Dashkal> nifty, danke
04:59 <context> but i dont think you can gpg sign all commits can you
04:59 <context> not to mention typing in that passwd every commit would SUCK !
04:59 <hyperair> context: yes of course, but git commit doesn't have gpg support.
04:59 <Ilari> Dashkal: Next doesn't. But beware that pu begins to be actually unstable.
04:59 <hyperair> context: ever heard of a gpg agent?
05:00 <context> hyperair: yes. firegpg uses it so i dont have to type it in for every email i send from gmail
05:00 <Dashkal> Ilari: Yeah, I'm kind of afraid of pu as a whole, but if I can find the relivant commits I can bring just that in
05:00 <context> gmail + gpg = win
05:00 <hyperair> i use evolution.
05:00 <context> hyperair: another ewe.
05:00 <context> ;)
05:00  * hyperair wonders what ewe is
05:01 <context> 'icky' growse
05:01 <Ilari> hyperair: Gpg signing doesn't really work if you have external contributors that can request pull unless you force non-ff merge somewhere.
05:01 <hyperair> i don't think it comes with a trailing e
05:01 <context> ilari: eh?
05:01 <context> hyperair: ill have to update my dictionary
05:01 <hyperair> Ilari: the main point is that you make your commits be verifiable, so that nobody can pretend to commit as you.
05:02 <context> hyperair: use svn, ;)
05:02  * hyperair barfs on context 
05:02 <Circuitsoft> context: Blasphemer!
05:02 <Ilari> hyperair: Well, if you need identifying of main contributors only.
05:02  * context hides
05:02 <Ilari> hyperair: So no one spoofs them. But it doesn't protect others.
05:02 <context> ilari: actually it wouldnt be too hard. if commit's could be sign
05:02 <hyperair> Ilari: yeah true.
05:03 <context> trusted users could add their finger print to like a ~/.gitfinger file
05:03 <context> people WOULD notice if that gets changed
05:03 <context> and you could have like a git fetch-gpg-keys
05:03 <hyperair> hahah
05:03 <hyperair> i think we should file that as a feature request =p
05:03 <hyperair> if tags can be signed, why not commits? =p
05:04 <Ilari> hyperair: Both even have similar structure. Header fields plus freeform text section.
05:04 <Ilari> hyperair: The text section is even fully 8-bit clean.
05:04 <hyperair> awesome. so let's have it signed =p
05:05 <Ilari> hyperair: Since it starts immediately after first 0A0Ah sequence in object and continues to end of object. And objects need to be 8-bit clean to store binary files in blobs.
05:05 <context> hyperair: then you need to worry about an author signature, AND commiters signature
05:05 <context> and diff's might be even more funky
05:06 <context> but it would be an awesome feature
05:06 <hyperair> context: diffs can have headers and footers. so a clearsign would be fine
05:06 <Ilari> If you care only about protecting main authors, committer signature is enough.
05:06 <Circuitsoft> What if gpg on commit was only used when the --signoff option was selected?
05:07 <Ilari> It also has simplifying factor that signing headers plus rest of commit message is enough.
05:07 <hyperair> Circuitsoft: that would be awesome, but as far as i can tell, it isn't used atm
05:07 <hyperair> now then are there any git devs we can propose this to? =p
05:07 <context> <-- gets all credit
05:07 <context> and his million dollar prize
05:08 <hyperair> lol
05:08 <Ilari> hyperair: Send idea to mailinglist. The official policy is essentially that altough this channel has archives, for development purposes discussions here never happned.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: GPG signing for git commit?

[Linus Torvalds]

On Sat, 4 Apr 2009, Chow Loong Jin wrote:
> 
> It crossed my mind that currently git commits cannot actually be
> verified to be authentic, due to the fact that I can just set my
> identity to be someone else, and then commit under their name.

You can't do that.

Well, you can, but it's always going to be inferior to just adding a tag. 

The thing is, what is it you want to protect? The tree, the authorship, 
the committer info, the commit log, what?

And it really does matter. Because the signature must be over some part of 
the commit, and since the SHA1 of the commit by definition contains 
everything, then the _safest_ thing is always to sign the SHA1 itself: 
thus a tag.

Anything else is always bound to only sign a _part_ of the commit. What 
part do you feel like protecting? Or put another way, what part do you 
feel like _not_ protecting?

So the way git does signatures protects everything. When you do a tag with 
"git tag -s" on a commit, you can absolutely _know_ that nobody will ever 
modify that commit in any way without the tag signature becoming invalid. 

And perhaps equally interestingly, that signature is now also easily 
separable from the history - which is interesting if you want to 
distribute your cryptographic parts separately (for example, you only use 
it _internally_ within a company or group, to mark some group-specific 
issues).

Also, related to that "separable" - the person signing on something is not 
necessarily the person marked as author, or even committing it anyway. One 
of the guiding goals for git was always that it should work well with 
"outside" flows, ie others passing patches around or using other SCM's to 
manage their own flow. 

Finally, on that same "separable" notion - imagine a big rewrite operation 
for whatever reason - like a big import into git, or a project re-writing 
their history because they ended up importing more history from old 
sources (or because they wanted to split a big project into subprojects). 
All of those invalidate any cryptographic signatures.

And all of those are events that you may still want to _update_ the 
signatures, but do you want to trust the one doing the conversion with the 
private keys? Obviously not. You could "wrap" the signing in a new 
"conversion signature", and have a signature to try to imply that the 
person doing the conversion "signs" the conversion. But the fact is, that 
doesn't mean the same thing.

With separate signatures (ie the "git tag -s" model), you can ask the 
people who signed the original repository to consider re-signing the 
rewritten one. See? Safe, flexible, and much superior.

The exact same thing goes for keys that get invalidated because they ended 
up being shown to be too weak or just flawed some other way, btw. That is 
a reason to re-sign, _without_ the repository necessarily changing.

You can do _none_ of these things sanely if you put the signatures into 
the commits themselves. 

So don't do it.

Btw, there's a final reason, and probably the really real one. Signing 
each commit is totally stupid. It just means that you automate it, and you 
make the signature worth less. It also doesn't add any real value, since 
the way the git DAG-chain of SHA1's work, you only ever need _one_ 
signature to make all the commits reachable from that one be effectively 
covered by that one. So signing each commit is simply missing the point. 

IOW, you don't _ever_ have a reason to sign anythign but the "tip". The 
only exception is the "go back and re-sign", but that's the one that 
requires external signatures anyway.

So be happy with 'git tag -s'. It really is the right way.

		Linus

Re: GPG signing for git commit?

[Sam Vilain]

Linus Torvalds wrote:
> On Sat, 4 Apr 2009, Chow Loong Jin wrote:
>   
>> It crossed my mind that currently git commits cannot actually be
>> verified to be authentic, due to the fact that I can just set my
>> identity to be someone else, and then commit under their name.
>>     
>
> You can't do that.
>
> Well, you can, but it's always going to be inferior to just adding a tag. 
>
> The thing is, what is it you want to protect? The tree, the authorship, 
> the committer info, the commit log, what?
>   
[...]
> Btw, there's a final reason, and probably the really real one. Signing 
> each commit is totally stupid. It just means that you automate it, and you 
> make the signature worth less. It also doesn't add any real value, since 
> the way the git DAG-chain of SHA1's work, you only ever need _one_ 
> signature to make all the commits reachable from that one be effectively 
> covered by that one. So signing each commit is simply missing the point. 
>
> IOW, you don't _ever_ have a reason to sign anythign but the "tip". The 
> only exception is the "go back and re-sign", but that's the one that 
> requires external signatures anyway.
>
> So be happy with 'git tag -s'. It really is the right way.
>   

Linus I agree with these points - I'd just like to point you to the new
mirror-sync design document. Under Documentation/git-mirror-sync.txt on
http://github.com/samv/git/tree/mirror-sync - and an implementation plan
outlined in Documentation/git-mirror-sync-impl.txt

This system allows for *pushes* to be signed and in general laying the
foundation for knowing that commits are authentic without the intrusion
into the refs/tags/* space that making lots of signed tags would imply.
The idea is to put 'packed-refs' contents (or a moral equivalent) in tag
bodies. It is really a new type of object, but it's sufficiently similar
to a tag that I thought I'd just go and go with that design for now.
Anyway if you're curious take a look, otherwise wait for the formal
submission once I've got something better together...

Sam

Re: GPG signing for git commit?

[Jakub Narebski]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Sat, 4 Apr 2009, Chow Loong Jin wrote:
> > 
> > It crossed my mind that currently git commits cannot actually be
> > verified to be authentic, due to the fact that I can just set my
> > identity to be someone else, and then commit under their name.

[...]
> Btw, there's a final reason, and probably the really real one. Signing 
> each commit is totally stupid. It just means that you automate it, and you 
> make the signature worth less. It also doesn't add any real value, since 
> the way the git DAG-chain of SHA1's work, you only ever need _one_ 
> signature to make all the commits reachable from that one be effectively 
> covered by that one. So signing each commit is simply missing the point. 
> 
> IOW, you don't _ever_ have a reason to sign anythign but the "tip". The 
> only exception is the "go back and re-sign", but that's the one that 
> requires external signatures anyway.
> 
> So be happy with 'git tag -s'. It really is the right way.

And if you really, really need for some reason (for example
requirement checkpoint, or being paranoid enough) ned to have each and
every commit signed, you can use Monotone instead of Git.  That is
what we recommended IPsec (or something) on #git.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: GPG signing for git commit?

[Linus Torvalds]

On Tue, 7 Apr 2009, Jakub Narebski wrote:
> 
> And if you really, really need for some reason (for example
> requirement checkpoint, or being paranoid enough) ned to have each and
> every commit signed, you can use Monotone instead of Git.  That is
> what we recommended IPsec (or something) on #git.

Yeah, well..

That's more of a "If you really want to be incredibly slow, depend on an 
unbelievably baroque model, _and_ you are too stupid to understand the 
fact that you only need to sign the tip", then use Monotone.

But yes, the "sign each commit" is one of the big design mistakes in 
Monotone. Go ask them about how much pain it has caused them.

			Linus

Re: GPG signing for git commit?

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]

On Mon, Apr 06, 2009 at 06:05:38PM +1200, Sam Vilain wrote:
> This system allows for *pushes* to be signed and in general laying the
> foundation for knowing that commits are authentic without the intrusion
> into the refs/tags/* space that making lots of signed tags would imply.
I'm on the lookout for something similar, so that we can be sure who
introduced some change into the central repo.

One of the spots that we're looking for in this, is a model something
like what follows. Firstly, a "proxy maintainer" (PM) is a developer
with commit rights to the central repo, that's willing to proxy commits
by an outside source for some specific package. Think of them as the
kernel subsystem maintainer, but many more of them. The PM is still
expected to verify the work before passing it on the central repo.

So we have a commit with author+committer being the outside source, and
now we want to record (in an easily reviewable fashion) that a specific
changeset was introduced to the central tree by the PM.

Not sure of the best route to trace this data. Signing the SHA1 makes
the most sense, but need to be able to do that without polluting the tag
namespace.

If the changeset does not have an associated signature, we'd like to
reject it at the central repo.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]

Re: GPG signing for git commit?

[Shawn O. Pearce]

"Robin H. Johnson" <robbat2@gentoo.org> wrote:
> 
> One of the spots that we're looking for in this, is a model something
> like what follows. Firstly, a "proxy maintainer" (PM) is a developer
> with commit rights to the central repo, that's willing to proxy commits
> by an outside source for some specific package. Think of them as the
> kernel subsystem maintainer, but many more of them. The PM is still
> expected to verify the work before passing it on the central repo.
> 
> So we have a commit with author+committer being the outside source, and
> now we want to record (in an easily reviewable fashion) that a specific
> changeset was introduced to the central tree by the PM.
> 
> Not sure of the best route to trace this data. Signing the SHA1 makes
> the most sense, but need to be able to do that without polluting the tag
> namespace.

Have the PM push over SSH, and don't ever expire reflogs on the
central repository?  The reflog will have the old and new commits
and the user name of the PM.

Downsides are:

- data is in the reflog on the central repository, to access it
  you need to expose that file via some non-git means (e.g. http
  or direct shell).

- one reflog record may cover multiple commits, so looking up a
  single commit is very difficult.  no current tools exist to merge
  the reflog back against the commit history to attach the record
  to a range of commits.

- the reflog is a text file, it will get somewhat large with time.

- the reflog is destroyed when the branch is deleted.  you may need a
  hook to forbid deletion of critical branches, so the reflog stays.

-- 
Shawn.

Re: GPG signing for git commit?

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

On Wed, Apr 15, 2009 at 12:20:54PM -0700, Shawn O. Pearce wrote:
> > Not sure of the best route to trace this data. Signing the SHA1 makes
> > the most sense, but need to be able to do that without polluting the tag
> > namespace.
> Have the PM push over SSH, and don't ever expire reflogs on the
> central repository?  The reflog will have the old and new commits
> and the user name of the PM.
All pushing to the central repo will be git+ssh:// anyway.

I don't follow where the PM's identity is being stored, and how that's
distributed back out with the later pulls.

The other downside to relying on SSH presentation of identity directly,
is the inability to use the SSH key to uniquely identify the user during
the SSH auth (see designs like gitosis, where you always push to
git+ssh://git@host/repo).

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]

Re: GPG signing for git commit?

[Shawn O. Pearce]

"Robin H. Johnson" <robbat2@gentoo.org> wrote:
> On Wed, Apr 15, 2009 at 12:20:54PM -0700, Shawn O. Pearce wrote:
> > > Not sure of the best route to trace this data. Signing the SHA1 makes
> > > the most sense, but need to be able to do that without polluting the tag
> > > namespace.
> > Have the PM push over SSH, and don't ever expire reflogs on the
> > central repository?  The reflog will have the old and new commits
> > and the user name of the PM.
>
> All pushing to the central repo will be git+ssh:// anyway.
> 
> I don't follow where the PM's identity is being stored, and how that's
> distributed back out with the later pulls.

Its stored in the reflog for the branch; see "git log -g branch".
Technically the environment variable GIT_COMMITTER_NAME and
GIT_COMMITTER_EMAIL is used to populate the identity into the reflog,
but if these aren't set then its guessed from the gecos information
of the effective user.
 
> The other downside to relying on SSH presentation of identity directly,
> is the inability to use the SSH key to uniquely identify the user during
> the SSH auth (see designs like gitosis, where you always push to
> git+ssh://git@host/repo).

Uhm, yea.  That's a fault of gitosis then.  It knows the key that
was used, and has that mapped back to some token that identifies that
account in the configuration file.  Why it doesn't push that into the
GIT_COMMITTER_* environment before launching git-shell, I don't know.

<plug type="shameless">

My day-job project, Gerrit Code Review[1], actually does the right
thing by recording the identity of the user in the reflog...

</plug>


[1] http://code.google.com/p/gerrit/

-- 
Shawn.

Re: GPG signing for git commit?

[Sitaram Chamarty]

On 2009-04-16, Shawn O. Pearce <spearce@spearce.org> wrote:
>> The other downside to relying on SSH presentation of identity directly,
>> is the inability to use the SSH key to uniquely identify the user during
>> the SSH auth (see designs like gitosis, where you always push to
>> git+ssh://git@host/repo).
>
> Uhm, yea.  That's a fault of gitosis then.  It knows the key that
> was used, and has that mapped back to some token that identifies that
> account in the configuration file.  Why it doesn't push that into the
> GIT_COMMITTER_* environment before launching git-shell, I don't know.

If you set GIT_COMMITTER_*, won't it change the SHA of the
commit itself?  I always thought so...

One possibility is to set "LogLevel VERBOSE" in
/etc/ssh/sshd_config and save those logs -- they can help
you match up the timestamps in the reflogs and find out who
pushed what, subject to all the other caveats in Shawn's
earlier post.

But it's a kludge... sadly my python-fu is zero; I really
wish gitosis would put that info *somewhere*.

Re: GPG signing for git commit?

[Jeff King]

On Fri, Apr 17, 2009 at 03:42:07AM +0000, Sitaram Chamarty wrote:

> > Uhm, yea.  That's a fault of gitosis then.  It knows the key that
> > was used, and has that mapped back to some token that identifies that
> > account in the configuration file.  Why it doesn't push that into the
> > GIT_COMMITTER_* environment before launching git-shell, I don't know.
> 
> If you set GIT_COMMITTER_*, won't it change the SHA of the
> commit itself?  I always thought so...

No. Pushing will never create a new commit, so there are no new SHA-1s
calculated. But the reflog entry will contain GIT_COMMITTER_*, and is a
simple text file.

-Peff

Re: GPG signing for git commit?

[Sitaram Chamarty]

On 2009-04-17, Jeff King <peff@peff.net> wrote:
>> If you set GIT_COMMITTER_*, won't it change the SHA of the
>> commit itself?  I always thought so...
>
> No. Pushing will never create a new commit, so there are no new SHA-1s
> calculated. But the reflog entry will contain GIT_COMMITTER_*, and is a
> simple text file.

cool -- I didn't know this.  Thanks!

One last question: where do you set it, in the pre-commit
hook on the server?

Re: GPG signing for git commit?

[Jeff King]

On Fri, Apr 17, 2009 at 06:36:40PM +0000, Sitaram Chamarty wrote:

> On 2009-04-17, Jeff King <peff@peff.net> wrote:
> >> If you set GIT_COMMITTER_*, won't it change the SHA of the
> >> commit itself?  I always thought so...
> >
> > No. Pushing will never create a new commit, so there are no new SHA-1s
> > calculated. But the reflog entry will contain GIT_COMMITTER_*, and is a
> > simple text file.
> 
> cool -- I didn't know this.  Thanks!
> 
> One last question: where do you set it, in the pre-commit
> hook on the server?

No, for two reasons:

  1. The pre-commit hook is run when making a local commit. For pushing,
     you would want the pre-receive hook.

  2. Hooks are executed as child processes of receive-pack, so they
     can't impact the environment it sees.

I think you would need to intercept the call to receive-pack (e.g., by
replacing it with a wrapper script), set the variables based on ssh keys
used (or whatever criteria you want), and then exec receive-pack.

-Peff

Re: GPG signing for git commit?

[Nguyen Thai Ngoc Duy]

On Thu, Apr 16, 2009 at 4:55 AM, Robin H. Johnson <robbat2@gentoo.org> wrote:
> One of the spots that we're looking for in this, is a model something
> like what follows. Firstly, a "proxy maintainer" (PM) is a developer
> with commit rights to the central repo, that's willing to proxy commits
> by an outside source for some specific package. Think of them as the
> kernel subsystem maintainer, but many more of them. The PM is still
> expected to verify the work before passing it on the central repo.
>
> So we have a commit with author+committer being the outside source, and
> now we want to record (in an easily reviewable fashion) that a specific
> changeset was introduced to the central tree by the PM.
>
> Not sure of the best route to trace this data. Signing the SHA1 makes
> the most sense, but need to be able to do that without polluting the tag
> namespace.
>
> If the changeset does not have an associated signature, we'd like to
> reject it at the central repo.

How about signing the tree SHA-1 and putting the signature in commit
message? It's like gpg way of saying Signed-off-by. If the committer
wants to sign again before pushing out, he could amend the commit,
append his signature there; or make a no-change commit to contain his
signature (probably from git-commit-tree because iirc git-commit won't
let you make no-change commit)
-- 
Duy

Re: GPG signing for git commit?

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]

On Thu, May 07, 2009 at 03:30:51PM +1000, Nguyen Thai Ngoc Duy wrote:
> On Thu, Apr 16, 2009 at 4:55 AM, Robin H. Johnson <robbat2@gentoo.org> wrote:
> > One of the spots that we're looking for in this, is a model something
> > like what follows. Firstly, a "proxy maintainer" (PM) is a developer
> > with commit rights to the central repo, that's willing to proxy commits
> > by an outside source for some specific package. Think of them as the
> > kernel subsystem maintainer, but many more of them. The PM is still
> > expected to verify the work before passing it on the central repo.
> >
> > So we have a commit with author+committer being the outside source, and
> > now we want to record (in an easily reviewable fashion) that a specific
> > changeset was introduced to the central tree by the PM.
> >
> > Not sure of the best route to trace this data. Signing the SHA1 makes
> > the most sense, but need to be able to do that without polluting the tag
> > namespace.
> >
> > If the changeset does not have an associated signature, we'd like to
> > reject it at the central repo.
> How about signing the tree SHA-1 and putting the signature in commit
> message? It's like gpg way of saying Signed-off-by. If the committer
> wants to sign again before pushing out, he could amend the commit,
> append his signature there; or make a no-change commit to contain his
> signature (probably from git-commit-tree because iirc git-commit won't
> let you make no-change commit)
Hmm, I like the sound of that, but I'm concerned it might be difficult
to enforce. If rewrite-history ever happens, it's also invalidated.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]

Re: GPG signing for git commit?

[Nguyen Thai Ngoc Duy]

On Sat, May 9, 2009 at 5:03 AM, Robin H. Johnson <robbat2@gentoo.org> wrote:
>> How about signing the tree SHA-1 and putting the signature in commit
>> message? It's like gpg way of saying Signed-off-by. If the committer
>> wants to sign again before pushing out, he could amend the commit,
>> append his signature there; or make a no-change commit to contain his
>> signature (probably from git-commit-tree because iirc git-commit won't
>> let you make no-change commit)
> Hmm, I like the sound of that, but I'm concerned it might be difficult
> to enforce. If rewrite-history ever happens, it's also invalidated.

Well if you rewrite and touch the trees, then every signature should
be invalidated anyway. If you only touch commit message, it should
remain valid because I only sign trees.
-- 
Duy

Re: GPG signing for git commit?

[Nguyen Thai Ngoc Duy]

[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

On Mon, May 11, 2009 at 8:53 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Sat, May 9, 2009 at 5:03 AM, Robin H. Johnson <robbat2@gentoo.org> wrote:
>>> How about signing the tree SHA-1 and putting the signature in commit
>>> message? It's like gpg way of saying Signed-off-by. If the committer
>>> wants to sign again before pushing out, he could amend the commit,
>>> append his signature there; or make a no-change commit to contain his
>>> signature (probably from git-commit-tree because iirc git-commit won't
>>> let you make no-change commit)
>> Hmm, I like the sound of that, but I'm concerned it might be difficult
>> to enforce. If rewrite-history ever happens, it's also invalidated.
>
> Well if you rewrite and touch the trees, then every signature should
> be invalidated anyway. If you only touch commit message, it should
> remain valid because I only sign trees.

I went ahead and made two scripts git-gpg-sign and git-gpg-verify to
see if it works. Things that are signed in these scripts:
 - tree
 - parents
 - any other gpg signature
You probably don't want to sign the same commit too many times because
the signature will get huge.
-- 
Duy

[-- Attachment #2: git-gpg-sign --]
[-- Type: application/octet-stream, Size: 601 bytes --]

#!/bin/sh
PGP='/^-----BEGIN PGP MESSAGE-----$/,/^-----END PGP MESSAGE-----$/'
COMMIT_GPGMSG="$(git rev-parse --git-dir)"/COMMIT_GPGMSG
GPGMSG="$(git rev-parse --git-dir)"/GPGMSG
git cat-file -p HEAD | sed -ne '1,/^$/p' | egrep '^tree |^parent ' > "$GPGMSG"

#if it's not valid, just drop it
git cat-file -p HEAD | grep -q '^-----BEGIN PGP MESSAGE-----$' &&
	git gpg-verify &&
	git cat-file -p HEAD | sed -ne "$PGP"p >> "$GPGMSG"
git cat-file -p HEAD | sed -e '1,/^$/d' | sed -e "$PGP"d > "$COMMIT_GPGMSG"
gpg --sign --armor -o - "$GPGMSG" >> "$COMMIT_GPGMSG"
git commit --amend -F "$COMMIT_GPGMSG" -e

[-- Attachment #3: git-gpg-verify --]
[-- Type: application/octet-stream, Size: 563 bytes --]

#!/bin/sh

die() {
	echo "$@"
	exit 1
}

PGP='/^-----BEGIN PGP MESSAGE-----$/,/^-----END PGP MESSAGE-----$/'
C="$1"
GPGMSG1="$(git rev-parse --git-dir)"/GPGMSG1
GPGMSG2="$(git rev-parse --git-dir)"/GPGMSG2
[ -n "$1" ] || C=HEAD
git cat-file commit $C > "$GPGMSG1"
while grep -q '^-----BEGIN PGP MESSAGE-----$' "$GPGMSG1";do
	[ -f "$GPGMSG2" ] && rm -f "$GPGMSG2"
	gpg -o "$GPGMSG2" "$GPGMSG1" || die "Failed to verify"
	mv "$GPGMSG2" "$GPGMSG1"
done
git cat-file commit $C | sed -ne '1,/^$/p' | egrep '^tree |^parent '|cmp -s "$GPGMSG1" || die "Failed to verify"