{"thread":{"id":"13317","subject":"Tracability in git commits","startedAt":"2008-04-29T12:55:39Z","lastAt":"2008-05-01T22:21:41Z","messageCount":15,"participants":["Richard Purdie","Johannes Schindelin","Junio C Hamano","Shawn O. Pearce","Jakub Narebski","Ping Yin","Miklos Vajna","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"75526","messageId":"1209473739.5642.31.camel@dax.rpnet.com","threadId":"13317","inReplyTo":null,"subject":"Tracability in git commits","fromName":"Richard Purdie","fromEmail":"rpurdie@rpsys.net","sentAt":"2008-04-29T12:55:39Z","receivedAt":"2008-04-29T12:55:39Z","isPatch":false,"sender":{"key":"rpurdie@rpsys.net","avatar":null},"body":"Hi,\n\nI've been wondering about whether its possible to provide some degree of\ntraceability of commits to a shared git repository. The potential\nnightmare scenario is one developer making a commit pretending to be\nsomeone else.\n\nAssuming a shared server using something like gitosis each set of\ncommits is made under a certain ssh ID and what I'd like is to be able\nto validate that against the commits so we could tell that commits A-D\nwere made by ID Z.\n\nI see a repository as a linear progression of commits and merges.\n\nThe simplest security check would check each commit/merge on this linear\nprogression and make sure it matches the ssh ID. The problem is where\nsomeone merges in some external tree, someone else pulls it and pushes\nit, only fast forward merges are made and the ssh 'ID' no longer matches\nthe ID of the merge which is in the linear path.\n\nSomeone mentioned some patches that are on the mailing list atm and the\nidea of never allowing fast forward merges. Would the \"never\" policy of\nfast forward merges solve this problem? Is there a simpler way to\naddress this or are there problems I'm not seeing?\n\nRegards,\n\nRichard\n"},{"id":"75541","messageId":"alpine.DEB.1.00.0804291707210.27457@eeepc-johanness","threadId":"13317","inReplyTo":"1209473739.5642.31.camel@dax.rpnet.com","subject":"Re: Tracability in git commits","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-29T16:08:24Z","receivedAt":"2008-04-29T16:08:24Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 29 Apr 2008, Richard Purdie wrote:\n\n> I've been wondering about whether its possible to provide some degree of \n> traceability of commits to a shared git repository. The potential \n> nightmare scenario is one developer making a commit pretending to be \n> someone else.\n\nYou will probably not like my answer: if you do not trust your fellow \ndevelopers, do not use a shared repository. Use clones (such as Linux' \nmany different repositories on kernel.org) instead.\n\nCiao,\nDscho\n"},{"id":"75585","messageId":"7vd4o873cm.fsf@gitster.siamese.dyndns.org","threadId":"13317","inReplyTo":"1209473739.5642.31.camel@dax.rpnet.com","subject":"Re: Tracability in git commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-29T21:34:01Z","receivedAt":"2008-04-29T21:34:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Richard Purdie writes:\n\n> Assuming a shared server using something like gitosis each set of\n> commits is made under a certain ssh ID and what I'd like is to be able\n> to validate that against the commits so we could tell that commits A-D\n> were made by ID Z.\n\nFirst of all, you need to learn the differences between making commits and\nupdating remote repositories. Push does not create commits, it only\npropagates a new part of commit DAG created elsewhere.\n\nWhen you grant rights to a person to update the tip of a branch of a\nrepository, you are saying that you trust the person to advance the\nhistory recorded on that branch in a way that is compatible with the goal\nof the branch of your repository.\n\nWhether you like it or not, git is a distributed system and git does not\ncare how that other person came up with the new part of the history. The\nperson may find somebody else's work that is useful and apply patches to\nhis history (introducing commits whose authors are not himself), or merge\nit (introducing commits whose committer are not himself), but you trust\nthat the person who does so uses good judgement, the same good judgement\nhe uses when making changes on his own.\n\nAnd then the branch you granted the right to update its tip to that person\nis updated, using that added part of the history. The updates to the tip\nwill be recorded in reflog to record who updated the tip and when, which\nwould allow you to go back and point your finger at the person who\nintroduced problematic new history and at that point you really do not\ncare if the problem you have with the new history was due to faulty\ncommits the pusher made himself, was introduced by a merge the pusher did,\nor was applied by the pusher from his mailbox.\n"},{"id":"75596","messageId":"1209506199.5642.66.camel@dax.rpnet.com","threadId":"13317","inReplyTo":"7vd4o873cm.fsf@gitster.siamese.dyndns.org","subject":"Re: Tracability in git commits","fromName":"Richard Purdie","fromEmail":"rpurdie@rpsys.net","sentAt":"2008-04-29T21:56:39Z","receivedAt":"2008-04-29T21:56:39Z","isPatch":false,"sender":{"key":"rpurdie@rpsys.net","avatar":null},"body":"On Tue, 2008-04-29 at 14:34 -0700, Junio C Hamano wrote:\n> Richard Purdie writes:\n> \n> > Assuming a shared server using something like gitosis each set of\n> > commits is made under a certain ssh ID and what I'd like is to be able\n> > to validate that against the commits so we could tell that commits A-D\n> > were made by ID Z.\n> \n> First of all, you need to learn the differences between making commits and\n> updating remote repositories. Push does not create commits, it only\n> propagates a new part of commit DAG created elsewhere.\n\nI understand that, yes. I also understood the remote repository to be\nable to accept or reject commits/merges through its hooks?\n\n> When you grant rights to a person to update the tip of a branch of a\n> repository, you are saying that you trust the person to advance the\n> history recorded on that branch in a way that is compatible with the goal\n> of the branch of your repository.\n\nbut you can put a policy in place for that in the hooks if desired?\n\n> Whether you like it or not, git is a distributed system and git does not\n> care how that other person came up with the new part of the history. The\n> person may find somebody else's work that is useful and apply patches to\n> his history (introducing commits whose authors are not himself), or merge\n> it (introducing commits whose committer are not himself), but you trust\n> that the person who does so uses good judgement, the same good judgement\n> he uses when making changes on his own.\n\nI appreciate this can happen and is often part of the normal workflow. I\nhave no objection to that, its more a question about whether it can be\ncontrolled or at least logged...\n\n> And then the branch you granted the right to update its tip to that person\n> is updated, using that added part of the history. The updates to the tip\n> will be recorded in reflog to record who updated the tip and when, which\n> would allow you to go back and point your finger at the person who\n> introduced problematic new history and at that point you really do not\n> care if the problem you have with the new history was due to faulty\n> commits the pusher made himself, was introduced by a merge the pusher did,\n> or was applied by the pusher from his mailbox.\n\nThis sounds like my answer, it's possible to trace who did what from the\nreflog. Which area of code is responsible for updating the reflog, is it\nin git itself or is it in the form of a hook? \n\nI'm asking since if the repository is read/write for several users,\nfaking the log is easy. If you use something like gitosis it runs under\none user and faking is hard due to the restricted access. There is\nprobably a need to feed extra information into whatever is making the\nlog, or generate an additional log though due to the single user?\n\nThanks,\n\nRichard\n"},{"id":"75624","messageId":"20080430025102.GS29771@spearce.org","threadId":"13317","inReplyTo":"1209506199.5642.66.camel@dax.rpnet.com","subject":"Re: Tracability in git commits","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-04-30T02:51:03Z","receivedAt":"2008-04-30T02:51:03Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Richard Purdie wrote:\n> On Tue, 2008-04-29 at 14:34 -0700, Junio C Hamano wrote:\n> > Richard Purdie writes:\n> > \n> > > Assuming a shared server using something like gitosis each set of\n> > > commits is made under a certain ssh ID and what I'd like is to be able\n> > > to validate that against the commits so we could tell that commits A-D\n> > > were made by ID Z.\n>\n> [...] I also understood the remote repository to be\n> able to accept or reject commits/merges through its hooks?\n\nYes. Look at contrib/hooks/update-paranoid for an example hook that\nvalidates the committer name and email address of each new commit\nmatches with the real posix uid performing the push. I use this\nhook at day-job to validate pushes made by users over SSH through\na setuid git-receive-pack process.\n\nThe receive-pack program was patched to make it safer under setuid.\nMy patched version drops the setuid privs if the repository it\nwill write to or the hook(s) it will invoke are writable or owned\nby anyone other than the effective uid.\n\nBut update-paranoid could be adapted to verify committer name/email\nby some means other than just posix uid, such as by SSH public key.\n \n> > And then the branch you granted the right to update its tip to that person\n> > is updated, using that added part of the history. The updates to the tip\n> > will be recorded in reflog to record who updated the tip and when, [...]\n> \n> This sounds like my answer, it's possible to trace who did what from the\n> reflog. Which area of code is responsible for updating the reflog, is it\n> in git itself or is it in the form of a hook? \n\nPretty much all of git automatically updates the reflog when a\nchange takes place. On the receiving side of a push event its\ngit-receive-pack that is handling the repository updates, and one\nof the functions it calls is to add the event to the branch's reflog.\n\n> I'm asking since if the repository is read/write for several users,\n> faking the log is easy. If you use something like gitosis it runs under\n> one user and faking is hard due to the restricted access. There is\n> probably a need to feed extra information into whatever is making the\n> log, or generate an additional log though due to the single user?\n\nRight. The reflog events are actually logged using the value of the\nenvironment variables GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL.\n\nSo if you set these with whatever identity you want use prior\nto invoking the server side git-receive-pack, you will get that\ninformation in the reflog. By default if these aren't set we use\nthe gecos information of the real uid.\n\nSecuring a repository means protecting limiting access to it.\nYou can reasonably protect a repository by making only a specific\nuser able to run git-receive-pack in that repository, but then\nyou need to arrange for individual users to execute as that user\nover SSH. The forced command feature associated with public keys\nis often used for this, and its how gitosis does it.\n\nMy setuid hack to receive-pack will likely be retired at day-job\nin the future. We will either stop using git entirely, or we will\ntransfer over to forced commands in a common user authorized_keys,\nlike gitosis does.\n\n-- \nShawn.\n"},{"id":"75663","messageId":"m3lk2vodw4.fsf@localhost.localdomain","threadId":"13317","inReplyTo":"1209473739.5642.31.camel@dax.rpnet.com","subject":"Re: Tracability in git commits","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-04-30T10:06:43Z","receivedAt":"2008-04-30T10:06:43Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Richard Purdie writes:\n\n> I've been wondering about whether its possible to provide some degree of\n> traceability of commits to a shared git repository. The potential\n> nightmare scenario is one developer making a commit pretending to be\n> someone else.\n[cut]\n\nIf you really need that, perhaps you would be better with using\nMonotone, with its elaborate security and trust-related features?\n\nIIRC we recommended Monotone to IPSec folks here...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"75668","messageId":"1209551520.5010.20.camel@dax.rpnet.com","threadId":"13317","inReplyTo":"m3lk2vodw4.fsf@localhost.localdomain","subject":"Re: Tracability in git commits","fromName":"Richard Purdie","fromEmail":"rpurdie@rpsys.net","sentAt":"2008-04-30T10:32:00Z","receivedAt":"2008-04-30T10:32:00Z","isPatch":false,"sender":{"key":"rpurdie@rpsys.net","avatar":null},"body":"On Wed, 2008-04-30 at 03:06 -0700, Jakub Narebski wrote:\n> Richard Purdie writes:\n> \n> > I've been wondering about whether its possible to provide some degree of\n> > traceability of commits to a shared git repository. The potential\n> > nightmare scenario is one developer making a commit pretending to be\n> > someone else.\n> [cut]\n> \n> If you really need that, perhaps you would be better with using\n> Monotone, with its elaborate security and trust-related features?\n> \n> IIRC we recommended Monotone to IPSec folks here...\n\nThe project I'm thinking about is OpenEmbedded which used to use\nbitkeeper and switched to monotone when bitkeeper went private only.\n\nThe issues with monotone are ones of poor performance, particularly with\nthe usage patterns we have, lack of good branching/merging capabilities,\nlack of good web interfaces, high server load, some breakage issues and\na now general ill feeling amongst OE's developers.\n\nWhilst monotone has improved tremendously from where it was, I'm not\nsure certain features we need are going to appear in it within the\nmedium term which makes git look attractive.\n\nWhen we switched to monotone we also lost our bitkeeper history which\nI'd like to see us reunited with. I've been trying to make a sane\nconversion of the bkcvs dump to git using git-cvsimport and the bkcvs\nmode of cvsps but I'm having problems which I'll perhaps mention in\nanother email once I've had time to try and understand them properly.\n\nIts by no means certain OE will switch but we want to setup a git trial\nsystem and see exactly what we gain/lose. Evaluating the 'security'\nconsequences of a move is part of the equation. hg is another option\nunder consideration but not many of us have experience of it and we're\nwary of choosing an SCM with a smallish userbase again amongst other\nthings.\n\nCheers,\n\nRichard\n"},{"id":"75700","messageId":"46dff0320804301033k1dea34ecx863ecfa8e386e0af@mail.gmail.com","threadId":"13317","inReplyTo":"7vd4o873cm.fsf@gitster.siamese.dyndns.org","subject":"Re: Tracability in git commits","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2008-04-30T17:33:53Z","receivedAt":"2008-04-30T17:33:53Z","isPatch":false,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"On Wed, Apr 30, 2008 at 5:34 AM, Junio C Hamano wrote:\n\n\n> is updated, using that added part of the history. The updates to the tip\n> will be recorded in reflog to record who updated the tip and when, which\n> would allow you to go back and point your finger at the person who\n> introduced problematic new history\n\nI don't find reflog for bare repository, or must i enable it manually?\n\n\n\n-- \nPing Yin\n"},{"id":"75709","messageId":"20080430194651.GC23672@genesis.frugalware.org","threadId":"13317","inReplyTo":"46dff0320804301033k1dea34ecx863ecfa8e386e0af@mail.gmail.com","subject":"Re: Tracability in git commits","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-04-30T19:46:51Z","receivedAt":"2008-04-30T19:46:51Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Thu, May 01, 2008 at 01:33:53AM +0800, Ping Yin wrote:\n> I don't find reflog for bare repository, or must i enable it manually?\n\nRight, reflog is disabled by default for bare repos.\n"},{"id":"75725","messageId":"20080501002827.GX29771@spearce.org","threadId":"13317","inReplyTo":"20080430194651.GC23672@genesis.frugalware.org","subject":"Re: Tracability in git commits","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-05-01T00:28:27Z","receivedAt":"2008-05-01T00:28:27Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Miklos Vajna wrote:\n> On Thu, May 01, 2008 at 01:33:53AM +0800, Ping Yin wrote:\n> > I don't find reflog for bare repository, or must i enable it manually?\n> \n> Right, reflog is disabled by default for bare repos.\n\n`git config core.logAllRefUpdates true` right after you make the\nrepository solves that nicely. I actually have a script that I use\nto make a new bare central repo:\n\n\t#!/bin/sh\n\tgit --git-dir=\"$1\" init &&\n\tgit --git-dir=\"$1\" config core.logAllRefUpdates true ||\n\texit\n\n;-)\n\n-- \nShawn.\n"},{"id":"75729","messageId":"46a038f90804301826xaf5d73bl1d29a07bc930a716@mail.gmail.com","threadId":"13317","inReplyTo":"1209551520.5010.20.camel@dax.rpnet.com","subject":"Re: Tracability in git commits","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2008-05-01T01:26:09Z","receivedAt":"2008-05-01T01:26:09Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Wed, Apr 30, 2008 at 10:32 PM, Richard Purdie wrote:\n> The project I'm thinking about is OpenEmbedded which used to use\n> bitkeeper and switched to monotone when bitkeeper went private only.\n\nRichard,\n\nyou might be able to use a slightly tweaked workflow where you\n\n 1 - Prepare a GPG-signed list of the commit hashes you are about to push\n 2 - Push to an \"incoming\" repository that does weak or no validation\n 3 - Push/publish your GPG-signed list of commit hashes\n 4 - A script \"pushes\" commits from the \"incoming\" repo to a\n\"verified\" repo after checking that they are backed by a GPG-signed\nlist. For ease of use, this can happen on the server ASAP, and it can\nbe validated independently by any party. Notably, it is probably a\ngood idea that it is validated shortly before a release is tagged.\n\nThis way, you keep the flexible/fast properties of git, but use the\nSHA1 commit->tree>file relationship plus external wrapper scripts to\nadd auditing capabilities that are open and repeatable.\n\nSo all you need is\n\n - a trivial \"push\" wrapper that prepares the commits-to-push list and\nautomates the signing and publishing of the list\n - a trivial script to run the migration of verified commits\n\ncheers,\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- School Server Architect\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"75732","messageId":"46dff0320804302209o2af9d630s48564a9b68c24ec1@mail.gmail.com","threadId":"13317","inReplyTo":"20080501002827.GX29771@spearce.org","subject":"Re: Tracability in git commits","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2008-05-01T05:09:45Z","receivedAt":"2008-05-01T05:09:45Z","isPatch":false,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"On Thu, May 1, 2008 at 8:28 AM, Shawn O. Pearce wrote:\n\n> `git config core.logAllRefUpdates true` right after you make the\n> repository solves that nicely. I actually have a script that I use\n> to make a new bare central repo:\n>\n> #!/bin/sh\n> git --git-dir=\"$1\" init &&\n> git --git-dir=\"$1\" config core.logAllRefUpdates true ||\n> exit\n\nI wonder why not make it the default behaviour. If someone push the\nwrong commit to the bare repository (for example, with 'git push -f'),\nthere is no easy way to recover without reflog.\n\nSo as a solution, i would rather put this config to ~/.gitconfig\n\n\n\n\n-- \nPing Yin\n"},{"id":"75735","messageId":"46a038f90805010034y3ffd3eb5hbee7c2200912eef3@mail.gmail.com","threadId":"13317","inReplyTo":"46a038f90804301826xaf5d73bl1d29a07bc930a716@mail.gmail.com","subject":"Re: Tracability in git commits","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2008-05-01T07:34:55Z","receivedAt":"2008-05-01T07:34:55Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Thu, May 1, 2008 at 1:26 PM, Martin Langhoff\n wrote:\n> 4 - A script \"pushes\" commits from the \"incoming\" repo to a\n> \"verified\" repo after checking that they are backed by a GPG-signed\n> list. For ease of use, this can happen on the server ASAP, and it can\n> be validated independently by any party. Notably, it is probably a\n> good idea that it is validated shortly before a release is tagged.\n>\n> This way, you keep the flexible/fast properties of git\n\nNote that with this, you *can* also keep the ability for someone to\npush commits that they are not the author or committer for. This is\nactually added flexibility - you can merge from a 3rd party tree, and\npush it to the central repo, as long as you GPG-sign the list\nincluding those commits.\n\nI highlight \"can\" because the wrapper on the developer side and the\nscript on the server side can prevent this, or force extra steps in\nsuch case.\n\ncheers,\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- School Server Architect\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"75775","messageId":"7v63txzw18.fsf@gitster.siamese.dyndns.org","threadId":"13317","inReplyTo":"46a038f90805010034y3ffd3eb5hbee7c2200912eef3@mail.gmail.com","subject":"Re: Tracability in git commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-05-01T19:03:47Z","receivedAt":"2008-05-01T19:03:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Martin Langhoff\" writes:\n\n> On Thu, May 1, 2008 at 1:26 PM, Martin Langhoff\n> wrote:\n>> 4 - A script \"pushes\" commits from the \"incoming\" repo to a\n>> \"verified\" repo after checking that they are backed by a GPG-signed\n>> list. For ease of use, this can happen on the server ASAP, and it can\n>> be validated independently by any party. Notably, it is probably a\n>> good idea that it is validated shortly before a release is tagged.\n>>\n>> This way, you keep the flexible/fast properties of git\n>\n> Note that with this, you *can* also keep the ability for someone to\n> push commits that they are not the author or committer for. This is\n> actually added flexibility - you can merge from a 3rd party tree, and\n> push it to the central repo, as long as you GPG-sign the list\n> including those commits.\n>\n> I highlight \"can\" because the wrapper on the developer side and the\n> script on the server side can prevent this, or force extra steps in\n> such case.\n>\n> cheers,\n\nI suspect that, with the \"push to incoming, vet there and move to\nverified\" workflow, you do not need a special GPG-signed list. You can\ninstead have the pusher sign the tip using the usual signed-tag mechanism,\nwhich would sign the whole history leading to it, and have him push that\ntag to the incoming together with the tip update. You obviously do not\nneed nor want to move that signed tag to the final area.\n"},{"id":"75785","messageId":"46a038f90805011521s1d7f5d42k2e9186e5fd4c43b3@mail.gmail.com","threadId":"13317","inReplyTo":"7v63txzw18.fsf@gitster.siamese.dyndns.org","subject":"Re: Tracability in git commits","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2008-05-01T22:21:41Z","receivedAt":"2008-05-01T22:21:41Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Fri, May 2, 2008 at 7:03 AM, Junio C Hamano wrote:\n> I suspect that, with the \"push to incoming, vet there and move to\n> verified\" workflow, you do not need a special GPG-signed list. You can\n> instead have the pusher sign the tip using the usual signed-tag mechanism,\n> which would sign the whole history leading to it, and have him push that\n> tag to the incoming together with the tip update. You obviously do not\n> need nor want to move that signed tag to the final area.\n\nYes. Though it makes a post-facto audit of who-pushed-which-commits\ntrickier - you'll have to correlate the reflogs in the server with the\nsigned tags. Having an explicit signature on a list of commits is a\nbit more direct, easier to audit... IMHO anyway ;-)\n\ncheers,\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- School Server Architect\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"}]}