{"thread":{"id":"15836","subject":"Implementing commit signing","startedAt":"2008-10-09T14:03:10Z","lastAt":"2008-10-09T15:44:09Z","messageCount":2,"participants":["Balasubramaniam, Arunan","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"92676","messageId":"E74D836C8B2CEF4A89F47E8ACECEEF9B748C75@maildub1.misys.global.ad","threadId":"15836","inReplyTo":null,"subject":"Implementing commit signing","fromName":"Balasubramaniam, Arunan","fromEmail":"arunan.balasubramaniam@misys.com","sentAt":"2008-10-09T14:03:10Z","receivedAt":"2008-10-09T14:03:10Z","isPatch":false,"sender":{"key":"arunan.balasubramaniam@misys.com","avatar":null},"body":"\nHello,\n\nI am looking at using Git within our organisation, and verifying the\nsource of\ncommits has been raised as a concern. GPG signing individual commits has\nbeen\ndiscussed at least once on this list [1]. I got the impression from that\nthread\nthat if a patch to implement it were submitted then it would probably\nget\naccepted. I have a few questions:\n\n  1) Is that actually the case at present? I ask to avoid doing the work\nand\n     having it rejected.\n\n  2) If it were accepted into Git, would an equivalent patch be accepted\ninto\n     jgit? Would patches for UI to use it be accepted into egit?\n\nI can not promise that we will actually write this patch as I am going\nto\npresent it internally as one option and using hooks scripts as another,\nbut it\nwould be more likely to happen if there were positive answers to those\nquestions. \n\nThanks,\nArunan Bala\n\n[1] http://kerneltrap.org/mailarchive/git/2007/1/15/235839/thread\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":"92681","messageId":"20081009154409.GU8203@spearce.org","threadId":"15836","inReplyTo":"E74D836C8B2CEF4A89F47E8ACECEEF9B748C75@maildub1.misys.global.ad","subject":"Re: Implementing commit signing","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-10-09T15:44:09Z","receivedAt":"2008-10-09T15:44:09Z","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> 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 has\n> been\n> discussed at least once on this list [1].\n\nAnother approach is to use a central Git server with SSH\nkey authentication and install into every repository the\ncontrib/hooks/update-paranoid hook as $GIT_DIR/hooks/update.\nThis is actually what I did at my prior day-job.\n\nThe update-paranoid hook scrapes all new incoming commits and\nverifies the \"committer\" line matches the name and email address\nassociated with the user who is executing the \"git push\".\n\nIf you use this under something like say \"Gitosis\" then users don't\neven need direct UNIX access.  The SSH public keys are installed\ninto a common user account, and the user is only allowed to start\nthe Gitosis wrapper.  The wrapper verifies the command is only a\ngit server request, then starts Git.  The update hook can then use\ndata from Gitosis to verify the committer lines.\n\nActually at prior day-job we wrote our own scripts to do this, and\ndidn't use Gitosis at all.  If I recall correclty it was about 200\nlines of Perl to automatically manage the ~git/.ssh/authorized_keys\nfile, verify commands, and create repositories with the\nupdate-paranoid hook installed by default.  Too bad I couldn't get\nthem to let me open that code.\n\nSecurity wise its the same as signing commits, except the only\nway to verify commits are valid is to fetch them from the central,\ntrusted server.  If you get commits via any other path they cannot\nbe verified.  In a corporate setting this may be sufficient.  In an\nopen source setting its less so, as you want to avoid that central\npoint of failure.\n\n> I got the impression from that\n> thread\n> that if a patch to implement it were submitted then it would probably\n> get\n> accepted.\n\nIts possible.  I think some of the preconditions to it being accepted\nwould be:\n\n- It must be off by default.\n\n- It must be configured on by default per-project, via .git/config.\n\n- It should be able to be a command line option to git-commit,\n  like the current --signoff flag, so users can actively choose to\n  activate it on a per-commit basis.\n\n- It should be able to optionally use a GnuPG agent so keys can\n  be unlocked in memory and used for signing without typing your\n  password on every commit.\n\nA problem with signed commits is you obviously cannot cherry-pick\nthem, or apply them with git-am, as the committer portion of the\ncommit should be incorporated into the signature calculation.\n\nSo maybe also:\n\n- git format-patch / log --format=email must strip the signature\n  as the output cannot be verified.\n\n- cherry-pick must strip the signature when picking the commit.\n\n- rebase -i must strip the signature when squashing commits together\n  and one or more of them are signed.\n\n- all three rebase implementations should support stripping or\n  resigning all commits in the series it is rebasing.\n\nBut as I think about it more, if you signed the diff, excluding the\nline offsets in the hunk headers (so file paths, context and -/+\nlines), the \"author\" line and the message, leaving out the other\nfields of the commit message, it may be possible to still include\nthe 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> I have a few questions:\n> \n>   1) Is that actually the case at present? I ask to avoid doing the work\n> and\n>      having it rejected.\n\nIts difficult to guage rejection without seeing the code behind it\nand considering the consequences of including that code.  A lot\nof these hypothetical discussions start out with a question like\nthis, raise some good points, and then folks are waiting to see it\nimplemented, but no code comes about.\n\nIt may be faster to prototype this out in Perl or shell with a\nvery simple \"git signcommit\" sort of tool, so people can experiment\nwith the concept and see what works before committing to a longer\nimplementation that integrates it into the git core tools.\n\nIf you really want to try to implement this I would encourage you\nto make an extremely simple \"git signcommit\" tool that doesn't\nimplement all of the git commit features, but that does provide\nthe signing system.  Here's a start:\n\n  #!/bin/sh\n  . git-sh-setup\n  git status >.git/COMMIT_EDITMSG\n  git_editor .git/COMMIT_EDITMSG\n  tree=$(git write-tree) || die \"write tree failed\"\n  raw=$(git commit-tree $tree -p HEAD <.git/COMMIT_EDITMSG)\n  raw=$((cat .git/COMMIT_EDITMSG; git cat-file commit $raw | gpg -s)\\\n        | git commit-tree $tree -p HEAD)\n  git update-ref HEAD $raw\n\nCrude as heck, and maybe my gpg -s call isn't quite right, but\nthat's a basic git commit tool that you can experiment with.\n \n>   2) If it were accepted into Git, would an equivalent patch be accepted\n> into\n>      jgit? Would patches for UI to use it be accepted into egit?\n\nYes, absolutely, so long as the implementation in Java was reasonably\nsane.  E.g. we'd prefer you used a pure Java implementation of\nGnuPG, rather than say forking out to a Python script that execs\nsome Haskell program to use a SOAP RPC to a remote signing service\nwritten in Tcl... ;-)\n \n-- \nShawn.\n"}]}