{"thread":{"id":"18707","subject":"GPG signing for git commit?","startedAt":"2009-04-03T21:25:54Z","lastAt":"2009-05-11T10:39:38Z","messageCount":17,"participants":["Chow Loong Jin","Linus Torvalds","Sam Vilain","Jakub Narebski","Robin H. Johnson","Shawn O. Pearce","Sitaram Chamarty","Jeff King","Nguyen Thai Ngoc Duy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"110312","messageId":"1238793954.19982.14.camel@hyperair-laptop","threadId":"18707","inReplyTo":null,"subject":"GPG signing for git commit?","fromName":"Chow Loong Jin","fromEmail":"hyperair@gmail.com","sentAt":"2009-04-03T21:25:54Z","receivedAt":"2009-04-03T21:25:54Z","isPatch":false,"sender":{"key":"hyperair@gmail.com","avatar":null},"body":"Hi,\n\nIt crossed my mind that currently git commits cannot actually be\nverified to be authentic, due to the fact that I can just set my\nidentity to be someone else, and then commit under their name. During\ndiscussion on #git, Ilari, context and I figured that it would be a good\nidea to get GPG signing on git commits, considering that git-tag already\nhas GPG signing support.\n\nAttached is the transcript of the log, with some irrelevant bits chopped\nout. Log is dated Sat, April 4, and timezone GMT +0800.\n\n-- \nChow Loong Jin\n\n\n04:35 hmm i've always wondered... is it possible to create commits under someone else's name and then push it to a git server? if it is, how does one prevent that from happening?\n04:35 s/git server/git repo/\n04:36 hyperair: Sure it is.\n04:36 hyperair: GIT_COMMITTER_NAME=\"Someone Else\" git commit\n04:36 UUncia: It has capability to transfer commits between repositories. Pushing (transfer to another repository), Fetching (transfer from another repository, clone/pull are built on top) and sneakernet commit transport are all supported.\n04:36 Ilari, wereHamster: yeah i thought so, but how do you prevent someone from pushing to a git repo under your name?\n04:36 hyperair: you'd have to have hooks on the server side that check the commiter name\n04:36 ah i see\n04:37 hyperair: Then there are situations where one legimately needs to push commit with some oddball committer name.\n04:37 hyperair: also note that git distinguishes between committer and author\n04:37 wereHamster: committer and author?\n04:38 wereHamster: what's the difference?\n04:38 hyperair: author is the person who wrote the patch, committer is the person who created the commit\n04:38 so if someone sends you a patch, he/she is the author but you are the committer\n04:38 wereHamster: how does git tell the difference?\n04:39 wereHamster: also, supposing you weren't working by passing patches around, but rather by pushing to a main project repository, what's to stop one committer from committing under another person's name and shoving all the blame onto him?\n04:39 the authors are like physics students\n04:39 or her?\n04:39 and the commiters are rocket scientests\n04:40 I think by looking at the patch headers (assuming it's sent in mbox format)\n04:40 hyperair: nothing.\n04:40 context: bit insecure don't you think?\n04:40 hyperair: there is no way to stop it. you gave them commit access, you trust them enough\n04:41 there is a way to stop it: don't give them committ access ;)\n04:41 werehamster: ;)\n04:41 wereHamster: you mean push access =p\n04:41 hyperair: There are cases like: I work on some feature. I complete it and send pull request to somebody who has push privs to main repo. They pull it and since its up to date, it results fast forward. Then they push it. Again, its up to date so push succeeds. Now you have wound up with situation where topmost commit claims (correctly) that I committed it.\n04:41 hyperair: unless you have a propsel on how to stop it\n04:42 There isn't really a way to stop it.\n04:42 hyperair: You could use hooks to keep logs about who pushed what.\n04:42 i see\n04:42 Even if there were, there's nothing preventing someone else from setting their identity to you.\n04:42 ilari: that still doesnt work.\n04:42 ilari: say i pull from you, merge my changes with yours, then merge into master and push to repo\n04:43 how do you track the branch i pulled form you is really from you.\n04:43 how about gpg signing every commit =p\n04:43 context: Both \"merges\" are fast forwards by assumption there.\n04:43 just like how tags can be signed, how about signing them commits\n04:43 hyperair: that would work.\n04:43 ilari: no i mean merge as in merge.\n04:43 hyperair: Its just impractical with current tools.\n04:44 Ilari: yeah it's impractical, but if you git git-commit signing capabilities similar to taht of git-tag's i'm sure it would work\n04:44 Ilari: and become practical.\n04:44 context: Unless you explicitly ask, merge when presented with situation where one of branches is in future of another will make fast forward without any new commits.\n04:45 hyperair: There are even hacks that authenticate pushing to git:// by using signed tags.\n04:46 Ilari: what hacks are those?\n04:46 hyperair: They essentially implement push authentication on top of git://\n04:46 hyperair: Not very helpful, because ssh usually does it better.\n04:46 yeah i thought so\n04:47 hyperair: And as tip: If you want to keep logs, current version of gitosis (last I checked) can not be used in such applications without modification.\n04:48 Ilari: what's gitosis?\n04:48 hyperair: Software that makes admining repo permissions in group settings easier.\n04:48 hmm interesting\n04:49 Sometimes I wish I could annotate a branch. Leave a comment on the branch itself that explains why I made it...\n04:49 hyperair: Usually very good. But its lack of exported user identity (unless you can hack it in) is absolute showstopper if you need to keep push logs.\n04:49 hmm\n04:50 hyperair: But its one line change AFAICS...\n04:50 interesting\n04:50 Dashkal: self-explanatory names ftw.\n04:51 ilari: yes i know\n04:51 <-- not new to git\n04:59 hyperair: only way to trust a commit would be gpg signatures\n04:59 Ilari: oh? Might have to hunt through git.git for it\n04:59 Dashkal: pu has it.\n04:59 nifty, danke\n04:59 but i dont think you can gpg sign all commits can you\n04:59 not to mention typing in that passwd every commit would SUCK !\n04:59 context: yes of course, but git commit doesn't have gpg support.\n04:59 Dashkal: Next doesn't. But beware that pu begins to be actually unstable.\n04:59 context: ever heard of a gpg agent?\n05:00 hyperair: yes. firegpg uses it so i dont have to type it in for every email i send from gmail\n05:00 Ilari: Yeah, I'm kind of afraid of pu as a whole, but if I can find the relivant commits I can bring just that in\n05:00 gmail + gpg = win\n05:00 i use evolution.\n05:00 hyperair: another ewe.\n05:00 ;)\n05:00 * hyperair wonders what ewe is\n05:01 'icky' growse\n05:01 hyperair: Gpg signing doesn't really work if you have external contributors that can request pull unless you force non-ff merge somewhere.\n05:01 i don't think it comes with a trailing e\n05:01 ilari: eh?\n05:01 hyperair: ill have to update my dictionary\n05:01 Ilari: the main point is that you make your commits be verifiable, so that nobody can pretend to commit as you.\n05:02 hyperair: use svn, ;)\n05:02 * hyperair barfs on context \n05:02 context: Blasphemer!\n05:02 hyperair: Well, if you need identifying of main contributors only.\n05:02 * context hides\n05:02 hyperair: So no one spoofs them. But it doesn't protect others.\n05:02 ilari: actually it wouldnt be too hard. if commit's could be sign\n05:02 Ilari: yeah true.\n05:03 trusted users could add their finger print to like a ~/.gitfinger file\n05:03 people WOULD notice if that gets changed\n05:03 and you could have like a git fetch-gpg-keys\n05:03 hahah\n05:03 i think we should file that as a feature request =p\n05:03 if tags can be signed, why not commits? =p\n05:04 hyperair: Both even have similar structure. Header fields plus freeform text section.\n05:04 hyperair: The text section is even fully 8-bit clean.\n05:04 awesome. so let's have it signed =p\n05:05 hyperair: Since it starts immediately after first 0A0Ah sequence in object and continues to end of object. And objects need to be 8-bit clean to store binary files in blobs.\n05:05 hyperair: then you need to worry about an author signature, AND commiters signature\n05:05 and diff's might be even more funky\n05:06 but it would be an awesome feature\n05:06 context: diffs can have headers and footers. so a clearsign would be fine\n05:06 If you care only about protecting main authors, committer signature is enough.\n05:06 What if gpg on commit was only used when the --signoff option was selected?\n05:07 It also has simplifying factor that signing headers plus rest of commit message is enough.\n05:07 Circuitsoft: that would be awesome, but as far as i can tell, it isn't used atm\n05:07 now then are there any git devs we can propose this to? =p\n05:07 <-- gets all credit\n05:07 and his million dollar prize\n05:08 lol\n05:08 hyperair: Send idea to mailinglist. The official policy is essentially that altough this channel has archives, for development purposes discussions here never happned.\n"},{"id":"110313","messageId":"alpine.LFD.2.00.0904031535140.3915@localhost.localdomain","threadId":"18707","inReplyTo":"1238793954.19982.14.camel@hyperair-laptop","subject":"Re: GPG signing for git commit?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-04-03T22:54:10Z","receivedAt":"2009-04-03T22:54:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 4 Apr 2009, Chow Loong Jin wrote:\n> \n> It crossed my mind that currently git commits cannot actually be\n> verified to be authentic, due to the fact that I can just set my\n> identity to be someone else, and then commit under their name.\n\nYou can't do that.\n\nWell, you can, but it's always going to be inferior to just adding a tag. \n\nThe thing is, what is it you want to protect? The tree, the authorship, \nthe committer info, the commit log, what?\n\nAnd it really does matter. Because the signature must be over some part of \nthe commit, and since the SHA1 of the commit by definition contains \neverything, then the _safest_ thing is always to sign the SHA1 itself: \nthus a tag.\n\nAnything else is always bound to only sign a _part_ of the commit. What \npart do you feel like protecting? Or put another way, what part do you \nfeel like _not_ protecting?\n\nSo the way git does signatures protects everything. When you do a tag with \n\"git tag -s\" on a commit, you can absolutely _know_ that nobody will ever \nmodify that commit in any way without the tag signature becoming invalid. \n\nAnd perhaps equally interestingly, that signature is now also easily \nseparable from the history - which is interesting if you want to \ndistribute your cryptographic parts separately (for example, you only use \nit _internally_ within a company or group, to mark some group-specific \nissues).\n\nAlso, related to that \"separable\" - the person signing on something is not \nnecessarily the person marked as author, or even committing it anyway. One \nof the guiding goals for git was always that it should work well with \n\"outside\" flows, ie others passing patches around or using other SCM's to \nmanage their own flow. \n\nFinally, on that same \"separable\" notion - imagine a big rewrite operation \nfor whatever reason - like a big import into git, or a project re-writing \ntheir history because they ended up importing more history from old \nsources (or because they wanted to split a big project into subprojects). \nAll of those invalidate any cryptographic signatures.\n\nAnd all of those are events that you may still want to _update_ the \nsignatures, but do you want to trust the one doing the conversion with the \nprivate keys? Obviously not. You could \"wrap\" the signing in a new \n\"conversion signature\", and have a signature to try to imply that the \nperson doing the conversion \"signs\" the conversion. But the fact is, that \ndoesn't mean the same thing.\n\nWith separate signatures (ie the \"git tag -s\" model), you can ask the \npeople who signed the original repository to consider re-signing the \nrewritten one. See? Safe, flexible, and much superior.\n\nThe exact same thing goes for keys that get invalidated because they ended \nup being shown to be too weak or just flawed some other way, btw. That is \na reason to re-sign, _without_ the repository necessarily changing.\n\nYou can do _none_ of these things sanely if you put the signatures into \nthe commits themselves. \n\nSo don't do it.\n\nBtw, there's a final reason, and probably the really real one. Signing \neach commit is totally stupid. It just means that you automate it, and you \nmake the signature worth less. It also doesn't add any real value, since \nthe way the git DAG-chain of SHA1's work, you only ever need _one_ \nsignature to make all the commits reachable from that one be effectively \ncovered by that one. So signing each commit is simply missing the point. \n\nIOW, you don't _ever_ have a reason to sign anythign but the \"tip\". The \nonly exception is the \"go back and re-sign\", but that's the one that \nrequires external signatures anyway.\n\nSo be happy with 'git tag -s'. It really is the right way.\n\n\t\tLinus\n"},{"id":"110518","messageId":"49D99BB2.2090906@vilain.net","threadId":"18707","inReplyTo":"alpine.LFD.2.00.0904031535140.3915@localhost.localdomain","subject":"Re: GPG signing for git commit?","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2009-04-06T06:05:38Z","receivedAt":"2009-04-06T06:05:38Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Linus Torvalds wrote:\n> On Sat, 4 Apr 2009, Chow Loong Jin wrote:\n> \n>> It crossed my mind that currently git commits cannot actually be\n>> verified to be authentic, due to the fact that I can just set my\n>> identity to be someone else, and then commit under their name.\n>> \n>\n> You can't do that.\n>\n> Well, you can, but it's always going to be inferior to just adding a tag. \n>\n> The thing is, what is it you want to protect? The tree, the authorship, \n> the committer info, the commit log, what?\n> \n[...]\n> Btw, there's a final reason, and probably the really real one. Signing \n> each commit is totally stupid. It just means that you automate it, and you \n> make the signature worth less. It also doesn't add any real value, since \n> the way the git DAG-chain of SHA1's work, you only ever need _one_ \n> signature to make all the commits reachable from that one be effectively \n> covered by that one. So signing each commit is simply missing the point. \n>\n> IOW, you don't _ever_ have a reason to sign anythign but the \"tip\". The \n> only exception is the \"go back and re-sign\", but that's the one that \n> requires external signatures anyway.\n>\n> So be happy with 'git tag -s'. It really is the right way.\n> \n\nLinus I agree with these points - I'd just like to point you to the new\nmirror-sync design document. Under Documentation/git-mirror-sync.txt on\nhttp://github.com/samv/git/tree/mirror-sync - and an implementation plan\noutlined in Documentation/git-mirror-sync-impl.txt\n\nThis system allows for *pushes* to be signed and in general laying the\nfoundation for knowing that commits are authentic without the intrusion\ninto the refs/tags/* space that making lots of signed tags would imply.\nThe idea is to put 'packed-refs' contents (or a moral equivalent) in tag\nbodies. It is really a new type of object, but it's sufficiently similar\nto a tag that I thought I'd just go and go with that design for now.\nAnyway if you're curious take a look, otherwise wait for the formal\nsubmission once I've got something better together...\n\nSam\n"},{"id":"110720","messageId":"m3ljqc1h55.fsf@localhost.localdomain","threadId":"18707","inReplyTo":"alpine.LFD.2.00.0904031535140.3915@localhost.localdomain","subject":"Re: GPG signing for git commit?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-04-07T17:55:01Z","receivedAt":"2009-04-07T17:55:01Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds writes:\n\n> On Sat, 4 Apr 2009, Chow Loong Jin wrote:\n> > \n> > It crossed my mind that currently git commits cannot actually be\n> > verified to be authentic, due to the fact that I can just set my\n> > identity to be someone else, and then commit under their name.\n\n[...]\n> Btw, there's a final reason, and probably the really real one. Signing \n> each commit is totally stupid. It just means that you automate it, and you \n> make the signature worth less. It also doesn't add any real value, since \n> the way the git DAG-chain of SHA1's work, you only ever need _one_ \n> signature to make all the commits reachable from that one be effectively \n> covered by that one. So signing each commit is simply missing the point. \n> \n> IOW, you don't _ever_ have a reason to sign anythign but the \"tip\". The \n> only exception is the \"go back and re-sign\", but that's the one that \n> requires external signatures anyway.\n> \n> So be happy with 'git tag -s'. It really is the right way.\n\nAnd if you really, really need for some reason (for example\nrequirement checkpoint, or being paranoid enough) ned to have each and\nevery commit signed, you can use Monotone instead of Git. That is\nwhat we recommended IPsec (or something) on #git.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"110722","messageId":"alpine.LFD.2.00.0904071102450.27889@localhost.localdomain","threadId":"18707","inReplyTo":"m3ljqc1h55.fsf@localhost.localdomain","subject":"Re: GPG signing for git commit?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-04-07T18:04:25Z","receivedAt":"2009-04-07T18:04:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 7 Apr 2009, Jakub Narebski wrote:\n> \n> And if you really, really need for some reason (for example\n> requirement checkpoint, or being paranoid enough) ned to have each and\n> every commit signed, you can use Monotone instead of Git. That is\n> what we recommended IPsec (or something) on #git.\n\nYeah, well..\n\nThat's more of a \"If you really want to be incredibly slow, depend on an \nunbelievably baroque model, _and_ you are too stupid to understand the \nfact that you only need to sign the tip\", then use Monotone.\n\nBut yes, the \"sign each commit\" is one of the big design mistakes in \nMonotone. Go ask them about how much pain it has caused them.\n\n\t\t\tLinus\n"},{"id":"111392","messageId":"20090415185554.GG23644@curie-int","threadId":"18707","inReplyTo":"49D99BB2.2090906@vilain.net","subject":"Re: GPG signing for git commit?","fromName":"Robin H. Johnson","fromEmail":"robbat2@gentoo.org","sentAt":"2009-04-15T18:55:54Z","receivedAt":"2009-04-15T18:55:54Z","isPatch":false,"sender":{"key":"robbat2@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/373898?v=4"},"body":"On Mon, Apr 06, 2009 at 06:05:38PM +1200, Sam Vilain wrote:\n> This system allows for *pushes* to be signed and in general laying the\n> foundation for knowing that commits are authentic without the intrusion\n> into the refs/tags/* space that making lots of signed tags would imply.\nI'm on the lookout for something similar, so that we can be sure who\nintroduced some change into the central repo.\n\nOne of the spots that we're looking for in this, is a model something\nlike what follows. Firstly, a \"proxy maintainer\" (PM) is a developer\nwith commit rights to the central repo, that's willing to proxy commits\nby an outside source for some specific package. Think of them as the\nkernel subsystem maintainer, but many more of them. The PM is still\nexpected to verify the work before passing it on the central repo.\n\nSo we have a commit with author+committer being the outside source, and\nnow we want to record (in an easily reviewable fashion) that a specific\nchangeset was introduced to the central tree by the PM.\n\nNot sure of the best route to trace this data. Signing the SHA1 makes\nthe most sense, but need to be able to do that without polluting the tag\nnamespace.\n\nIf the changeset does not have an associated signature, we'd like to\nreject it at the central repo.\n\n-- \nRobin Hugh Johnson\nGentoo Linux Developer & Infra Guy\nE-Mail : robbat2@gentoo.org\nGnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85\n"},{"id":"111393","messageId":"20090415192054.GE23604@spearce.org","threadId":"18707","inReplyTo":"20090415185554.GG23644@curie-int","subject":"Re: GPG signing for git commit?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-04-15T19:20:54Z","receivedAt":"2009-04-15T19:20:54Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Robin H. Johnson\" wrote:\n> \n> One of the spots that we're looking for in this, is a model something\n> like what follows. Firstly, a \"proxy maintainer\" (PM) is a developer\n> with commit rights to the central repo, that's willing to proxy commits\n> by an outside source for some specific package. Think of them as the\n> kernel subsystem maintainer, but many more of them. The PM is still\n> expected to verify the work before passing it on the central repo.\n> \n> So we have a commit with author+committer being the outside source, and\n> now we want to record (in an easily reviewable fashion) that a specific\n> changeset was introduced to the central tree by the PM.\n> \n> Not sure of the best route to trace this data. Signing the SHA1 makes\n> the most sense, but need to be able to do that without polluting the tag\n> namespace.\n\nHave the PM push over SSH, and don't ever expire reflogs on the\ncentral repository? The reflog will have the old and new commits\nand the user name of the PM.\n\nDownsides are:\n\n- data is in the reflog on the central repository, to access it\n you need to expose that file via some non-git means (e.g. http\n or direct shell).\n\n- one reflog record may cover multiple commits, so looking up a\n single commit is very difficult. no current tools exist to merge\n the reflog back against the commit history to attach the record\n to a range of commits.\n\n- the reflog is a text file, it will get somewhat large with time.\n\n- the reflog is destroyed when the branch is deleted. you may need a\n hook to forbid deletion of critical branches, so the reflog stays.\n\n-- \nShawn.\n"},{"id":"111403","messageId":"20090415T220710Z@curie.orbis-terrarum.net","threadId":"18707","inReplyTo":"20090415192054.GE23604@spearce.org","subject":"Re: GPG signing for git commit?","fromName":"Robin H. Johnson","fromEmail":"robbat2@gentoo.org","sentAt":"2009-04-15T22:29:14Z","receivedAt":"2009-04-15T22:29:14Z","isPatch":false,"sender":{"key":"robbat2@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/373898?v=4"},"body":"On Wed, Apr 15, 2009 at 12:20:54PM -0700, Shawn O. Pearce wrote:\n> > Not sure of the best route to trace this data. Signing the SHA1 makes\n> > the most sense, but need to be able to do that without polluting the tag\n> > namespace.\n> Have the PM push over SSH, and don't ever expire reflogs on the\n> central repository? The reflog will have the old and new commits\n> and the user name of the PM.\nAll pushing to the central repo will be git+ssh:// anyway.\n\nI don't follow where the PM's identity is being stored, and how that's\ndistributed back out with the later pulls.\n\nThe other downside to relying on SSH presentation of identity directly,\nis the inability to use the SSH key to uniquely identify the user during\nthe SSH auth (see designs like gitosis, where you always push to\ngit+ssh://git@host/repo).\n\n-- \nRobin Hugh Johnson\nGentoo Linux Developer & Infra Guy\nE-Mail : robbat2@gentoo.org\nGnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85\n"},{"id":"111453","messageId":"20090416142728.GG23604@spearce.org","threadId":"18707","inReplyTo":"20090415T220710Z@curie.orbis-terrarum.net","subject":"Re: GPG signing for git commit?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-04-16T14:27:28Z","receivedAt":"2009-04-16T14:27:28Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Robin H. Johnson\" wrote:\n> On Wed, Apr 15, 2009 at 12:20:54PM -0700, Shawn O. Pearce wrote:\n> > > Not sure of the best route to trace this data. Signing the SHA1 makes\n> > > the most sense, but need to be able to do that without polluting the tag\n> > > namespace.\n> > Have the PM push over SSH, and don't ever expire reflogs on the\n> > central repository? The reflog will have the old and new commits\n> > and the user name of the PM.\n>\n> All pushing to the central repo will be git+ssh:// anyway.\n> \n> I don't follow where the PM's identity is being stored, and how that's\n> distributed back out with the later pulls.\n\nIts stored in the reflog for the branch; see \"git log -g branch\".\nTechnically the environment variable GIT_COMMITTER_NAME and\nGIT_COMMITTER_EMAIL is used to populate the identity into the reflog,\nbut if these aren't set then its guessed from the gecos information\nof the effective user.\n \n> The other downside to relying on SSH presentation of identity directly,\n> is the inability to use the SSH key to uniquely identify the user during\n> the SSH auth (see designs like gitosis, where you always push to\n> git+ssh://git@host/repo).\n\nUhm, yea. That's a fault of gitosis then. It knows the key that\nwas used, and has that mapped back to some token that identifies that\naccount in the configuration file. Why it doesn't push that into the\nGIT_COMMITTER_* environment before launching git-shell, I don't know.\n\n\n\nMy day-job project, Gerrit Code Review[1], actually does the right\nthing by recording the identity of the user in the reflog...\n\n\n\n\n[1] http://code.google.com/p/gerrit/\n\n-- \nShawn.\n"},{"id":"111473","messageId":"slrngufuke.1am.sitaramc@sitaramc.homelinux.net","threadId":"18707","inReplyTo":"20090416142728.GG23604@spearce.org","subject":"Re: GPG signing for git commit?","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-04-17T03:42:07Z","receivedAt":"2009-04-17T03:42:07Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-04-16, Shawn O. Pearce wrote:\n>> The other downside to relying on SSH presentation of identity directly,\n>> is the inability to use the SSH key to uniquely identify the user during\n>> the SSH auth (see designs like gitosis, where you always push to\n>> git+ssh://git@host/repo).\n>\n> Uhm, yea. That's a fault of gitosis then. It knows the key that\n> was used, and has that mapped back to some token that identifies that\n> account in the configuration file. Why it doesn't push that into the\n> GIT_COMMITTER_* environment before launching git-shell, I don't know.\n\nIf you set GIT_COMMITTER_*, won't it change the SHA of the\ncommit itself? I always thought so...\n\nOne possibility is to set \"LogLevel VERBOSE\" in\n/etc/ssh/sshd_config and save those logs -- they can help\nyou match up the timestamps in the reflogs and find out who\npushed what, subject to all the other caveats in Shawn's\nearlier post.\n\nBut it's a kludge... sadly my python-fu is zero; I really\nwish gitosis would put that info *somewhere*.\n"},{"id":"111482","messageId":"20090417120110.GC29121@coredump.intra.peff.net","threadId":"18707","inReplyTo":"slrngufuke.1am.sitaramc@sitaramc.homelinux.net","subject":"Re: GPG signing for git commit?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-04-17T12:01:10Z","receivedAt":"2009-04-17T12:01:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 17, 2009 at 03:42:07AM +0000, Sitaram Chamarty wrote:\n\n> > Uhm, yea. That's a fault of gitosis then. It knows the key that\n> > was used, and has that mapped back to some token that identifies that\n> > account in the configuration file. Why it doesn't push that into the\n> > GIT_COMMITTER_* environment before launching git-shell, I don't know.\n> \n> If you set GIT_COMMITTER_*, won't it change the SHA of the\n> commit itself? I always thought so...\n\nNo. Pushing will never create a new commit, so there are no new SHA-1s\ncalculated. But the reflog entry will contain GIT_COMMITTER_*, and is a\nsimple text file.\n\n-Peff\n"},{"id":"111515","messageId":"slrnguhj1o.usr.sitaramc@sitaramc.homelinux.net","threadId":"18707","inReplyTo":"20090417120110.GC29121@coredump.intra.peff.net","subject":"Re: GPG signing for git commit?","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-04-17T18:36:40Z","receivedAt":"2009-04-17T18:36:40Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-04-17, Jeff King wrote:\n>> If you set GIT_COMMITTER_*, won't it change the SHA of the\n>> commit itself? I always thought so...\n>\n> No. Pushing will never create a new commit, so there are no new SHA-1s\n> calculated. But the reflog entry will contain GIT_COMMITTER_*, and is a\n> simple text file.\n\ncool -- I didn't know this. Thanks!\n\nOne last question: where do you set it, in the pre-commit\nhook on the server?\n"},{"id":"111902","messageId":"20090421202711.GB12891@coredump.intra.peff.net","threadId":"18707","inReplyTo":"slrnguhj1o.usr.sitaramc@sitaramc.homelinux.net","subject":"Re: GPG signing for git commit?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-04-21T20:27:11Z","receivedAt":"2009-04-21T20:27:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 17, 2009 at 06:36:40PM +0000, Sitaram Chamarty wrote:\n\n> On 2009-04-17, Jeff King wrote:\n> >> If you set GIT_COMMITTER_*, won't it change the SHA of the\n> >> commit itself? I always thought so...\n> >\n> > No. Pushing will never create a new commit, so there are no new SHA-1s\n> > calculated. But the reflog entry will contain GIT_COMMITTER_*, and is a\n> > simple text file.\n> \n> cool -- I didn't know this. Thanks!\n> \n> One last question: where do you set it, in the pre-commit\n> hook on the server?\n\nNo, for two reasons:\n\n 1. The pre-commit hook is run when making a local commit. For pushing,\n you would want the pre-receive hook.\n\n 2. Hooks are executed as child processes of receive-pack, so they\n can't impact the environment it sees.\n\nI think you would need to intercept the call to receive-pack (e.g., by\nreplacing it with a wrapper script), set the variables based on ssh keys\nused (or whatever criteria you want), and then exec receive-pack.\n\n-Peff\n"},{"id":"113166","messageId":"fcaeb9bf0905062230h7ba9526fg6b79ddade72c072a@mail.gmail.com","threadId":"18707","inReplyTo":"20090415185554.GG23644@curie-int","subject":"Re: GPG signing for git commit?","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2009-05-07T05:30:51Z","receivedAt":"2009-05-07T05:30:51Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Apr 16, 2009 at 4:55 AM, Robin H. Johnson wrote:\n> One of the spots that we're looking for in this, is a model something\n> like what follows. Firstly, a \"proxy maintainer\" (PM) is a developer\n> with commit rights to the central repo, that's willing to proxy commits\n> by an outside source for some specific package. Think of them as the\n> kernel subsystem maintainer, but many more of them. The PM is still\n> expected to verify the work before passing it on the central repo.\n>\n> So we have a commit with author+committer being the outside source, and\n> now we want to record (in an easily reviewable fashion) that a specific\n> changeset was introduced to the central tree by the PM.\n>\n> Not sure of the best route to trace this data. Signing the SHA1 makes\n> the most sense, but need to be able to do that without polluting the tag\n> namespace.\n>\n> If the changeset does not have an associated signature, we'd like to\n> reject it at the central repo.\n\nHow about signing the tree SHA-1 and putting the signature in commit\nmessage? It's like gpg way of saying Signed-off-by. If the committer\nwants to sign again before pushing out, he could amend the commit,\nappend his signature there; or make a no-change commit to contain his\nsignature (probably from git-commit-tree because iirc git-commit won't\nlet you make no-change commit)\n-- \nDuy\n"},{"id":"113366","messageId":"robbat2.20090508T190254.538956494Z@orbis-terrarum.net","threadId":"18707","inReplyTo":"fcaeb9bf0905062230h7ba9526fg6b79ddade72c072a@mail.gmail.com","subject":"Re: GPG signing for git commit?","fromName":"Robin H. Johnson","fromEmail":"robbat2@gentoo.org","sentAt":"2009-05-08T19:03:58Z","receivedAt":"2009-05-08T19:03:58Z","isPatch":false,"sender":{"key":"robbat2@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/373898?v=4"},"body":"On Thu, May 07, 2009 at 03:30:51PM +1000, Nguyen Thai Ngoc Duy wrote:\n> On Thu, Apr 16, 2009 at 4:55 AM, Robin H. Johnson wrote:\n> > One of the spots that we're looking for in this, is a model something\n> > like what follows. Firstly, a \"proxy maintainer\" (PM) is a developer\n> > with commit rights to the central repo, that's willing to proxy commits\n> > by an outside source for some specific package. Think of them as the\n> > kernel subsystem maintainer, but many more of them. The PM is still\n> > expected to verify the work before passing it on the central repo.\n> >\n> > So we have a commit with author+committer being the outside source, and\n> > now we want to record (in an easily reviewable fashion) that a specific\n> > changeset was introduced to the central tree by the PM.\n> >\n> > Not sure of the best route to trace this data. Signing the SHA1 makes\n> > the most sense, but need to be able to do that without polluting the tag\n> > namespace.\n> >\n> > If the changeset does not have an associated signature, we'd like to\n> > reject it at the central repo.\n> How about signing the tree SHA-1 and putting the signature in commit\n> message? It's like gpg way of saying Signed-off-by. If the committer\n> wants to sign again before pushing out, he could amend the commit,\n> append his signature there; or make a no-change commit to contain his\n> signature (probably from git-commit-tree because iirc git-commit won't\n> let you make no-change commit)\nHmm, I like the sound of that, but I'm concerned it might be difficult\nto enforce. If rewrite-history ever happens, it's also invalidated.\n\n-- \nRobin Hugh Johnson\nGentoo Linux Developer & Infra Guy\nE-Mail : robbat2@gentoo.org\nGnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85\n"},{"id":"113497","messageId":"fcaeb9bf0905101553p56f5e8b2o6e6b550e9494b726@mail.gmail.com","threadId":"18707","inReplyTo":"robbat2.20090508T190254.538956494Z@orbis-terrarum.net","subject":"Re: GPG signing for git commit?","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2009-05-10T22:53:49Z","receivedAt":"2009-05-10T22:53:49Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, May 9, 2009 at 5:03 AM, Robin H. Johnson wrote:\n>> How about signing the tree SHA-1 and putting the signature in commit\n>> message? It's like gpg way of saying Signed-off-by. If the committer\n>> wants to sign again before pushing out, he could amend the commit,\n>> append his signature there; or make a no-change commit to contain his\n>> signature (probably from git-commit-tree because iirc git-commit won't\n>> let you make no-change commit)\n> Hmm, I like the sound of that, but I'm concerned it might be difficult\n> to enforce. If rewrite-history ever happens, it's also invalidated.\n\nWell if you rewrite and touch the trees, then every signature should\nbe invalidated anyway. If you only touch commit message, it should\nremain valid because I only sign trees.\n-- \nDuy\n"},{"id":"113529","messageId":"fcaeb9bf0905110339q22692751jc12f5a199bf47740@mail.gmail.com","threadId":"18707","inReplyTo":"fcaeb9bf0905101553p56f5e8b2o6e6b550e9494b726@mail.gmail.com","subject":"Re: GPG signing for git commit?","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2009-05-11T10:39:38Z","receivedAt":"2009-05-11T10:39:38Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, May 11, 2009 at 8:53 AM, Nguyen Thai Ngoc Duy wrote:\n> On Sat, May 9, 2009 at 5:03 AM, Robin H. Johnson wrote:\n>>> How about signing the tree SHA-1 and putting the signature in commit\n>>> message? It's like gpg way of saying Signed-off-by. If the committer\n>>> wants to sign again before pushing out, he could amend the commit,\n>>> append his signature there; or make a no-change commit to contain his\n>>> signature (probably from git-commit-tree because iirc git-commit won't\n>>> let you make no-change commit)\n>> Hmm, I like the sound of that, but I'm concerned it might be difficult\n>> to enforce. If rewrite-history ever happens, it's also invalidated.\n>\n> Well if you rewrite and touch the trees, then every signature should\n> be invalidated anyway. If you only touch commit message, it should\n> remain valid because I only sign trees.\n\nI went ahead and made two scripts git-gpg-sign and git-gpg-verify to\nsee if it works. Things that are signed in these scripts:\n - tree\n - parents\n - any other gpg signature\nYou probably don't want to sign the same commit too many times because\nthe signature will get huge.\n-- \nDuy\n"}]}