{"thread":{"id":"6378","subject":"Re: Commit signing","startedAt":"2007-01-15T10:00:57Z","lastAt":"2007-01-15T22:26:50Z","messageCount":21,"participants":["Shawn O. Pearce","Andy Parkins","Matthias Kestenholz","Johannes Schindelin","Karl Hasselström","Martin Langhoff","Jakub Narebski","Daniel Barkalow","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"31692","messageId":"200701151000.58609.andyparkins@gmail.com","threadId":"6378","inReplyTo":null,"subject":"Commit signing","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-01-15T10:00:57Z","receivedAt":"2007-01-15T10:00:57Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"Hello,\n\nI was just talking to another developer in my office about version control.  \nHe's working with Windows so has chosen Monotone for a version control \nsystem.  I didn't have any huge objections, as I'm sure monotone can be \nmigrated to git without much trouble (they look to support the same features \nfrom my brief reading).\n\nOf course my favourite is git, but we were talking about the certificates \nneeded by monotone for each developer.  I assume that monotone therefore \nsigns every commit.  It obviously crossed my mind as to how one would do that \nwith git?  We obviously already have the ability to sign a tag, but is there \na way in which one could sign every commit.\n\nThe more I think about it, the more it could be a reasonable question.  In my \nown repository I can obviously create whatever commits i like, claiming them \nto be from whomever I like just by altering a few config settings.  If I put \na few of those in my own repository and then managed to persuade Junio to \npull from me - wouldn't I have faked commits from another developer?  \nHowever, I wouldn't be able to fake a gpg signature.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"31691","messageId":"1168856014.16129.35.camel@localhost.localdomain","threadId":"6378","inReplyTo":"200701151000.58609.andyparkins@gmail.com","subject":"Re: Commit signing","fromName":"Matthias Kestenholz","fromEmail":"lists@spinlock.ch","sentAt":"2007-01-15T10:13:34Z","receivedAt":"2007-01-15T10:13:34Z","isPatch":false,"sender":{"key":"lists@spinlock.ch","avatar":null},"body":"On Mon, 2007-01-15 at 10:00 +0000, Andy Parkins wrote:\n> Hello,\n> \n> I was just talking to another developer in my office about version control.  \n> He's working with Windows so has chosen Monotone for a version control \n> system.  I didn't have any huge objections, as I'm sure monotone can be \n> migrated to git without much trouble (they look to support the same features \n> from my brief reading).\n\nThe decision to use SHA1 hashes for all objects comes from Monotone, so\nthe design has to be somewhat similar.\n\n> Of course my favourite is git, but we were talking about the certificates \n> needed by monotone for each developer.  I assume that monotone therefore \n> signs every commit.  It obviously crossed my mind as to how one would do that \n> with git?  We obviously already have the ability to sign a tag, but is there \n> a way in which one could sign every commit.\n\nYou'd need to automatically generate a signed tag for every commit (for\nexample in a post-commit hook? Or use a wrapper script for git-commit\nwhich runs git-tag -s afterwards)\n\n> \n> The more I think about it, the more it could be a reasonable question.  In my \n> own repository I can obviously create whatever commits i like, claiming them \n> to be from whomever I like just by altering a few config settings.  If I put \n> a few of those in my own repository and then managed to persuade Junio to \n> pull from me - wouldn't I have faked commits from another developer?  \n> However, I wouldn't be able to fake a gpg signature.\n\nYou just explained why no one should pull from people he does not trust.\n\nI think it would be overkill to sign every single commit, signed tags\nare enough to sign the whole history (as everyone should know by now).\n\n\nMatthias\n"},{"id":"31718","messageId":"20070115101529.GB12257@spearce.org","threadId":"6378","inReplyTo":"200701151000.58609.andyparkins@gmail.com","subject":"Re: Commit signing","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-15T10:15:29Z","receivedAt":"2007-01-15T10:15:29Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Andy Parkins <andyparkins@gmail.com> wrote:\n> I was just talking to another developer in my office about version control.  \n> He's working with Windows so has chosen Monotone for a version control \n> system.  I didn't have any huge objections, as I'm sure monotone can be \n> migrated to git without much trouble (they look to support the same features \n> from my brief reading).\n> \n> Of course my favourite is git, but we were talking about the certificates \n> needed by monotone for each developer.  I assume that monotone therefore \n> signs every commit.  It obviously crossed my mind as to how one would do that \n> with git?  We obviously already have the ability to sign a tag, but is there \n> a way in which one could sign every commit.\n> \n> The more I think about it, the more it could be a reasonable question.  In my \n> own repository I can obviously create whatever commits i like, claiming them \n> to be from whomever I like just by altering a few config settings.  If I put \n> a few of those in my own repository and then managed to persuade Junio to \n> pull from me - wouldn't I have faked commits from another developer?  \n> However, I wouldn't be able to fake a gpg signature.\n\nYou could sign the content of the raw commit and include the signature\nin the payload, much like we do with tags.  E.g.:\n\n\ttree 4b825dc642cb6eb9a060e54bf8d69288fbee4904\n\tparent 5064201cfd47822e567456fb1d6a76a5e81da800\n\tparent e6987d056595deace8cba91ce0a2524bb91770a9\n\tauthor Shawn O. Pearce <spearce.org> 1168855184 -0400\n\tcommitter Shawn O. Pearce <spearce.org> 1168855184 -0400\n\n\tMerge branch 'branch' into 'master'.\n\n\t-----BEGIN PGP SIGNATURE-----\n\tVersion: GnuPG v1.4.6 (GNU/Linux)\n\n\tiD8DBQBFiY2zwMbZpPMRm5oRAll0AJ0ZR+Bu8zjMVe8eEKR8Xr+3QMtndACcC2Kl\n\taWSkKLptN0LAOpDinq+aqOc=\n\t=dZlu\n\t-----END PGP SIGNATURE-----\n\nBut that's horribly ugly and probably vast overkill.  Plus the only\nway to really verify each commit is to have the complete database of\nPGP public keys handy.  A commit-msg hook could probably implement\nthe signing.\n\n\nWhat I'm actually doing in one particular environment is checking\nthe committer string against a database of known committer strings\nassociated with the current UNIX uid.  My update hook[*1*] performs\na `git log --pretty=raw $3 --not --all` query to determine any\ncommits which are coming in as part of this push and which are not\nalready referenced by an existing head or tag in this repository.\nFor each of those the committer line *must* match one stored in\nthe allowed-committers file for the current user, as these are\nbrand new commits being introduced to the repository.\n\nThis works well as everyone has a UNIX account on the same system\nand logs in via SSH.  The easiest way for us to share changes is to\njust push them to a single central repository.  That repository is\nperforming the checking.  And since every commit signs the entire\nchain of commits which came before it, we're in effect implicitly\nsigning our commits by pushing them to that server.  And other\ndevelopers are agreeing by building on top of that work.\n\n\n[*1*] If anyone wants the hook, let me know.  I'd be happy to\n      share it.  But since its undocumented I haven't offered it\n      up as a contrib in git.git yet.\n\n-- \nShawn.\n"},{"id":"31719","messageId":"20070115102727.GC12257@spearce.org","threadId":"6378","inReplyTo":"20070115101529.GB12257@spearce.org","subject":"Re: Commit signing","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-15T10:27:27Z","receivedAt":"2007-01-15T10:27:27Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Shawn O. Pearce\" <spearce@spearce.org> wrote:\n> Andy Parkins <andyparkins@gmail.com> wrote:\n> > Of course my favourite is git, but we were talking about the certificates \n> > needed by monotone for each developer.\n\nOne problem here is a certificate does not make a security system.\nObviously anyone can generate a certificate and claim anything they\nwant within it, just the same as you can claim anything you want in\na Git commit or tag.  What's needed is some external method that\nall interested parties trust to verify a given certificate is\nassociated with a given entity.\n\n> What I'm actually doing in one particular environment is checking\n> the committer string against a database of known committer strings\n> associated with the current UNIX uid.\n\nIn this particular case access to the UNIX system is tightly\ncontrolled.  Much paperwork must be filled out and signed by multiple\npeople, all of whom recognize the user on sight and know why they\nneed access to that system.  They also have checked the user's\nidentity through multiple background checks, fingerprinting, etc.\n\nIn other words the entire authentication problem was already solved,\ntrusting the UNIX uid just let Git plug into that seamlessly.\n\nThe problem is obviously harder on the Internet.  I've never\nmet anyone on this mailing list in person, but the quality (or\nlack thereof sometimes) is evident in my work, and since its all\npeer-reviewed anyway Junio finds little risk in incorporating the\ngood stuff into git.git.  No certificate required.\n\n-- \nShawn.\n"},{"id":"31744","messageId":"Pine.LNX.4.63.0701151126540.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6378","inReplyTo":"20070115101529.GB12257@spearce.org","subject":"Re: Commit signing","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-15T10:31:46Z","receivedAt":"2007-01-15T10:31:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Jan 2007, Shawn O. Pearce wrote:\n\n> Andy Parkins <andyparkins@gmail.com> wrote:\n> > I was just talking to another developer in my office about version control.  \n> > He's working with Windows so has chosen Monotone for a version control \n> > system.  I didn't have any huge objections, as I'm sure monotone can be \n> > migrated to git without much trouble (they look to support the same features \n> > from my brief reading).\n> > \n> > Of course my favourite is git, but we were talking about the certificates \n> > needed by monotone for each developer.  I assume that monotone therefore \n> > signs every commit.  It obviously crossed my mind as to how one would do that \n> > with git?  We obviously already have the ability to sign a tag, but is there \n> > a way in which one could sign every commit.\n> > \n> > The more I think about it, the more it could be a reasonable question.  In my \n> > own repository I can obviously create whatever commits i like, claiming them \n> > to be from whomever I like just by altering a few config settings.  If I put \n> > a few of those in my own repository and then managed to persuade Junio to \n> > pull from me - wouldn't I have faked commits from another developer?  \n> > However, I wouldn't be able to fake a gpg signature.\n> \n> You could sign the content of the raw commit and include the signature\n> in the payload, much like we do with tags.  E.g.:\n> \n> \ttree 4b825dc642cb6eb9a060e54bf8d69288fbee4904\n> \tparent 5064201cfd47822e567456fb1d6a76a5e81da800\n> \tparent e6987d056595deace8cba91ce0a2524bb91770a9\n> \tauthor Shawn O. Pearce <spearce.org> 1168855184 -0400\n> \tcommitter Shawn O. Pearce <spearce.org> 1168855184 -0400\n> \n> \tMerge branch 'branch' into 'master'.\n> \n> \t-----BEGIN PGP SIGNATURE-----\n> \tVersion: GnuPG v1.4.6 (GNU/Linux)\n> \n> \tiD8DBQBFiY2zwMbZpPMRm5oRAll0AJ0ZR+Bu8zjMVe8eEKR8Xr+3QMtndACcC2Kl\n> \taWSkKLptN0LAOpDinq+aqOc=\n> \t=dZlu\n> \t-----END PGP SIGNATURE-----\n> \n> But that's horribly ugly and probably vast overkill.  Plus the only\n> way to really verify each commit is to have the complete database of\n> PGP public keys handy.  A commit-msg hook could probably implement\n> the signing.\n\nBut it would only sign the _message_. You would have to sign the whole \n_raw_ commit message, to include also the ancestry. But there is no hook \n_between_ constructing that _raw_ commit message and actually writing the \ncommit object (this would have to be in builtin-commit-tree.c:151).\n\nCiao,\nDscho\n"},{"id":"31740","messageId":"200701151042.12753.andyparkins@gmail.com","threadId":"6378","inReplyTo":"20070115101529.GB12257@spearce.org","subject":"Re: Commit signing","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-01-15T10:42:11Z","receivedAt":"2007-01-15T10:42:11Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2007 January 15 10:15, Shawn O. Pearce wrote:\n\n> You could sign the content of the raw commit and include the signature\n> in the payload, much like we do with tags.  E.g.:\n\nThat looks good to me.\n\n> But that's horribly ugly and probably vast overkill.  Plus the only\n> way to really verify each commit is to have the complete database of\n> PGP public keys handy.  A commit-msg hook could probably implement\n> the signing.\n\nNot such overkill.  I wasn't thinking of verifying every commit ever made \nevery time the repository changes.  I was thinking more of a situation when a \nparticular commit is identified as being troublesome (like introducing a \nbackdoor), and the person listed as comitter denies all knowledge.  At that \npoint one would verify the signature.\n\nAs an added extra, the host of the central repository could have a list \nof \"allowed keys\" so that only correctly signed commits would be allowed into \nthe repository.\n\nAs an example of why this would be useful: let's say we have a developer \ncommitting to a maintainer repository who then merges those changes into \nmainline and pushes up to the central repository (like what happens with \nLinux).  The commits to the central repository are made using the ssh login \nof the maintainer, but they are adding commits by someone else.  What if that \nsomeone else isn't allowed to commit to the central?  With signed commits the \noption is available to exclude them.\n\nI don't think the argument that Matthias offered (\"You just explained why no \none should pull from people he does not trust.\") is a good one.  One might \nnot want trust to be transitive.  Just because I trust you, doesn't not mean \nthat I trust those who you trust.  The path of getting commits in via a \ntrusted person, perhaps even via multiple levels of transitive trust might \nnot be something that is wanted in every project.  Having signed commits \nwould at least give the option.\n\n> What I'm actually doing in one particular environment is checking\n> the committer string against a database of known committer strings\n> associated with the current UNIX uid.  My update hook[*1*] performs\n> a `git log --pretty=raw $3 --not --all` query to determine any\n> commits which are coming in as part of this push and which are not\n> already referenced by an existing head or tag in this repository.\n> For each of those the committer line *must* match one stored in\n> the allowed-committers file for the current user, as these are\n> brand new commits being introduced to the repository.\n\nThis addresses the problem somewhat.  However, the problem I'm talking about \nis where a commit identity has been faked by someone committing to a \nsecondary (or tertiary) level repository.  While you are ensuring that the \ncurrent user is allowed to commit on behalf of someone else to your \nrepository, you haven't protected anything, because they could simply fake \ntheir ID to one of the \"allowed\" set and your test will pass.\n\n> performing the checking.  And since every commit signs the entire\n> chain of commits which came before it, we're in effect implicitly\n\nWhile true, on a big project, with changes mainly in different areas, the fact \nthat I committed a/file1.c after you committed b/file2.c doesn't mean I've \nsigned off on your b/file2.c changes being non-malicious.\n\nThis is all just paranoia obviously.  It's nothing that is in the remotest bit \nurgent, or perhaps even practical.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"31689","messageId":"20070115104336.GD12257@spearce.org","threadId":"6378","inReplyTo":"Pine.LNX.4.63.0701151126540.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Commit signing","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-15T10:43:36Z","receivedAt":"2007-01-15T10:43:36Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> On Mon, 15 Jan 2007, Shawn O. Pearce wrote:\n> > A commit-msg hook could probably implement the signing.\n> \n> But it would only sign the _message_. You would have to sign the whole \n> _raw_ commit message, to include also the ancestry. But there is no hook \n> _between_ constructing that _raw_ commit message and actually writing the \n> commit object (this would have to be in builtin-commit-tree.c:151).\n\nSorry, I was assuming people knew what was in the grey matter\nupstairs.  :-)\n\nI meant to say something along the lines of:\n\n  A commit-msg hook could probably implement the signing.  However\n  doing that would require generating the raw commit data using the\n  current timestamp, and that would require having git-commit.sh set\n  the timestamp into GIT_COMMITTER_DATE and GIT_AUTHOR_DATE before\n  it runs the hook, or before git-commit-tree.  Clearly an ugly mess.\n\nJohannes is right.  A proper signing would probably need to be done\nin commit-tree itself.  Or commit-tree would need to be invoked to\ncreate a dummy commit, fetch it back out with cat-file, sign that,\nthen regenerate the commit with the same prior timestamps.  Ugly.\n\nBut I don't really see a need for commit signing in Git.  The best\nway to shuttle commits around in Git-space is through published\nrepositories.  You probably want to grab whatever is on that\nrepository, and you either trust the repository owner or you don't.\nIf you don't trust the owner, but you trust the pusher, than using\n1 annotated tag per push is reasonable and gives you something\nto verify the repository owner isn't playing games.  If you don't\ntrust the pusher than you should be reviewing the changes before\ndeciding to keep them in your project.\n\nBut even then annotated tags are overkill.  You could just\nreceive the commit SHA1 out-of-band from the pusher (e.g. email,\nlike Junio's hidden X-master-at header) and verify that by hand.\n8 digits is probably more than enough to hand-verify the entire\ncommit chain you are receiving.\n\n-- \nShawn.\n"},{"id":"31736","messageId":"Pine.LNX.4.63.0701151137430.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6378","inReplyTo":"20070115102727.GC12257@spearce.org","subject":"Re: Commit signing","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-15T10:43:45Z","receivedAt":"2007-01-15T10:43:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Jan 2007, Shawn O. Pearce wrote:\n\n> I've never met anyone on this mailing list in person, but the quality \n> (or lack thereof sometimes) is evident in my work, and since its all \n> peer-reviewed anyway Junio finds little risk in incorporating the good \n> stuff into git.git.  No certificate required.\n\nExactly. I think it is one of the reasons monotone is so unpopular (at \nleast as far as I am concerned): it makes the start really cumbersome. And \nin the end you gain nothing.\n\nAnd you see what the result is when looking into corporate projects. More \noften than not, bureaucratic procedures (e.g. tracking time, meetings, \nspecifications) supersede quality-assuring procedures (e.g. permanent \nupdates on the TODO list, code review, discussion on implementation \ndetails), and quite often, the code just sucks.\n\nMy favourite example is when I found 34 different (!) implementations of a \ntree structure in the same project.\n\nSo, if you start relying on the validity of code just because somebody \nsigned it, you will reap trouble.\n\nCiao,\nDscho\n"},{"id":"31734","messageId":"20070115105616.GE12257@spearce.org","threadId":"6378","inReplyTo":"200701151042.12753.andyparkins@gmail.com","subject":"Re: Commit signing","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-15T10:56:16Z","receivedAt":"2007-01-15T10:56:16Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Andy Parkins <andyparkins@gmail.com> wrote:\n> On Monday 2007 January 15 10:15, Shawn O. Pearce wrote:\n> As an added extra, the host of the central repository could have a list \n> of \"allowed keys\" so that only correctly signed commits would be allowed into \n> the repository.\n\nBut that might reject cases where one commit has been brought up\nfrom other repositories yet its part of a chain of 1,000 commits\nnow being pushed into the central repository.  You need to allow\nthe head that is coming in, and everything in its past.\n \n> As an example of why this would be useful: let's say we have a developer \n> committing to a maintainer repository who then merges those changes into \n> mainline and pushes up to the central repository (like what happens with \n> Linux).  The commits to the central repository are made using the ssh login \n> of the maintainer, but they are adding commits by someone else.  What if that \n> someone else isn't allowed to commit to the central?  With signed commits the \n> option is available to exclude them.\n\nYou can't just clip commits out during a push!  Are you going to\nreject the push because the trusted SSH-logged in maintainer has\npulled in changes from elsewhere and has decided that they are good\nenough for inclusion?\n\n> I don't think the argument that Matthias offered (\"You just explained why no \n> one should pull from people he does not trust.\") is a good one.  One might \n> not want trust to be transitive.  Just because I trust you, doesn't not mean \n> that I trust those who you trust.  The path of getting commits in via a \n> trusted person, perhaps even via multiple levels of transitive trust might \n> not be something that is wanted in every project.  Having signed commits \n> would at least give the option.\n\nYes, that's very valid.  But if you trust me and I've gone and\nbuilt 100 commits on top of something I got from someone else I\ntrust but that you don't trust, you are going to reject all of my\nchanges and ask that I rewrite them?  That's quite paranoid.\n \n> > What I'm actually doing in one particular environment is checking\n> > the committer string against a database of known committer strings\n> > associated with the current UNIX uid.\n> \n> This addresses the problem somewhat.  However, the problem I'm talking about \n> is where a commit identity has been faked by someone committing to a \n> secondary (or tertiary) level repository.  While you are ensuring that the \n> current user is allowed to commit on behalf of someone else to your \n> repository, you haven't protected anything, because they could simply fake \n> their ID to one of the \"allowed\" set and your test will pass.\n\nActually I'm checking for exact matching against the committer\nstring.  Every UNIX uid has exactly one (and only one) committer\nstring associated with it.  The name on their payroll and security\npaperwork, and the corporate email that was assigned to them.\nSo you *cannot* push something which was committed by another user\nor which you committed for them on their behalf.  But you can set\nthe author field to anything you want; indeeded I often copy in\nchanges from other people and mark them as the author will retaining\nthe committer line as myself.\n\nThis causes a huge problem with our local mirror of git.git.\nNormally I would just run git-fetch on the server to update the\nmirror (thus bypassing the update hook, which screams out that I'm\nnot Junio) but that system doesn't have cURL or expat built and I\ncan only fetch over HTTP from there.  So I wind up having to go\nthrough extra hoops to update commits which came from someone I\ntrust, but which ain't me.\n\n-- \nShawn.\n"},{"id":"31739","messageId":"Pine.LNX.4.63.0701151149030.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6378","inReplyTo":"200701151042.12753.andyparkins@gmail.com","subject":"Re: Commit signing","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-15T10:59:00Z","receivedAt":"2007-01-15T10:59:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Jan 2007, Andy Parkins wrote:\n\n> As an example of why this would be useful: let's say we have a developer \n> committing to a maintainer repository who then merges those changes into \n> mainline and pushes up to the central repository (like what happens with \n> Linux).  The commits to the central repository are made using the ssh \n> login of the maintainer, but they are adding commits by someone else.  \n> What if that someone else isn't allowed to commit to the central?  With \n> signed commits the option is available to exclude them.\n\nIMHO the thinko is the old CVS one. With git we _discourage_ a central \nrepository where everybody pushes into. We _encourage_ local repositories, \nwhich are controlled by _one_ person.\n\nIf you need a central repository with one \"official\" version, then \ndesignate a release officer. This officer is responsible to keep the \nrepository clean. And I _guarantee_ you that she can tell where she pulled \nbad commits from: it is written down in the \"Merge from\" message.\n\nAnd BTW you have no option to exclude unsigned commits when pushing to a \nrepository. It is either all in or all out.\n\nCiao,\nDscho\n"},{"id":"31721","messageId":"Pine.LNX.4.63.0701151201100.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6378","inReplyTo":"20070115105616.GE12257@spearce.org","subject":"Re: Commit signing","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-15T11:08:16Z","receivedAt":"2007-01-15T11:08:16Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Jan 2007, Shawn O. Pearce wrote:\n\n> Andy Parkins <andyparkins@gmail.com> wrote:\n> \n> > I don't think the argument that Matthias offered (\"You just explained \n> > why no one should pull from people he does not trust.\") is a good one.  \n> > One might not want trust to be transitive.  Just because I trust you, \n> > doesn't not mean that I trust those who you trust.  The path of \n> > getting commits in via a trusted person, perhaps even via multiple \n> > levels of transitive trust might not be something that is wanted in \n> > every project.  Having signed commits would at least give the option.\n> \n> Yes, that's very valid.  But if you trust me and I've gone and built 100 \n> commits on top of something I got from someone else I trust but that you \n> don't trust, you are going to reject all of my changes and ask that I \n> rewrite them?  That's quite paranoid.\n\nIt is not only paranoid. It is bad practice.\n\nWe might be tempted to forget in these horrible times that distrust itself \nis a perpetuum mobile. Distrust results in distrust. And nobody being \ndistrusted likes that fact. It makes for a bad working environment, for \nless code quality, and quite often, people get ideas from being \ndistrusted: \"If they think I could include a backdoor, well, that might \nactually be a good idea!\".\n\nPlease have a look at the Linux kernel development, or for that matter, \ngit development itself. Here, people care, people trust, people respect \neach other (sometimes YELLING, to keep discussions exciting). And the \nresult is: nice code.\n\nCiao,\nDscho\n"},{"id":"31701","messageId":"200701151141.51659.andyparkins@gmail.com","threadId":"6378","inReplyTo":"20070115105616.GE12257@spearce.org","subject":"Re: Commit signing","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-01-15T11:41:43Z","receivedAt":"2007-01-15T11:41:43Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2007 January 15 10:56, Shawn O. Pearce wrote:\n\n\n> You can't just clip commits out during a push!  Are you going to\n> reject the push because the trusted SSH-logged in maintainer has\n> pulled in changes from elsewhere and has decided that they are good\n> enough for inclusion?\n\nYes.\n\nWhat about this set of repositories\n\n Central - Maintainer - Lieutenant - Subsystem Maintainer - Idiot - Vandal\n\nWhile I'm not saying that it should be mandatory, I do think that the central \nrepository should have an optional way of stopping the vandal using the \nidiot's repository to push unnoticed bad changes in under somebody else's \nname.  What about:\n * Vandal spends one year developing reasonable relationship with Idiot, all\n   patches are good.  Occasional big patches are pulled by Idiot.\n * Vandal prepares extra big series of commits, with ostensibly good\n   functionality.  In the middle of large series adds one small commit with\n   the committer set to someone other than himself.  In fact, he sets it to be\n   someone he doesn't like.\n * Idiot pulls from Vandal's repository.\n * pull, pull, pull, push because we all trust the person we're pulling from.\n * Vandal's changes are now in Central.\n\n> Yes, that's very valid.  But if you trust me and I've gone and\n> built 100 commits on top of something I got from someone else I\n> trust but that you don't trust, you are going to reject all of my\n> changes and ask that I rewrite them?  That's quite paranoid.\n\nWell yes.  I personally wouldn't bother, but I'm casting myself in the role \nof \"paranoid\" maintainer for this discussion.\n\nThe answer is: no, you can't put your 100+X commits in my repository because I \ndon't trust the person who wrote X of them.  It is paranoid, and it is \noverkill, but it is also /my/ repository.  It might also be that you are my \nemployee and you will do as you are damn well told.\n\nI'm arguing that git should cater for the borderline sociopath as well as the \nwell adjusted developer as well.  After all, PHB's need version control \ntoo :-)\n\n> the author field to anything you want; indeeded I often copy in\n> changes from other people and mark them as the author will retaining\n> the committer line as myself.\n\nIn the case above, it is the distributed nature of git that causes the \nproblem, the original comitter is Idiot, but the repository that the changes \nuse to get into central is Maintainer's.\n\nThis has spiralled more than I ever intended anyway.  You (and Johannes) have \nanswered my question: namely that there isn't an easy way to do it (with a \ncommit script) and that it's not really a major issue anyway.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"31690","messageId":"200701151150.28082.andyparkins@gmail.com","threadId":"6378","inReplyTo":"Pine.LNX.4.63.0701151201100.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Commit signing","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-01-15T11:50:26Z","receivedAt":"2007-01-15T11:50:26Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2007 January 15 11:08, Johannes Schindelin wrote:\n\n> It is not only paranoid. It is bad practice.\n\nTrue.  However, I don't see that it is Git's place to dictate policy.  If a \ncompany wants to use Git and wants to use it in an oppressive and inefficient \nmanner, while alienating their developers, who are we to stand in their way?\n\n> Please have a look at the Linux kernel development, or for that matter,\n> git development itself. Here, people care, people trust, people respect\n> each other (sometimes YELLING, to keep discussions exciting). And the\n> result is: nice code.\n\nAgain true.  What has that to do with Git though?  Why shouldn't Git have \nfeatures that let people with different methods of development from you use \nit?  It is certainly true that signed commits /is/ a feature.  And it's a \nfeature that some people might want.  If there isn't a technical argument \nagainst it, what does it matter?\n\n(Note: it doesn't matter enough to me that I would put the time in, I'm \narguing in the abstract really - should features be kept out because they \nallow a development method we would find distasteful?)\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"31704","messageId":"Pine.LNX.4.63.0701151255530.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6378","inReplyTo":"200701151150.28082.andyparkins@gmail.com","subject":"Re: Commit signing","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-15T12:02:18Z","receivedAt":"2007-01-15T12:02:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Jan 2007, Andy Parkins wrote:\n\n> It is certainly true that signed commits /is/ a feature.  And it's a \n> feature that some people might want.  If there isn't a technical \n> argument against it, what does it matter?\n> \n> (Note: it doesn't matter enough to me that I would put the time in, I'm \n> arguing in the abstract really - should features be kept out because \n> they allow a development method we would find distasteful?)\n\nYou gave the answer yourself: until there is somebody who needs it, I \nguess it will not be there.\n\nNote that it would be relatively easy: I already gave the location where \nthe hook should go (builtin-commit-tree.c, line 151), and you can see an \nexample how to execute a hook in receive-pack.c, lines 67ff.\n\nCiao,\nDscho\n\nP.S.: Yes, I am encouraging you to implement it.\n"},{"id":"31733","messageId":"20070115145235.GA1830@diana.vm.bytemark.co.uk","threadId":"6378","inReplyTo":"20070115104336.GD12257@spearce.org","subject":"Re: Commit signing","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-01-15T14:52:35Z","receivedAt":"2007-01-15T14:52:35Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-01-15 05:43:36 -0500, Shawn O. Pearce wrote:\n\n> If you don't trust the owner, but you trust the pusher, than using 1\n> annotated tag per push is reasonable and gives you something to\n> verify the repository owner isn't playing games. If you don't trust\n> the pusher than you should be reviewing the changes before deciding\n> to keep them in your project.\n>\n> But even then annotated tags are overkill. You could just receive\n> the commit SHA1 out-of-band from the pusher (e.g. email, like\n> Junio's hidden X-master-at header) and verify that by hand. 8 digits\n> is probably more than enough to hand-verify the entire commit chain\n> you are receiving.\n\nNo. You've just constructed a system whose security depends on a\n32-bit hash. This is one of those situations where you really do need\nall the digits.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"31757","messageId":"46a038f90701151036k7b9ee5e2sdd3bbf6d69f9a27c@mail.gmail.com","threadId":"6378","inReplyTo":"200701151141.51659.andyparkins@gmail.com","subject":"Re: Commit signing","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-01-15T18:36:14Z","receivedAt":"2007-01-15T18:36:14Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 1/16/07, Andy Parkins <andyparkins@gmail.com> wrote:\n\n> What about this set of repositories\n>\n>  Central - Maintainer - Lieutenant - Subsystem Maintainer - Idiot - Vandal\n...\n>  * Vandal spends one year developing reasonable relationship with Idiot, all\n>    patches are good.  Occasional big patches are pulled by Idiot.\n\nIf you are using signatures, the trojan horse would make sure he gets\nhis patches signed. What is the advantage again?\n\n>  * Vandal prepares extra big series of commits, with ostensibly good\n>    functionality.  In the middle of large series adds one small commit with\n>    the committer set to someone other than himself.  In fact, he sets it to be\n>    someone he doesn't like.\n\nHow about\n - not pulling without review\n - pulling only \"own\" patches from peripheral developers\n\n> Well yes.  I personally wouldn't bother, but I'm casting myself in the role\n> of \"paranoid\" maintainer for this discussion.\n\nAnd if you are so paranoid, then you review, and mandate that all\npatches get a lot of reading ;-) because bugs slip in due to idiocy a\nwhole lot more than because of trojans. Maybe you force patches to be\nsent to a mailing list, discussed and merged in only if they survive\nthe hard-assed review. Like it happens with git or linux.\n\n> The answer is: no, you can't put your 100+X commits in my repository because I\n> don't trust the person who wrote X of them.  It is paranoid, and it is\n> overkill, but it is also /my/ repository.  It might also be that you are my\n> employee and you will do as you are damn well told.\n>\n> I'm arguing that git should cater for the borderline sociopath as well as the\n> well adjusted developer as well.  After all, PHB's need version control\n> too :-)\n\nArchitecturally, you can't rewrite history just like that -- merge\nskipping patches isn't possible. You _can_, however, cancel a merge\nbecause something looks fishy.\n\n> In the case above, it is the distributed nature of git that causes the\n> problem, the original comitter is Idiot, but the repository that the changes\n> use to get into central is Maintainer's.\n\nIIRC Linus discussed this early on, and his view was that authorship\nonly gives you false security. The only security is in reviewing code.\nAnd that the code-signed patches are dog-slow too.\n\ncheers,\n\n\n\nmartin\n"},{"id":"31759","messageId":"200701151923.07493.andyparkins@gmail.com","threadId":"6378","inReplyTo":"46a038f90701151036k7b9ee5e2sdd3bbf6d69f9a27c@mail.gmail.com","subject":"Re: Commit signing","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-01-15T19:23:05Z","receivedAt":"2007-01-15T19:23:05Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2007, January 15 18:36, Martin Langhoff wrote:\n\n> >  * Vandal spends one year developing reasonable relationship with Idiot,\n> > all patches are good.  Occasional big patches are pulled by Idiot.\n>\n> If you are using signatures, the trojan horse would make sure he gets\n> his patches signed. What is the advantage again?\n\nHe can't sign it as someone else, and so when it is eventually discovered the \nculprit can be hunted down and flogged.\n\n> IIRC Linus discussed this early on, and his view was that authorship\n> only gives you false security. The only security is in reviewing code.\n> And that the code-signed patches are dog-slow too.\n\nEh? It's only a little bit of extra text to carry around.  It's signed by the \noriginal author when it enters a repository, so it's not a huge price to pay \nin any one place.  The checking, if you wanted to enable it, would only be \ndone once per incoming commit to a master repository.  All-in-all, nothing \nthat you wouldn't be willing to pay if you wanted this feature.\n\nAs an aside; I would also suggest that this isn't just about people trojaning \na commit.  You could also argue that without it, this whole Signed-Off-By \nbusiness is a bit a moot point.\n\nThe signed-off-by lines in the kernel are being used to establish original \nauthorship and entry path of every line in the kernel.  It's fairly worthless \nthough when the \"signing\" is just someone writing an easily forged line of \ntext.  For example, what is to stop that naughty lad Linus from adding some \ncode the infringes a copyright to the kernel and adding a \"Signed-Off-By: \nMartin Langhoff\" to the bottom?  Equally, when SCO come knocking with \ntheir \"we wrote that line\", a secure digital signature chain would go a long \nway to proving that a submission wasn't faked.\n\nI'm not sure how far commit signing would go towards preventing that, but it \ncould certainly be part of the solution.  Commit signing doesn't have to be \nall about trusting developers, it can be about recording history in an \nindependently checkable way.\n\n\n\nAndy\n\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\nandyparkins@gmail.com\n"},{"id":"31763","messageId":"eognu3$tje$1@sea.gmane.org","threadId":"6378","inReplyTo":"200701151000.58609.andyparkins@gmail.com","subject":"Re: Commit signing","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-15T20:24:55Z","receivedAt":"2007-01-15T20:24:55Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"By the way, how to make tag pointing to a out-of-tree blob, like\njunio-gpg-pub tag in git.git?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"31764","messageId":"Pine.LNX.4.64.0701151430170.20138@iabervon.org","threadId":"6378","inReplyTo":"20070115102727.GC12257@spearce.org","subject":"Re: Commit signing","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-01-15T20:25:52Z","receivedAt":"2007-01-15T20:25:52Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 15 Jan 2007, Shawn O. Pearce wrote:\n\n> \"Shawn O. Pearce\" <spearce@spearce.org> wrote:\n> > Andy Parkins <andyparkins@gmail.com> wrote:\n> > > Of course my favourite is git, but we were talking about the certificates \n> > > needed by monotone for each developer.\n> \n> One problem here is a certificate does not make a security system.\n> Obviously anyone can generate a certificate and claim anything they\n> want within it, just the same as you can claim anything you want in\n> a Git commit or tag.  What's needed is some external method that\n> all interested parties trust to verify a given certificate is\n> associated with a given entity.\n> \n> > What I'm actually doing in one particular environment is checking\n> > the committer string against a database of known committer strings\n> > associated with the current UNIX uid.\n> \n> In this particular case access to the UNIX system is tightly\n> controlled.  Much paperwork must be filled out and signed by multiple\n> people, all of whom recognize the user on sight and know why they\n> need access to that system.  They also have checked the user's\n> identity through multiple background checks, fingerprinting, etc.\n> \n> In other words the entire authentication problem was already solved,\n> trusting the UNIX uid just let Git plug into that seamlessly.\n> \n> The problem is obviously harder on the Internet.  I've never\n> met anyone on this mailing list in person, but the quality (or\n> lack thereof sometimes) is evident in my work, and since its all\n> peer-reviewed anyway Junio finds little risk in incorporating the\n> good stuff into git.git.  No certificate required.\n\nIn theory, we could put certificates as blobs in the repository and \nreference them in the commit header. The names and such in the certificate \nwould, of course, not be verified in any particular way, but the \nfingerprint would be an effective identity. We'd be able to tell that a \ncommit was prepared by someone with access to the same certificate that \nwas used to build the reputation.\n\nIf we saw certificates with different fingerprints with the same name, \nwe'd know to ask what was going on, because that's suspicious.\n\nOf course, there would be no requirement to sign commits, or to have a \ncertificate, or to get anyone in particular to say anything in particular \nabout a certificate. But you'd be able to create a pseudonym if you \nwanted and have cryptographicly secure access to it.\n\n\t-Daniel\n*This .sig left intentionaly blank*\n"},{"id":"31766","messageId":"20070115211120.GA1987@coredump.intra.peff.net","threadId":"6378","inReplyTo":"eognu3$tje$1@sea.gmane.org","subject":"Re: Commit signing","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-01-15T21:11:20Z","receivedAt":"2007-01-15T21:11:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 15, 2007 at 09:24:55PM +0100, Jakub Narebski wrote:\n\n> By the way, how to make tag pointing to a out-of-tree blob, like\n> junio-gpg-pub tag in git.git?\n\ngit-tag will accept the usual object syntax:\n  git-tag magic HEAD:foo\n  git-tag magic e69de29bb2d1d6434b8b29ae775ad8c2e48c5391\n\nSo you just need to create the blob:\n  git-hash-object -w foo\n\nIf you make an annotated tag, git-show will give you the actual tag;\nlooks like it doesn't peel away unless it's a commit.\n\n-Peff\n"},{"id":"31778","messageId":"46a038f90701151426t7f25b50cl21a65c9b283829ef@mail.gmail.com","threadId":"6378","inReplyTo":"200701151923.07493.andyparkins@gmail.com","subject":"Re: Commit signing","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-01-15T22:26:50Z","receivedAt":"2007-01-15T22:26:50Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 1/16/07, Andy Parkins <andyparkins@gmail.com> wrote:\n> On Monday 2007, January 15 18:36, Martin Langhoff wrote:\n>\n> > >  * Vandal spends one year developing reasonable relationship with Idiot,\n> > > all patches are good.  Occasional big patches are pulled by Idiot.\n> >\n> > If you are using signatures, the trojan horse would make sure he gets\n> > his patches signed. What is the advantage again?\n>\n> He can't sign it as someone else, and so when it is eventually discovered the\n> culprit can be hunted down and flogged.\n\nFair enough. But you should should not pull from peripheral devs.\nEver. Core developers pull from eachother, everyone else posts\npatches. That's how it's meant to be used.\n\nAnd if you do a pull from a peripheral developer (to grab a specific\ninteresting patch series), you review it to check it contains what you\nexpect. As the person doing the merge, _your_ name is on the line.\n\n> > IIRC Linus discussed this early on, and his view was that authorship\n> > only gives you false security. The only security is in reviewing code.\n> > And that the code-signed patches are dog-slow too.\n>\n> Eh? It's only a little bit of extra text to carry around.  It's signed by the\n> original author when it enters a repository, so it's not a huge price to pay\n> in any one place.  The checking, if you wanted to enable it, would only be\n> done once per incoming commit to a master repository.  All-in-all, nothing\n> that you wouldn't be willing to pay if you wanted this feature.\n\nI guess the argument was against the cost of running expensive checks\nin operations that should be fast. On the other hand, if youare happy\nfor the git internal machinery to ignore alll this, you _could_ add\nthis trivially with a slight modification of the commit msg.\n\nAt commit-time, just add a signature block at the bottom, making sure\nyou are including the tree and parent SHA1s in the text signed by the\ncommit (the commit however will have no GPG starts here\" line at the\ntop when it is displayed).\n\n> As an aside; I would also suggest that this isn't just about people trojaning\n> a commit.  You could also argue that without it, this whole Signed-Off-By\n> business is a bit a moot point.\n\nWell, it's covered by a trust-but-review ethos...\n\n> The signed-off-by lines in the kernel are being used to establish original\n> authorship and entry path of every line in the kernel.  It's fairly worthless\n> though when the \"signing\" is just someone writing an easily forged line of\n> text.  For example, what is to stop that naughty lad Linus from adding some\n> code the infringes a copyright to the kernel and adding a \"Signed-Off-By:\n> Martin Langhoff\" to the bottom?  Equally, when SCO come knocking with\n> their \"we wrote that line\", a secure digital signature chain would go a long\n> way to proving that a submission wasn't faked.\n\nOh, evil Linus. It takes a bit more work to take my name in vain. SMTP\nhosts, IP addresses of the sending machine, etc. And yet...\n\n<social, nontechnical commentary follows>\n\n... you probably know about Debian and its keysigning parties. One of\nthe net results is that pretty much nobody reviews the work developers\ndo in their packages. Nobody. All signed and pretty, but in most\ndebian packages the review is nil. And you can mostly trust that a\ngiven upload came from me or someone that has my keys. Sure. But trust\nhas smothered review.\n\nSo while I don't disagree that it can be implemented easily, I doubt\nit will improve the technical quality of a project to introduce it.\nAnd it is trivial to prove that it   lowers the social/human quality,\nas it brings in all sorts of politics and exclusion games (present in\nCVS/SVN today). Starting from the \"are you in the keychain?\" game, to\nforcing passport-based keysigning parties (not bad in itself) that\nlead to bs like \"I don't trust non-western-central-country-passports\",\n\"I don't think you look like your passport picture\". And then smart\npeople get tired and do stuff like this\nhttp://blog.madduck.net/geek/2006.05.24-tr-id-at-keysigning\n\nSorry about the rant :-) but I consider this kind of stuff a good\nreason to stay away from a project. Judge the patch, nothing else.\n\n\n\nmartin\n"}]}