Implementing commit signing

Implementing commit signing

[Balasubramaniam, Arunan]

Hello,

I am looking at using Git within our organisation, and verifying the
source of
commits has been raised as a concern. GPG signing individual commits has
been
discussed at least once on this list [1]. I got the impression from that
thread
that if a patch to implement it were submitted then it would probably
get
accepted. I have a few questions:

  1) Is that actually the case at present? I ask to avoid doing the work
and
     having it rejected.

  2) If it were accepted into Git, would an equivalent patch be accepted
into
     jgit? Would patches for UI to use it be accepted into egit?

I can not promise that we will actually write this patch as I am going
to
present it internally as one option and using hooks scripts as another,
but it
would be more likely to happen if there were positive answers to those
questions. 

Thanks,
Arunan Bala

[1] http://kerneltrap.org/mailarchive/git/2007/1/15/235839/thread


"Misys" is the trade name for Misys plc (registered in England and Wales). Registration Number: 01360027. Registered office: One Kingdom Street, London W2 6BL, United Kingdom. For a list of Misys group operating companies please go to http://www.misys.com/html/about_us/group_operating_companies/. This email and any attachments have been scanned for known viruses using multiple scanners. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys plc. Please refer to the executed contract betw
 een you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing. 

Re: Implementing commit signing

[Shawn O. Pearce]

"Balasubramaniam, Arunan" <Arunan.Balasubramaniam@misys.com> wrote:
> I am looking at using Git within our organisation, and verifying the
> source of
> commits has been raised as a concern. GPG signing individual commits has
> been
> discussed at least once on this list [1].

Another approach is to use a central Git server with SSH
key authentication and install into every repository the
contrib/hooks/update-paranoid hook as $GIT_DIR/hooks/update.
This is actually what I did at my prior day-job.

The update-paranoid hook scrapes all new incoming commits and
verifies the "committer" line matches the name and email address
associated with the user who is executing the "git push".

If you use this under something like say "Gitosis" then users don't
even need direct UNIX access.  The SSH public keys are installed
into a common user account, and the user is only allowed to start
the Gitosis wrapper.  The wrapper verifies the command is only a
git server request, then starts Git.  The update hook can then use
data from Gitosis to verify the committer lines.

Actually at prior day-job we wrote our own scripts to do this, and
didn't use Gitosis at all.  If I recall correclty it was about 200
lines of Perl to automatically manage the ~git/.ssh/authorized_keys
file, verify commands, and create repositories with the
update-paranoid hook installed by default.  Too bad I couldn't get
them to let me open that code.

Security wise its the same as signing commits, except the only
way to verify commits are valid is to fetch them from the central,
trusted server.  If you get commits via any other path they cannot
be verified.  In a corporate setting this may be sufficient.  In an
open source setting its less so, as you want to avoid that central
point of failure.

> I got the impression from that
> thread
> that if a patch to implement it were submitted then it would probably
> get
> accepted.

Its possible.  I think some of the preconditions to it being accepted
would be:

- It must be off by default.

- It must be configured on by default per-project, via .git/config.

- It should be able to be a command line option to git-commit,
  like the current --signoff flag, so users can actively choose to
  activate it on a per-commit basis.

- It should be able to optionally use a GnuPG agent so keys can
  be unlocked in memory and used for signing without typing your
  password on every commit.

A problem with signed commits is you obviously cannot cherry-pick
them, or apply them with git-am, as the committer portion of the
commit should be incorporated into the signature calculation.

So maybe also:

- git format-patch / log --format=email must strip the signature
  as the output cannot be verified.

- cherry-pick must strip the signature when picking the commit.

- rebase -i must strip the signature when squashing commits together
  and one or more of them are signed.

- all three rebase implementations should support stripping or
  resigning all commits in the series it is rebasing.

But as I think about it more, if you signed the diff, excluding the
line offsets in the hunk headers (so file paths, context and -/+
lines), the "author" line and the message, leaving out the other
fields of the commit message, it may be possible to still include
the signature in an email formatted patch and carry it through a
"git format-patch | git am" pipeline and still have it verify.

> I have a few questions:
> 
>   1) Is that actually the case at present? I ask to avoid doing the work
> and
>      having it rejected.

Its difficult to guage rejection without seeing the code behind it
and considering the consequences of including that code.  A lot
of these hypothetical discussions start out with a question like
this, raise some good points, and then folks are waiting to see it
implemented, but no code comes about.

It may be faster to prototype this out in Perl or shell with a
very simple "git signcommit" sort of tool, so people can experiment
with the concept and see what works before committing to a longer
implementation that integrates it into the git core tools.

If you really want to try to implement this I would encourage you
to make an extremely simple "git signcommit" tool that doesn't
implement all of the git commit features, but that does provide
the signing system.  Here's a start:

  #!/bin/sh
  . git-sh-setup
  git status >.git/COMMIT_EDITMSG
  git_editor .git/COMMIT_EDITMSG
  tree=$(git write-tree) || die "write tree failed"
  raw=$(git commit-tree $tree -p HEAD <.git/COMMIT_EDITMSG)
  raw=$((cat .git/COMMIT_EDITMSG; git cat-file commit $raw | gpg -s)\
        | git commit-tree $tree -p HEAD)
  git update-ref HEAD $raw

Crude as heck, and maybe my gpg -s call isn't quite right, but
that's a basic git commit tool that you can experiment with.
 
>   2) If it were accepted into Git, would an equivalent patch be accepted
> into
>      jgit? Would patches for UI to use it be accepted into egit?

Yes, absolutely, so long as the implementation in Java was reasonably
sane.  E.g. we'd prefer you used a pure Java implementation of
GnuPG, rather than say forking out to a Python script that execs
some Haskell program to use a SOAP RPC to a remote signing service
written in Tcl... ;-)
 
-- 
Shawn.

RE: Implementing commit signing

[Balasubramaniam, Arunan]

Shawn,

thank you for such a detailed reply. I only have a few points:

Shawn O. Pearce wrote:
> "Balasubramaniam, Arunan" <Arunan.Balasubramaniam@misys.com> wrote:
> > I am looking at using Git within our organisation, and verifying the
> > source of
> > commits has been raised as a concern. GPG signing individual commits
has
> > been
> > discussed at least once on this list [1].
> 
> Another approach is to use a central Git server with SSH
> key authentication and install into every repository the
> contrib/hooks/update-paranoid hook as $GIT_DIR/hooks/update.
> This is actually what I did at my prior day-job.

We had looked at this sort of approach but are not hugely in favour of
it.
Engineers here operate in teams, with the work integrated and sent into
the
central repository by one person at regular intervals. We are leaning
toward
using our repositories in the same sort of manner. This is actually one
of
our reasons to move to DVCS. This is not to say we would not use a
central
server if it turned out to be our best option.

> But as I think about it more, if you signed the diff, excluding the
> line offsets in the hunk headers (so file paths, context and -/+
> lines), the "author" line and the message, leaving out the other
> fields of the commit message, it may be possible to still include
> the signature in an email formatted patch and carry it through a
> "git format-patch | git am" pipeline and still have it verify.

Would this be dangerous? If you were to leave out the parent fields in
the commit message, surely you could then reapply an old commit (that
say introduced a bug)?

> Its difficult to guage rejection without seeing the code behind it
> and considering the consequences of including that code.  A lot
> of these hypothetical discussions start out with a question like
> this, raise some good points, and then folks are waiting to see it
> implemented, but no code comes about.

I hope I disclaimed enough that I'm not promising to do it :) As much as
it
does interest me, we may end up using the centralised server model you
talked about or cleaning up the prototype I've been playing with that
amends
commits to add signature blocks or something else that suits. I am going
to
present some options to a higher power to decide what happens.

> >   2) If it were accepted into Git, would an equivalent patch be
accepted
> > into
> >      jgit? Would patches for UI to use it be accepted into egit?
> 
> Yes, absolutely, so long as the implementation in Java was reasonably
> sane.  E.g. we'd prefer you used a pure Java implementation of
> GnuPG, rather than say forking out to a Python script that execs
> some Haskell program to use a SOAP RPC to a remote signing service
> written in Tcl... ;-)

I don't think that there is a Java GPG implementation about, some
searching
didn't find any live looking projects . Would a JNI wrapper to say GPGME
(http://www.gnupg.org/related_software/gpgme/index.en.html) be
acceptable?

Thanks again,
Arunan


"Misys" is the trade name for Misys plc (registered in England and Wales). Registration Number: 01360027. Registered office: One Kingdom Street, London W2 6BL, United Kingdom. For a list of Misys group operating companies please go to http://www.misys.com/html/about_us/group_operating_companies/. This email and any attachments have been scanned for known viruses using multiple scanners. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys plc. Please refer to the executed contract betw
 een you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing. 

Re: Implementing commit signing

[Shawn O. Pearce]

"Balasubramaniam, Arunan" <Arunan.Balasubramaniam@misys.com> wrote:
> Shawn O. Pearce wrote:
> 
> > But as I think about it more, if you signed the diff, excluding the
> > line offsets in the hunk headers (so file paths, context and -/+
> > lines), the "author" line and the message, leaving out the other
> > fields of the commit message, it may be possible to still include
> > the signature in an email formatted patch and carry it through a
> > "git format-patch | git am" pipeline and still have it verify.
> 
> Would this be dangerous? If you were to leave out the parent fields in
> the commit message, surely you could then reapply an old commit (that
> say introduced a bug)?

Well, the idea was to sign the diff, but in a way that would
reasonably allow it to be applied with limited fuzz, such as what
git-apply would accept.  Thus signed changes could be emailed out
by git format-patch and git send-email, and applied with git am,
and the signature is still valid so long as the committer didn't
mess with the patch.

Obviously if a commit was reverted and then reapplied again later,
yes, the signature on the reapply may actually be valid, as the
parents weren't taken into consideration.

If the format-patch output was modified to include the parent when
the signature was included then git am could be trained to verify
HEAD == parent before applying the commit.  Then you can include
the parent as part of the signature, but still enable a format-patch
and am based workflow.
 
> > Yes, absolutely, so long as the implementation in Java was reasonably
> > sane.  E.g. we'd prefer you used a pure Java implementation of
> > GnuPG
> 
> I don't think that there is a Java GPG implementation about, some
> searching
> didn't find any live looking projects .

Bouncy Castle:  http://www.bouncycastle.org/java.html

> Would a JNI wrapper to say GPGME
> (http://www.gnupg.org/related_software/gpgme/index.en.html) be
> acceptable?

No, JNI isn't "pure Java".

-- 
Shawn.

RE: Implementing commit signing

[Balasubramaniam, Arunan]

Shawn O. Pearce wrote:
> Well, the idea was to sign the diff, but in a way that would
> reasonably allow it to be applied with limited fuzz, such as what
> git-apply would accept.  Thus signed changes could be emailed out
> by git format-patch and git send-email, and applied with git am,
> and the signature is still valid so long as the committer didn't
> mess with the patch.
> 
> Obviously if a commit was reverted and then reapplied again later,
> yes, the signature on the reapply may actually be valid, as the
> parents weren't taken into consideration.

I have realized I have been mixing things up; I was talking about
authors but mostly thinking about committers. The solution you
proposed tracked the author, so my question about it being
reapplied was a bit meaningless since the signature did not say
anything about the committer. My apologies.

As with having separate author and committer fields, would it make
sense to allow author and committer signatures? Just leaving aside
the issue of how much text it would take up for now, the committer's
signature could be created as tag signatures are, while the
author's could be as you originally described and would track the
content. If it reapplied to a different parent, then the signature
would be OK, but the committer would be listed as the one who
reapplied it. This would match how rebase works.

A project operating like the Linux kernel with patches only pulled
and emailed might use the author signature without the committer
one. I don't think there is any case for committer signing only.

If you ever merged or rebased, you automatically strip any committer
signature. If the operation succeeds, and the diff against the
parent matches the original diff, you could reuse the original
author signature.

Arunan


"Misys" is the trade name for Misys plc (registered in England and Wales). Registration Number: 01360027. Registered office: One Kingdom Street, London W2 6BL, United Kingdom. For a list of Misys group operating companies please go to http://www.misys.com/html/about_us/group_operating_companies/. This email and any attachments have been scanned for known viruses using multiple scanners. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys plc. Please refer to the executed contract betw
 een you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing.