RE: Implementing commit signing

Shawn,

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

Shawn O. Pearce wrote:

"Balasubramaniam, Arunan" [off-list ref] wrote:

quoted

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

quoted

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.

quoted

  2) If it were accepted into Git, would an equivalent patch be

accepted

quoted

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. 

"Balasubramaniam, Arunan" [off-list ref] wrote:

Shawn O. Pearce wrote:

quoted

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.
 

quoted

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.