[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    GPG signing for git commit?
From:       Chow Loong Jin <hyperair () gmail ! com>
Date:       2009-04-03 21:25:54
Message-ID: 1238793954.19982.14.camel () hyperair-laptop
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


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.

--=20
Chow Loong Jin

["git-commit-sign.log" (git-commit-sign.log)]

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.


["signature.asc" (application/pgp-signature)]
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[prev in list] [next in list] [prev in thread] [next in thread]