Shawn, thank you for such a detailed reply. I only have a few points: Shawn O. Pearce wrote: > "Balasubramaniam, Arunan" <Arunan.Balasubramaniam@xxxxxxxxx> 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 between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
