{"thread":{"id":"15837","subject":"RE: Implementing commit signing","startedAt":"2008-10-09T17:53:03Z","lastAt":"2008-10-09T18:00:26Z","messageCount":2,"participants":["Balasubramaniam, Arunan","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"92689","messageId":"E74D836C8B2CEF4A89F47E8ACECEEF9B748DCD@maildub1.misys.global.ad","threadId":"15837","inReplyTo":null,"subject":"RE: Implementing commit signing","fromName":"Balasubramaniam, Arunan","fromEmail":"arunan.balasubramaniam@misys.com","sentAt":"2008-10-09T17:53:03Z","receivedAt":"2008-10-09T17:53:03Z","isPatch":false,"sender":{"key":"arunan.balasubramaniam@misys.com","avatar":null},"body":"Shawn,\n\nthank you for such a detailed reply. I only have a few points:\n\nShawn O. Pearce wrote:\n> \"Balasubramaniam, Arunan\" <Arunan.Balasubramaniam@misys.com> wrote:\n> > I am looking at using Git within our organisation, and verifying the\n> > source of\n> > commits has been raised as a concern. GPG signing individual commits\nhas\n> > been\n> > discussed at least once on this list [1].\n> \n> Another approach is to use a central Git server with SSH\n> key authentication and install into every repository the\n> contrib/hooks/update-paranoid hook as $GIT_DIR/hooks/update.\n> This is actually what I did at my prior day-job.\n\nWe had looked at this sort of approach but are not hugely in favour of\nit.\nEngineers here operate in teams, with the work integrated and sent into\nthe\ncentral repository by one person at regular intervals. We are leaning\ntoward\nusing our repositories in the same sort of manner. This is actually one\nof\nour reasons to move to DVCS. This is not to say we would not use a\ncentral\nserver if it turned out to be our best option.\n\n> But as I think about it more, if you signed the diff, excluding the\n> line offsets in the hunk headers (so file paths, context and -/+\n> lines), the \"author\" line and the message, leaving out the other\n> fields of the commit message, it may be possible to still include\n> the signature in an email formatted patch and carry it through a\n> \"git format-patch | git am\" pipeline and still have it verify.\n\nWould this be dangerous? If you were to leave out the parent fields in\nthe commit message, surely you could then reapply an old commit (that\nsay introduced a bug)?\n\n> Its difficult to guage rejection without seeing the code behind it\n> and considering the consequences of including that code.  A lot\n> of these hypothetical discussions start out with a question like\n> this, raise some good points, and then folks are waiting to see it\n> implemented, but no code comes about.\n\nI hope I disclaimed enough that I'm not promising to do it :) As much as\nit\ndoes interest me, we may end up using the centralised server model you\ntalked about or cleaning up the prototype I've been playing with that\namends\ncommits to add signature blocks or something else that suits. I am going\nto\npresent some options to a higher power to decide what happens.\n\n> >   2) If it were accepted into Git, would an equivalent patch be\naccepted\n> > into\n> >      jgit? Would patches for UI to use it be accepted into egit?\n> \n> Yes, absolutely, so long as the implementation in Java was reasonably\n> sane.  E.g. we'd prefer you used a pure Java implementation of\n> GnuPG, rather than say forking out to a Python script that execs\n> some Haskell program to use a SOAP RPC to a remote signing service\n> written in Tcl... ;-)\n\nI don't think that there is a Java GPG implementation about, some\nsearching\ndidn't find any live looking projects . Would a JNI wrapper to say GPGME\n(http://www.gnupg.org/related_software/gpgme/index.en.html) be\nacceptable?\n\nThanks again,\nArunan\n\n\n\"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\n een you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing. \n"},{"id":"92690","messageId":"20081009180026.GX8203@spearce.org","threadId":"15837","inReplyTo":"E74D836C8B2CEF4A89F47E8ACECEEF9B748DCD@maildub1.misys.global.ad","subject":"Re: Implementing commit signing","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-10-09T18:00:26Z","receivedAt":"2008-10-09T18:00:26Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Balasubramaniam, Arunan\" <Arunan.Balasubramaniam@misys.com> wrote:\n> Shawn O. Pearce wrote:\n> \n> > But as I think about it more, if you signed the diff, excluding the\n> > line offsets in the hunk headers (so file paths, context and -/+\n> > lines), the \"author\" line and the message, leaving out the other\n> > fields of the commit message, it may be possible to still include\n> > the signature in an email formatted patch and carry it through a\n> > \"git format-patch | git am\" pipeline and still have it verify.\n> \n> Would this be dangerous? If you were to leave out the parent fields in\n> the commit message, surely you could then reapply an old commit (that\n> say introduced a bug)?\n\nWell, the idea was to sign the diff, but in a way that would\nreasonably allow it to be applied with limited fuzz, such as what\ngit-apply would accept.  Thus signed changes could be emailed out\nby git format-patch and git send-email, and applied with git am,\nand the signature is still valid so long as the committer didn't\nmess with the patch.\n\nObviously if a commit was reverted and then reapplied again later,\nyes, the signature on the reapply may actually be valid, as the\nparents weren't taken into consideration.\n\nIf the format-patch output was modified to include the parent when\nthe signature was included then git am could be trained to verify\nHEAD == parent before applying the commit.  Then you can include\nthe parent as part of the signature, but still enable a format-patch\nand am based workflow.\n \n> > Yes, absolutely, so long as the implementation in Java was reasonably\n> > sane.  E.g. we'd prefer you used a pure Java implementation of\n> > GnuPG\n> \n> I don't think that there is a Java GPG implementation about, some\n> searching\n> didn't find any live looking projects .\n\nBouncy Castle:  http://www.bouncycastle.org/java.html\n\n> Would a JNI wrapper to say GPGME\n> (http://www.gnupg.org/related_software/gpgme/index.en.html) be\n> acceptable?\n\nNo, JNI isn't \"pure Java\".\n\n-- \nShawn.\n"}]}