Hi, It crossed my mind that currently git commits cannot actually be verified to be authentic, due to the fact that I can just set my identity to be someone else, and then commit under their name. During discussion on #git, Ilari, context and I figured that it would be a good idea to get GPG signing on git commits, considering that git-tag already has GPG signing support. Attached is the transcript of the log, with some irrelevant bits chopped out. Log is dated Sat, April 4, and timezone GMT +0800. -- Chow Loong Jin
04:35 <hyperair> 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? 04:35 <hyperair> s/git server/git repo/ 04:36 <Ilari> hyperair: Sure it is. 04:36 <wereHamster> hyperair: GIT_COMMITTER_NAME="Someone Else" git commit 04:36 <Ilari> 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. 04:36 <hyperair> Ilari, wereHamster: yeah i thought so, but how do you prevent someone from pushing to a git repo under your name? 04:36 <wereHamster> hyperair: you'd have to have hooks on the server side that check the commiter name 04:36 <hyperair> ah i see 04:37 <Ilari> hyperair: Then there are situations where one legimately needs to push commit with some oddball committer name. 04:37 <wereHamster> hyperair: also note that git distinguishes between committer and author 04:37 <hyperair> wereHamster: committer and author? 04:38 <hyperair> wereHamster: what's the difference? 04:38 <wereHamster> hyperair: author is the person who wrote the patch, committer is the person who created the commit 04:38 <wereHamster> so if someone sends you a patch, he/she is the author but you are the committer 04:38 <hyperair> wereHamster: how does git tell the difference? 04:39 <hyperair> 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? 04:39 <context> the authors are like physics students 04:39 <hyperair> or her? 04:39 <context> and the commiters are rocket scientests 04:40 <wereHamster> I think by looking at the patch headers (assuming it's sent in mbox format) 04:40 <context> hyperair: nothing. 04:40 <hyperair> context: bit insecure don't you think? 04:40 <context> hyperair: there is no way to stop it. you gave them commit access, you trust them enough 04:41 <wereHamster> there is a way to stop it: don't give them committ access ;) 04:41 <context> werehamster: ;) 04:41 <hyperair> wereHamster: you mean push access =p 04:41 <Ilari> 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. 04:41 <context> hyperair: unless you have a propsel on how to stop it 04:42 <Circuitsoft> There isn't really a way to stop it. 04:42 <Ilari> hyperair: You could use hooks to keep logs about who pushed what. 04:42 <hyperair> i see 04:42 <Circuitsoft> Even if there were, there's nothing preventing someone else from setting their identity to you. 04:42 <context> ilari: that still doesnt work. 04:42 <context> ilari: say i pull from you, merge my changes with yours, then merge into master and push to repo 04:43 <context> how do you track the branch i pulled form you is really from you. 04:43 <hyperair> how about gpg signing every commit =p 04:43 <Ilari> context: Both "merges" are fast forwards by assumption there. 04:43 <hyperair> just like how tags can be signed, how about signing them commits 04:43 <context> hyperair: that would work. 04:43 <context> ilari: no i mean merge as in merge. 04:43 <Ilari> hyperair: Its just impractical with current tools. 04:44 <hyperair> 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 04:44 <hyperair> Ilari: and become practical. 04:44 <Ilari> 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. 04:45 <Ilari> hyperair: There are even hacks that authenticate pushing to git:// by using signed tags. 04:46 <hyperair> Ilari: what hacks are those? 04:46 <Ilari> hyperair: They essentially implement push authentication on top of git:// 04:46 <Ilari> hyperair: Not very helpful, because ssh usually does it better. 04:46 <hyperair> yeah i thought so 04:47 <Ilari> 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. 04:48 <hyperair> Ilari: what's gitosis? 04:48 <Ilari> hyperair: Software that makes admining repo permissions in group settings easier. 04:48 <hyperair> hmm interesting 04:49 <Dashkal> Sometimes I wish I could annotate a branch. Leave a comment on the branch itself that explains why I made it... 04:49 <Ilari> 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. 04:49 <hyperair> hmm 04:50 <Ilari> hyperair: But its one line change AFAICS... 04:50 <hyperair> interesting 04:50 <hyperair> Dashkal: self-explanatory names ftw. 04:51 <context> ilari: yes i know 04:51 <context> <-- not new to git 04:59 <context> hyperair: only way to trust a commit would be gpg signatures 04:59 <Dashkal> Ilari: oh? Might have to hunt through git.git for it 04:59 <Ilari> Dashkal: pu has it. 04:59 <Dashkal> nifty, danke 04:59 <context> but i dont think you can gpg sign all commits can you 04:59 <context> not to mention typing in that passwd every commit would SUCK ! 04:59 <hyperair> context: yes of course, but git commit doesn't have gpg support. 04:59 <Ilari> Dashkal: Next doesn't. But beware that pu begins to be actually unstable. 04:59 <hyperair> context: ever heard of a gpg agent? 05:00 <context> hyperair: yes. firegpg uses it so i dont have to type it in for every email i send from gmail 05:00 <Dashkal> 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 05:00 <context> gmail + gpg = win 05:00 <hyperair> i use evolution. 05:00 <context> hyperair: another ewe. 05:00 <context> ;) 05:00 * hyperair wonders what ewe is 05:01 <context> 'icky' growse 05:01 <Ilari> hyperair: Gpg signing doesn't really work if you have external contributors that can request pull unless you force non-ff merge somewhere. 05:01 <hyperair> i don't think it comes with a trailing e 05:01 <context> ilari: eh? 05:01 <context> hyperair: ill have to update my dictionary 05:01 <hyperair> Ilari: the main point is that you make your commits be verifiable, so that nobody can pretend to commit as you. 05:02 <context> hyperair: use svn, ;) 05:02 * hyperair barfs on context 05:02 <Circuitsoft> context: Blasphemer! 05:02 <Ilari> hyperair: Well, if you need identifying of main contributors only. 05:02 * context hides 05:02 <Ilari> hyperair: So no one spoofs them. But it doesn't protect others. 05:02 <context> ilari: actually it wouldnt be too hard. if commit's could be sign 05:02 <hyperair> Ilari: yeah true. 05:03 <context> trusted users could add their finger print to like a ~/.gitfinger file 05:03 <context> people WOULD notice if that gets changed 05:03 <context> and you could have like a git fetch-gpg-keys 05:03 <hyperair> hahah 05:03 <hyperair> i think we should file that as a feature request =p 05:03 <hyperair> if tags can be signed, why not commits? =p 05:04 <Ilari> hyperair: Both even have similar structure. Header fields plus freeform text section. 05:04 <Ilari> hyperair: The text section is even fully 8-bit clean. 05:04 <hyperair> awesome. so let's have it signed =p 05:05 <Ilari> 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. 05:05 <context> hyperair: then you need to worry about an author signature, AND commiters signature 05:05 <context> and diff's might be even more funky 05:06 <context> but it would be an awesome feature 05:06 <hyperair> context: diffs can have headers and footers. so a clearsign would be fine 05:06 <Ilari> If you care only about protecting main authors, committer signature is enough. 05:06 <Circuitsoft> What if gpg on commit was only used when the --signoff option was selected? 05:07 <Ilari> It also has simplifying factor that signing headers plus rest of commit message is enough. 05:07 <hyperair> Circuitsoft: that would be awesome, but as far as i can tell, it isn't used atm 05:07 <hyperair> now then are there any git devs we can propose this to? =p 05:07 <context> <-- gets all credit 05:07 <context> and his million dollar prize 05:08 <hyperair> lol 05:08 <Ilari> hyperair: Send idea to mailinglist. The official policy is essentially that altough this channel has archives, for development purposes discussions here never happned.
Attachment:
signature.asc
Description: This is a digitally signed message part
