{"thread":{"id":"194","subject":"Re: Git-commits mailing list feed.","startedAt":"2005-04-21T12:23:55Z","lastAt":"2005-04-25T09:31:37Z","messageCount":55,"participants":["David Woodhouse","Linus Torvalds","Fabian Franz","Thomas Glanzmann","Jan Harkes","Sean","Junio C Hamano","David A. Wheeler","Jeff Garzik","Mike Taht","Andreas Gal","Paul Jakma","Matt Domsch","Daniel Barkalow","David Greaves"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"1119","messageId":"1114086237.29135.24.camel@localhost.localdomain","threadId":"194","inReplyTo":"1114079347.6277.29.camel@laptopd505.fenrus.org","subject":"Re: Git-commits mailing list feed.","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2005-04-21T12:23:55Z","receivedAt":"2005-04-21T12:23:55Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2005-04-21 at 12:29 +0200, Arjan van de Ven wrote:\n> with BK this was not possible, but could we please have -p added to the\n> diff parameters with git ? It makes diffs a LOT more reasable!\n\nWith BK this was not possible, but could you please provide your\ncriticism in 'diff -up' form?\n\nI've done 'perl -pi -e s/-u/-up/ gitdiff-do' as a quick hack to provide\nwhat you want, but a saner fix to make gitdiff-do obey the same\nGIT_DIFF_CMD and GIT_DIFF_OPTS environment variables as show-diff.c\nwould be a more useful answer.\n\n-- \ndwmw2\n\n"},{"id":"1377","messageId":"Pine.LNX.4.58.0504231010580.2344@ppc970.osdl.org","threadId":"194","inReplyTo":"1114266907.3419.43.camel@localhost.localdomain","subject":"Re: Git-commits mailing list feed.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-23T17:31:28Z","receivedAt":"2005-04-23T17:31:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 24 Apr 2005, David Woodhouse wrote:\n> \n> Nah, asking Linus to tag his releases is the most comfortable way.\n> \n> mkdir .git/tags\n> echo 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 > .git/tags/2.6.12-rc2\n> echo a2755a80f40e5794ddc20e00f781af9d6320fafb > .git/tags/2.6.12-rc3\n\nThe reason I've not done tags yet is that I haven't decided how to do \nthem.\n\nThe git-pasky \"just remember the tag name\" approach certainly works, but I \nwas literally thinking o fsetting up some signing system, so that a tag \ndoesn't just say \"commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 is \nv2.6.12-rc2\", but it would actually give stronger guarantees, ie it would \nsay \"Linus says that commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 is \nhis 2.6.12-rc2 release\".\n\nThat's something fundamentally more powerful, and it's also something that \nI actually can integrate better into git.\n\nIn other words, I actually want to create \"tag objects\", the same way we \nhave \"commit objects\". A tag object points to a commit object, but in \naddition it contains the tag name _and_ the digital signature of whoever \ncreated the tag.\n\nThen you just distribute these tag objects along with all the other\nobjects, and fsck-cache can pick them up even without any other knowledge,\nbut normally you'd actually point to them some other way too, ie you could \nhave the \".git/tags/xxx\" files have the pointers, but now they are \n_validated_ pointers.\n\nThat was my plan, at least. But I haven't set up any signature generation\nthing, and this really isn't my area of expertise any more. But my _plan_ \nliterally was to have the tag object look a lot like a commit object, but \ninstead of pointing to the tree and the commit parents, it would point to \nthe commit you are tagging. Somehting like\n\n\tcommit a2755a80f40e5794ddc20e00f781af9d6320fafb\n\ttag v2.6.12-rc3\n\tsigner Linus Torvalds\n\n\tThis is my official original 2.6.12-rc2 release\n\n\t-----BEGIN PGP SIGNATURE-----\n\t....\n\t-----END PGP SIGNATURE-----\n\nwith a few fixed headers and then a place for free-form commentary, \neverything signed by the key (and then it ends up being encapsulated as an \nobject with the object type \"tag\", and SHA1-csummed and compressed, ie it \nends up being just another object as far as git is concerned, but now it's \nan object that tells you about _trust_)\n\n(The \"signer\" field is just a way to easily figure out which public key to\ncheck the signature against, so that you don't have to try them all. Or\nsomething. My point being that I know what I want, but because I normally \ndon't actually ever _use_ PGP etc, I don't know the scripts to create \nthese, so I've been punting on it all).\n\nIf somebody writes a script to generate the above kind of thing (and tells \nme how to validate it), I'll do the rest, and start tagging things \nproperly. Oh, and make sure the above sounds sane (ie if somebody has a \nbetter idea for how to more easily identify how to find the public key to \ncheck against, please speak up).\n\n\t\t\tLinus\n"},{"id":"1378","messageId":"Pine.LNX.4.58.0504231033500.2344@ppc970.osdl.org","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504231010580.2344@ppc970.osdl.org","subject":"Re: Git-commits mailing list feed.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-23T17:45:55Z","receivedAt":"2005-04-23T17:45:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 23 Apr 2005, Linus Torvalds wrote:\n> \n> \tcommit a2755a80f40e5794ddc20e00f781af9d6320fafb\n> \ttag v2.6.12-rc3\n> \tsigner Linus Torvalds\n> \n> \tThis is my official original 2.6.12-rc2 release\n> \n> \t-----BEGIN PGP SIGNATURE-----\n> \t....\n> \t-----END PGP SIGNATURE-----\n\nBtw, in case it wasn't clear, one of the advantages of this is that these\nobjects are really _not_ versioned themselves, and that they are totally \nindependent of the objects that they actually tag.\n\nThey spread together with all the other objects, so they fit very well\ninto the whole git infrastructure, but the real commit objects don't have\nany linkages to the tag and the tag objects themselves don't have any\nhistory amongst themselves, so you can create a tag at any (later) time,\nand it doesn't actually change the commit in any way or affect other tags \nin any way.\n\nIn particular, many different people can tag the same commit, and they\ndon't even need to tage their _own_ commit - you can use this tag objects\nto show that you trust somebody elses commit. You can also throw the tag\nobjects away, since nothing else depends on them and they have nothing\nlinking to them - so you can make a \"one-time\" tag object that you can\npass off to somebody else, and then delete it, and now it's just a\n\"temporary tag\"  that tells the recipient _something_ about the commit you\ntagged, but that doesn't stay around in the archive.\n\nThat's important, because I actually want to have the ability for people \nwho want me to pull from their archive to send me a message that says \n\"pull from this archive, and btw, here's the tag that not only tells you \nwhich head to merge, but also proves that it was me who created it\".\n\nWill we use this? Maybe not. Quite frankly, I think human trust is much \nmore important than automated trust through some technical means, but I \nthink it's good to have the _support_ for this kind of trust mechanism \nbuilt into the system. And I think it's a good way for distributors etc to \nsay: \"this is the source code we used to build the kernel that we \nreleased, and we tagged it 'v2.6.11-mm6-crazy-fixes-3.96'\".\n\nAnd if my key gets stolen, I can re-generate all the tags (from my archive\nof tags that I trust), and sign them with a new key, and revoke the trust\nof my old key. This is why it's important that tags don't have\ninterdependencies, they are just a one-way \"this key trusts that release\nand calls it xyzzy\".\n\n\t\tLinus\n"},{"id":"1379","messageId":"200504231950.43903.FabianFranz@gmx.de","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504231010580.2344@ppc970.osdl.org","subject":"Re: Git-commits mailing list feed.","fromName":"Fabian Franz","fromEmail":"fabianfranz@gmx.de","sentAt":"2005-04-23T17:50:39Z","receivedAt":"2005-04-23T17:50:39Z","isPatch":false,"sender":{"key":"fabianfranz@gmx.de","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nAm Samstag, 23. April 2005 19:31 schrieb Linus Torvalds:\n> On Sun, 24 Apr 2005, David Woodhouse wrote:\n> > Nah, asking Linus to tag his releases is the most comfortable way.\n> >\n> The reason I've not done tags yet is that I haven't decided how to do\n> them.\n>\n> \tcommit a2755a80f40e5794ddc20e00f781af9d6320fafb\n> \ttag v2.6.12-rc3\n> \tsigner Linus Torvalds\n>\n> \tThis is my official original 2.6.12-rc2 release\n>\n> \t-----BEGIN PGP SIGNATURE-----\n> \t....\n> \t-----END PGP SIGNATURE-----\n>\n> If somebody writes a script to generate the above kind of thing (and tells\n> me how to validate it), I'll do the rest, and start tagging things\n> properly. Oh, and make sure the above sounds sane (ie if somebody has a\n> better idea for how to more easily identify how to find the public key to\n> check against, please speak up).\n\nTo generate those you do:\n\n# cat unsigned_tag\n\n\tcommit a2755a80f40e5794ddc20e00f781af9d6320fafb\n\ttag v2.6.12-rc3\n\tsigner Linus Torvalds\n\tThis is my official original 2.6.12-rc2 release\n\n# gpg --clearsign < unsigned_tag > signed_tag # gpg will ask here for the \nsecret key phrase\n\nTo verify you do:\n\n# gpg --verify < signed_tag\n\nand check exit status.\n\nHope that helps,\n\ncu\n\nFabian \n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.2.4 (GNU/Linux)\n\niD8DBQFCaorzI0lSH7CXz7MRAr3QAJ45f2CQTgJ0sYfF9kRyrWHbsazVQQCeMqW7\nHCsah/llt/I8sQ36dlDnRWg=\n=Fgq1\n-----END PGP SIGNATURE-----\n\n"},{"id":"1389","messageId":"2646.10.10.10.24.1114278656.squirrel@linux1","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504231010580.2344@ppc970.osdl.org","subject":"Re: Git-commits mailing list feed.","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2005-04-23T17:50:56Z","receivedAt":"2005-04-23T17:50:56Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, April 23, 2005 1:31 pm, Linus Torvalds said:\n\n> If somebody writes a script to generate the above kind of thing (and\ntells me how to validate it), I'll do the rest, and start tagging things\nproperly. Oh, and make sure the above sounds sane (ie if somebody has a\nbetter idea for how to more easily identify how to find the public key to\n> check against, please speak up).\n>\n\nHi Linus,\n\nWhy not leave tags open to being signed or unsigned?  Anyone that wants to\ncreate a trusted tag could simply sign their cleartext entry in the tag\nobject.\n\nIdeally the SHA1 tree reference would be included in the text entry\nwhether it was signed or not.   Thus any script can pull the SHA1 out of\nthe text entry.  And a script that understands the signing method can\nverify it.  But scripts that don't understand the signing method can still\nuse the tag.\n\nFor presentation in the log or whatever, the script can look inside the\nclear text message, grab the SHA1 and display it in the header area; even\nthough it's not really in the header, always just in the clear text area.\n\nSean\n\n\n\n\n\n\n"},{"id":"1380","messageId":"20050423175422.GA7100@cip.informatik.uni-erlangen.de","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504231010580.2344@ppc970.osdl.org","subject":"Re: Git-commits mailing list feed.","fromName":"Thomas Glanzmann","fromEmail":"sithglan@stud.uni-erlangen.de","sentAt":"2005-04-23T17:54:22Z","receivedAt":"2005-04-23T17:54:22Z","isPatch":false,"sender":{"key":"sithglan@stud.uni-erlangen.de","avatar":null},"body":"Hello,\n\nthere is no need to tell the verifier against what key to verify because\nthe signature already contains this information.\n\n> If somebody writes a script to generate the above kind of thing (and\n> tells me how to validate it), I'll do the rest, and start tagging\n> things properly. Oh, and make sure the above sounds sane (ie if\n> somebody has a better idea for how to more easily identify how to find\n> the public key to check against, please speak up).\n\n# This creates the signature.\ngpg --clearsign < sign_this > signature\n\n# And this verifies it. \ngpg --verify < signature && echo valid\n\n\tThomas\n"},{"id":"1392","messageId":"2911.10.10.10.24.1114279589.squirrel@linux1","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504231125330.2344@ppc970.osdl.org","subject":"Re: Git-commits mailing list feed.","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2005-04-23T18:06:29Z","receivedAt":"2005-04-23T18:06:29Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, April 23, 2005 2:30 pm, Linus Torvalds said:\n> On Sat, 23 Apr 2005, Thomas Glanzmann wrote:\n>> # This creates the signature.\n>> gpg --clearsign < sign_this > signature\n>\n> This really doesn't work for me - I do not want to have the gpg header\nabove it, only the signature below. Since I want git to actually\nunderstand the tags, but do _not_ want git to have to know about\nwhatever\n> signing method was used, I really want the resulting file to look like\n>\n> \tcommit ....\n> \ttag ...\n>\n> \there goes comment\n> \there goes signature\n>\n> and no headers.\n>\n> Whether that can be faked by always forcing SHA1 as the hash, and then\njust removing the top lines, and re-inserting them when verifying, or\nwhether there is some mode to make gpg not do the header crud at all, I\ndon't know. Which is exactly why I never even got started.\n\nLinus,\n\nA script that knows how to validate signed tags, can easly strip off all\nthe signing overhead for display.   Users of scripts that don't understand\nwill see the cruft, but at least it will still be usable.\n\nSean\n\n\n"},{"id":"1394","messageId":"1242.10.10.10.24.1114280097.squirrel@linux1","threadId":"194","inReplyTo":"20050423190257.GA4194@cip.informatik.uni-erlangen.de","subject":"Re: Git-commits mailing list feed.","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2005-04-23T18:14:57Z","receivedAt":"2005-04-23T18:14:57Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, April 23, 2005 3:02 pm, Thomas Glanzmann said:\n> Hello,\n>\n>> Why not leave tags open to being signed or unsigned?\n>\n> I think that this is the idea anyway.\n>\n>> For presentation in the log or whatever, the script can look inside the\n>> clear text message, grab the SHA1 and display it in the header area;\n>> even\n>> though it's not really in the header, always just in the clear text\n>> area.\n>\n> Having the SHA1 signature twice in would be confusing and error-prone\n> when checking is done automated.\n>\n> So establishing the infrastructure is a good thing. To use it for every\n> commit is another issue.\n\n\nThere's no need to have the SHA1 object reference twice.  It will only be \nin the clear text, nowhere else.  Of course scripts that display the log,\ncould show the object reference in the header area for aesthetics. \nAnother nice thing is that this works no matter cleartext signing methods\nemerge in the future.\n\nSean\n\n\n\n"},{"id":"1383","messageId":"Pine.LNX.4.58.0504231125330.2344@ppc970.osdl.org","threadId":"194","inReplyTo":"20050423175422.GA7100@cip.informatik.uni-erlangen.de","subject":"Re: Git-commits mailing list feed.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-23T18:30:36Z","receivedAt":"2005-04-23T18:30:36Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 23 Apr 2005, Thomas Glanzmann wrote:\n> \n> # This creates the signature.\n> gpg --clearsign < sign_this > signature\n\nThis really doesn't work for me - I do not want to have the gpg header\nabove it, only the signature below. Since I want git to actually\nunderstand the tags, but do _not_ want git to have to know about whatever\nsigning method was used, I really want the resulting file to look like\n\n\tcommit ....\n\ttag ...\n\n\there goes comment\n\there goes signature\n\nand no headers.\n\nWhether that can be faked by always forcing SHA1 as the hash, and then \njust removing the top lines, and re-inserting them when verifying, or \nwhether there is some mode to make gpg not do the header crud at all, I \ndon't know. Which is exactly why I never even got started.\n\n\t\tLinus\n"},{"id":"1384","messageId":"20050423183406.GD20410@delft.aura.cs.cmu.edu","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504231010580.2344@ppc970.osdl.org","subject":"Re: Git-commits mailing list feed.","fromName":"Jan Harkes","fromEmail":"jaharkes@cs.cmu.edu","sentAt":"2005-04-23T18:34:07Z","receivedAt":"2005-04-23T18:34:07Z","isPatch":false,"sender":{"key":"jaharkes@cs.cmu.edu","avatar":"https://gravatar.com/avatar/cf95aecd150ca8ef33d6edc337ac4bb9e13aa4246fc3679257d578c7fddc1633?d=mp&s=160"},"body":"On Sat, Apr 23, 2005 at 10:31:28AM -0700, Linus Torvalds wrote:\n> In other words, I actually want to create \"tag objects\", the same way we \n> have \"commit objects\". A tag object points to a commit object, but in \n> addition it contains the tag name _and_ the digital signature of whoever \n> created the tag.\n\nI see how we can use such a tag object to find a specific commit object\nin the tree. But if you put the tag objects in the tree as well we now\nhave to figure out a way to find the tag objects.\n\nWhy not keep the tags object outside of the tree in the tags/ directory.\nThat way it is easy to find them, and simple to validate all tags or\nupdate the signatures if you lost your key.\n\n> properly. Oh, and make sure the above sounds sane (ie if somebody has a \n> better idea for how to more easily identify how to find the public key to \n> check against, please speak up).\n\nOthers already mentioned the gpg clearsign and verify options, to find a\npublic key that you haven't seen before it is probably easiest to use a\nkeyserver. If verify complains that it doesn't know a key it will print\na key-id that identifies it. That id can then be looked up as follows,\n\n    gpg --keyserver wwwkeys.pgp.net --search-keys 0xA86B35C5\n    gpg: searching for \"0xA86B35C5\" from hkp server wwwkeys.pgp.net\n    (1)     Linus Torvalds <Linus.Torvalds@Helsinki.FI>\n\t\t1024 bit RSA key A86B35C5, created: 1996-06-08\n    Keys 1-1 of 1 for \"0xA86B35C5\".  Enter number(s), N)ext, or Q)uit > q\n\nOfcourse trusting a key obtained this way is another thing altogether,\nand would probably depend on who signed it and such.\n\nJan\n"},{"id":"1387","messageId":"20050423183909.GC7100@cip.informatik.uni-erlangen.de","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504231125330.2344@ppc970.osdl.org","subject":"Re: Git-commits mailing list feed.","fromName":"Thomas Glanzmann","fromEmail":"sithglan@stud.uni-erlangen.de","sentAt":"2005-04-23T18:39:09Z","receivedAt":"2005-04-23T18:39:09Z","isPatch":false,"sender":{"key":"sithglan@stud.uni-erlangen.de","avatar":null},"body":"Hello,\n\n> \tcommit ....\n> \ttag ...\n\n> \there goes comment\n> \there goes signature\n\n# This creates only the signature in Ascii Armor.\ngpg -a --detach-sign < to_sign > signature\n\n\tThomas\n"},{"id":"1400","messageId":"1907.10.10.10.24.1114281858.squirrel@linux1","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504231234550.2344@ppc970.osdl.org","subject":"Re: Git-commits mailing list feed.","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2005-04-23T18:44:18Z","receivedAt":"2005-04-23T18:44:18Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, April 23, 2005 3:38 pm, Linus Torvalds said:\n> On Sat, 23 Apr 2005, Sean wrote:\n>>\n>> A script that knows how to validate signed tags, can easly strip off all\n>> the signing overhead for display.   Users of scripts that don't\n>> understand\n>> will see the cruft, but at least it will still be usable.\n>\n> NO.\n>\n> Guys, I will say this once more: git will not look at the signature.\n>\n> That means that we don't \"strip them off\", because dammit, they DO NOT\n> EXIST as far as git is concerned. This is why a tag-file will _always_\n> start with\n>\n> \tcommit <commit-sha1>\n> \ttag <tag-name>\n>\n> because that way we can use fsck and validate reachability and have things\n> that want trees (or commits) take tag-files instead, and git will\n> automatically look up the associated tree/commit. And it will do so\n> _without_ having to understand about signing, since signing is for trust\n> between _people_ not for git.\n\nYes, totally agreed.\n\n> And that is why I from the very beginning tried to make ti very clear\n> that the signature goes at the end. Not at the beginning, not in the\n> middle, and not in a different file. IT GOES AT THE END.\n>\n\nOkay now you're just being difficult <g>   You're acting like it's\nimpossible for git to grab the SHA1 out of the clear text message if there\nis signing overhead above the tag reference.   That is nonesense.   You\nsimply state that tag must include a SHA1 object reference preceded by\n\"REF:\" in the comment.   Git can surely use this regardless of what\nsigning overhead is above, below or beside it.   The suggestion for\nstripping out the signing overhead was for _human_ readability; git won't\ncare a gnit.\n\nSean\n\n\n"},{"id":"1390","messageId":"20050423184438.GD7100@cip.informatik.uni-erlangen.de","threadId":"194","inReplyTo":"20050423183909.GC7100@cip.informatik.uni-erlangen.de","subject":"Re: Git-commits mailing list feed.","fromName":"Thomas Glanzmann","fromEmail":"sithglan@stud.uni-erlangen.de","sentAt":"2005-04-23T18:44:38Z","receivedAt":"2005-04-23T18:44:38Z","isPatch":false,"sender":{"key":"sithglan@stud.uni-erlangen.de","avatar":null},"body":"Hello,\n\n> # This creates only the signature in Ascii Armor.\n> gpg -a --detach-sign < to_sign > signature\n\n# And to verify:\ngpg --verify signature to_sign\n\n\tThomas\n"},{"id":"1386","messageId":"20050423184613.GE20410@delft.aura.cs.cmu.edu","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504231125330.2344@ppc970.osdl.org","subject":"Re: Git-commits mailing list feed.","fromName":"Jan Harkes","fromEmail":"jaharkes@cs.cmu.edu","sentAt":"2005-04-23T18:46:13Z","receivedAt":"2005-04-23T18:46:13Z","isPatch":false,"sender":{"key":"jaharkes@cs.cmu.edu","avatar":"https://gravatar.com/avatar/cf95aecd150ca8ef33d6edc337ac4bb9e13aa4246fc3679257d578c7fddc1633?d=mp&s=160"},"body":"On Sat, Apr 23, 2005 at 11:30:36AM -0700, Linus Torvalds wrote:\n> On Sat, 23 Apr 2005, Thomas Glanzmann wrote:\n> > # This creates the signature.\n> > gpg --clearsign < sign_this > signature\n> \n> This really doesn't work for me - I do not want to have the gpg header\n> above it, only the signature below. Since I want git to actually\n> understand the tags, but do _not_ want git to have to know about whatever\n> signing method was used, I really want the resulting file to look like\n> \n> \tcommit ....\n> \ttag ...\n> \n> \there goes comment\n> \there goes signature\n> \n> and no headers.\n> \n> Whether that can be faked by always forcing SHA1 as the hash, and then \n> just removing the top lines, and re-inserting them when verifying, or \n> whether there is some mode to make gpg not do the header crud at all, I \n> don't know. Which is exactly why I never even got started.\n\nIt is a bit more messy, but it can be done with a detached signature.\n\nTo sign,\n    gpg -ab unsigned_commit\n    cat unsigned_commit unsigned_commit.asc > signed_commit\n\nTo verify,\n    cat signed_commit | sed '/-----BEGIN PGP/Q' | gpg --verify signed_commit -\n\nJan\n"},{"id":"1391","messageId":"7voec52uk0.fsf@assigned-by-dhcp.cox.net","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504231125330.2344@ppc970.osdl.org","subject":"Re: Git-commits mailing list feed.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-04-23T18:54:07Z","receivedAt":"2005-04-23T18:54:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds <torvalds@osdl.org> writes:\n\nLT> I really want the resulting file to look like\n\nLT> \tcommit ....\nLT> \ttag ...\n\nLT> \there goes comment\nLT> \there goes signature\n\nLT> and no headers.\n\nYou can use --detach-sign with --armor, like this.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n#!/bin/sh\n\nsq=s/\\'/\\''\\\\'\\'\\'/g\nusage=\"usage: $0  [--signer=...] commit-id tag < message\"\nwhile case \"$#\" in 0) break;; esac\ndo\n case \"$1\" in\n -s=*|--s=*|--si=*|--sig=*|--sign=*|--signe=*|--signer=*)\n  signer=`expr \"$1\" : '-[^=]*=\\(.*\\)'` ;;\n -s|--s|--si|--sig|--sign|--signe|--signer)\n  case \"$#\" in 0 | 1) echo \"$usage\"; exit 1 ;; esac\n  signer=\"${2?}\"\n  shift ;;\n --)\n  shift\n  break ;;\n -*)\n  echo \"$usage\"\n  exit 1 ;;\n *)\n  break ;;\n esac\n shift\ndone\n\ncase \"$#\" in 2) echo >&2 \"$usage\"; exit 1 ;; esac\ncommit=\"$1\" tag=\"$2\"\n\ncase \"$signer\" in\n'') signer_arg='' ;;\n?*) signer_arg=\"--local-user '$(echo \"$signer\" | sed -e \"$sq\")'\" ;;\nesac\n\ntmp=.jit-tag.$$\ntrap 'rm -f $tmp-*' 0 1 2 3 15\ntagblob=$tmp-tagblob\ntagsign=$tmp-tagsign\n\ncase $(cat-file -t \"$commit\" 2>/dev/null) in\ncommit) ;;\n*) echo >&2 \"$0: $commit is not a commit object\"; exit 1 ;;\nesac\n{\n    echo \"commit $commit\"\n    echo \"tag $tag\"\n    case \"$signer\" in\n    '') ;;\n    ?*) echo \"signer $signer\" ;;\n    esac\n    echo\n    tty -s && echo >&2 \"Type your tag message and end with ^D.\"\n    cat\n} >$tagblob || exit\ngpgcmd=\"gpg $signer_arg -a --output $tagsign --detach-sign $tagblob\"\neval \"$gpgcmd\" || exit\ncat $tagblob $tagsign\n"},{"id":"1393","messageId":"20050423190257.GA4194@cip.informatik.uni-erlangen.de","threadId":"194","inReplyTo":"2646.10.10.10.24.1114278656.squirrel@linux1","subject":"Re: Git-commits mailing list feed.","fromName":"Thomas Glanzmann","fromEmail":"sithglan@stud.uni-erlangen.de","sentAt":"2005-04-23T19:02:57Z","receivedAt":"2005-04-23T19:02:57Z","isPatch":false,"sender":{"key":"sithglan@stud.uni-erlangen.de","avatar":null},"body":"Hello,\n\n> Why not leave tags open to being signed or unsigned?\n\nI think that this is the idea anyway.\n\n> For presentation in the log or whatever, the script can look inside the\n> clear text message, grab the SHA1 and display it in the header area; even\n> though it's not really in the header, always just in the clear text area.\n\nHaving the SHA1 signature twice in would be confusing and error-prone\nwhen checking is done automated.\n\nSo establishing the infrastructure is a good thing. To use it for every\ncommit is another issue.\n\n\tThomas\n"},{"id":"1397","messageId":"Pine.LNX.4.58.0504231228480.2344@ppc970.osdl.org","threadId":"194","inReplyTo":"20050423183406.GD20410@delft.aura.cs.cmu.edu","subject":"Re: Git-commits mailing list feed.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-23T19:30:38Z","receivedAt":"2005-04-23T19:30:38Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 23 Apr 2005, Jan Harkes wrote:\n> \n> Why not keep the tags object outside of the tree in the tags/ directory.\n\nBecause then you have all those special cases with fetching them and with \nfsck, and with shared object directories. In other words: no. \n\nYou can have symlinks (or even better, just a single file with all the\ntags listed, which you can create with \"fsck\", for example) from the tags/\ndirectory, but the thing is, objects go in the object directory and\nnowhere else.\n\n\t\t\tLinus\n"},{"id":"1396","messageId":"426AA262.3050501@dwheeler.com","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504231010580.2344@ppc970.osdl.org","subject":"Suggestion: generalize signed tags into \"assertion objects\"","fromName":"David A. Wheeler","fromEmail":"dwheeler@dwheeler.com","sentAt":"2005-04-23T19:30:42Z","receivedAt":"2005-04-23T19:30:42Z","isPatch":false,"sender":{"key":"dwheeler@dwheeler.com","avatar":"https://avatars.githubusercontent.com/u/813150?v=4"},"body":"Linus Torvalds wrote:\n> The git-pasky \"just remember the tag name\" approach certainly works, but I \n> was literally thinking o fsetting up some signing system, so that a tag \n> doesn't just say \"commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 is \n> v2.6.12-rc2\", but it would actually give stronger guarantees, ie it would \n> say \"Linus says that commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 is \n> his 2.6.12-rc2 release\".\n> \n> That's something fundamentally more powerful, and it's also something that \n> I actually can integrate better into git.\n> \n> In other words, I actually want to create \"tag objects\", the same way we \n> have \"commit objects\". A tag object points to a commit object, but in \n> addition it contains the tag name _and_ the digital signature of whoever \n> created the tag.\n\nI'm thinking out loud here, but maybe instead of just \"tag objects\",\nhow about broadening them into \"assertion objects\" that include\n(1) a claim and (2) a signature.  Monotone, for example,\ncan do this -- it has a generalized mechanism for signed assertions.\n\nA claim might be that some commit is a tag\n(\"Linus Torvalds says this is tag 2.6.12-rc2\") or even \"I did this\"\n(\"Greg KH really committed this\").  You could create the latter objects\nwhen you push (just sign the head commit), and that would make it\nreally easy to do checks across an entire repository (who said what?).\nCurrently people can send signed emails that they really DID\ncommit something, but then that data's not available to everyone else.\nSigned assertions about commits would suddenly make it possible for\narbitrary people to detect & counter subverted repositories (if they\nhave the public key list); fsck-cache could check signatures as it went.\n\nWith a more generalized assertion mechanism,\nyou could make the same assertion multiple times, e.g., if\nyour key gets captured, you could go back and re-sign with a new key,\nsimply creating a new assertion object.  You can also make\nassertions about multiple objects (e.g., assert some relationship\nbetween far-removed commits).  I'd expect assertion\nobjects to be stored by their hash, just like any other object.\n\n> Then you just distribute these tag objects along with all the other\n> objects, and fsck-cache can pick them up even without any other knowledge,\n> but normally you'd actually point to them some other way too, ie you could \n> have the \".git/tags/xxx\" files have the pointers, but now they are \n> _validated_ pointers.\n\nYes, that makes sense.  I think .git/tags/xxx should point to\nthe assertion objects that claim they are tags; you can then check\nif you accept the assertion object's signature when you try to use it\n(and locally cache that acceptance once you've checked the signature).\n\nFor generalized assertion objects, you need a way to travel FROM\nthe object(s) being described TO the assertion object.\nA simple method might be to create subdirectories with the name\nderived from the object(s) being described, and inside the\nsubdirectory have a set of files that have the hashes of\nthe assertion objects. E.G., this kind of structure\n\n  00/\n    10f32aca7ba78e2cd95dcfedee0e6329edb735      (commit object)\n    10f32aca7ba78e2cd95dcfedee0e6329edb735.d/\n      1038e8b8e04b287ec876594cbab9df4af09ce131 ->\n                        ../../1038e8b8e04b287ec876594cbab9df4af09ce131\n  10/\n    38e8b8e04b287ec876594cbab9df4af09ce131     (assertion object)\n\n\nThere's no reason you can't point to assertions from\nmultiple places, which would make them cheap to find when needed.\n\nOne problem with symlinks is that some dopey filesystems\ndon't support them :-(.  In this case, though, if they got copied\nmultiple times they'd just waste space & not interfere\nwith meaning, since they'd all be static read-only.\nAn alternative would be 0-length files whose names are the hashes.\n\n...\n>  Somehting like\n> \n> \tcommit a2755a80f40e5794ddc20e00f781af9d6320fafb\n> \ttag v2.6.12-rc3\n> \tsigner Linus Torvalds\n> \n> \tThis is my official original 2.6.12-rc2 release\n> \n> \t-----BEGIN PGP SIGNATURE-----\n> \t....\n> \t-----END PGP SIGNATURE-----\n\n--- David A. Wheeler\n"},{"id":"1398","messageId":"Pine.LNX.4.58.0504231232260.2344@ppc970.osdl.org","threadId":"194","inReplyTo":"2646.10.10.10.24.1114278656.squirrel@linux1","subject":"Re: Git-commits mailing list feed.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-23T19:34:14Z","receivedAt":"2005-04-23T19:34:14Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 23 Apr 2005, Sean wrote:\n> \n> Why not leave tags open to being signed or unsigned?\n\nThat is exactly what my proposal does, except I'd make the normal tags \ncreation always sign.\n\nBut since _git_ won't care which is why I want the signature at the _end_, \nnot \"surrpunding\" the thing, you could create a tag that just doesn't have \nthe signature, and git will never even notice. The people who see the tag \nmay say \"hmm, why couldn't he be bothered to sign it\", though.\n\n\t\tLinus\n\n"},{"id":"1399","messageId":"Pine.LNX.4.58.0504231234550.2344@ppc970.osdl.org","threadId":"194","inReplyTo":"2911.10.10.10.24.1114279589.squirrel@linux1","subject":"Re: Git-commits mailing list feed.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-23T19:38:23Z","receivedAt":"2005-04-23T19:38:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 23 Apr 2005, Sean wrote:\n> \n> A script that knows how to validate signed tags, can easly strip off all\n> the signing overhead for display.   Users of scripts that don't understand\n> will see the cruft, but at least it will still be usable.\n\nNO.\n\nGuys, I will say this once more: git will not look at the signature.\n\nThat means that we don't \"strip them off\", because dammit, they DO NOT \nEXIST as far as git is concerned. This is why a tag-file will _always_ \nstart with \n\n\tcommit <commit-sha1>\n\ttag <tag-name>\n\nbecause that way we can use fsck and validate reachability and have things \nthat want trees (or commits) take tag-files instead, and git will \nautomatically look up the associated tree/commit. And it will do so \n_without_ having to understand about signing, since signing is for trust \nbetween _people_ not for git.\n\nAnd that is why I from the very beginning tried to make ti very clear that\nthe signature goes at the end. Not at the beginning, not in the middle,\nand not in a different file. IT GOES AT THE END.\n\n\t\tLinus\n"},{"id":"1402","messageId":"7vis2d2rmv.fsf@assigned-by-dhcp.cox.net","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504231234550.2344@ppc970.osdl.org","subject":"Re: Git-commits mailing list feed.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-04-23T19:57:12Z","receivedAt":"2005-04-23T19:57:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds <torvalds@osdl.org> writes:\n\nLT> Guys, I will say this once more: git will not look at the signature.\n\nLT> And that is why I from the very beginning tried to make ti very clear that\nLT> the signature goes at the end. Not at the beginning, not in the middle,\nLT> and not in a different file. IT GOES AT THE END.\n\nIf that is the case, can't you do it without introducing this\nnew tag object, like this?\n\n  1. Find existing commit-id that you want to tag.\n  2. Sign that commit object:\n\n     cat-file commit $commit |\n     gpg --detach-sign --armor -u 'Linus Torvalds' >commit.sig\n\n  3. Make another commit, making the original commit as its parent:\n\n     {\n         echo tag This is my tag.\n         cat commit.sig \n     } | commit-tree $(cat-file commit $commit |\n                       sed -e 's/tree //;d') -p $commit\n\nThen you can publish the ID of this commit object, which attests\nthat the original commit is what you vouch for.  Am I missing\nsomething?\n\n"},{"id":"1401","messageId":"Pine.LNX.4.58.0504231252450.2344@ppc970.osdl.org","threadId":"194","inReplyTo":"1907.10.10.10.24.1114281858.squirrel@linux1","subject":"Re: Git-commits mailing list feed.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-23T19:58:50Z","receivedAt":"2005-04-23T19:58:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 23 Apr 2005, Sean wrote:\n> \n> Okay now you're just being difficult <g>   You're acting like it's\n> impossible for git to grab the SHA1 out of the clear text message if there\n> is signing overhead above the tag reference.   That is nonesense.\n\nNo. It's not \"impossible\" for git to parse crap. But git won't.\n\nThere are two ways you can write programs:\n - reliably\n - unreliably\n\nand I do the first one. That means that a program I write does something \n_repeatable_. It does the same thing, regardless of whether a human \nhappened to write \"REF:\" in the comment section, or anything else.\n\nThe thing is, great programs come not out of great coding, but out of \ngreat data structures. The whole git philosophy bases itself on getting \nthe data structure right. \n\nAnd what you are asking for is doing it _wrong_. So in git I don't just\nparse random free-form text and guess that a line that starts with REF: is\na reference to a commit. It has very rigid and well-specified data \nstructures, and that's how you make reliable programs.\n\nI don't care what anybody else does on top of git, but dammit, I'll make \nsure that the core infrastructure is designed the right way. \n\nAnd that means that we don't guess, and that we don't parse random ASCII\nblobs. It means that we have very very fixed formats so that programs can\neither do the right thing or unambiguously say \"that's crap\".\n\nI've said it before, and I'll say it again: we have enough crap that calls \nitself SCM's out there already. I want git to be reliable and _simple_, \nnot a collection of crap that just happens to work.\n\n\t\tLinus\n"},{"id":"1404","messageId":"Pine.LNX.4.58.0504231300140.2344@ppc970.osdl.org","threadId":"194","inReplyTo":"20050423184613.GE20410@delft.aura.cs.cmu.edu","subject":"Re: Git-commits mailing list feed.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-23T20:01:59Z","receivedAt":"2005-04-23T20:01:59Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 23 Apr 2005, Jan Harkes wrote:\n> \n> It is a bit more messy, but it can be done with a detached signature.\n\nOk, this looks more like it.\n\nExcept:\n\n> To sign,\n>     gpg -ab unsigned_commit\n>     cat unsigned_commit unsigned_commit.asc > signed_commit\n> \n> To verify,\n>     cat signed_commit | sed '/-----BEGIN PGP/Q' | gpg --verify signed_commit -\n\nExcept I think you'd need to searc for the \"---BEGIN PGP\" starting from\nthe end, rather than the beginning.\n\nAnyway, that should be workable. I'll whip something up.\n\n\t\tLinus\n"},{"id":"1408","messageId":"426AACD1.2090608@pobox.com","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504231010580.2344@ppc970.osdl.org","subject":"Re: Git-commits mailing list feed.","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-04-23T20:15:13Z","receivedAt":"2005-04-23T20:15:13Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Linus Torvalds wrote:\n> That was my plan, at least. But I haven't set up any signature generation\n> thing, and this really isn't my area of expertise any more. But my _plan_ \n> literally was to have the tag object look a lot like a commit object, but \n> instead of pointing to the tree and the commit parents, it would point to \n> the commit you are tagging. Somehting like\n> \n> \tcommit a2755a80f40e5794ddc20e00f781af9d6320fafb\n> \ttag v2.6.12-rc3\n> \tsigner Linus Torvalds\n> \n> \tThis is my official original 2.6.12-rc2 release\n> \n> \t-----BEGIN PGP SIGNATURE-----\n> \t....\n> \t-----END PGP SIGNATURE-----\n\n> with a few fixed headers and then a place for free-form commentary, \n\ngroovy\n\n\n\n> If somebody writes a script to generate the above kind of thing (and tells \n> me how to validate it), I'll do the rest, and start tagging things \n> properly. Oh, and make sure the above sounds sane (ie if somebody has a \n> better idea for how to more easily identify how to find the public key to \n> check against, please speak up).\n\n[tangent]\n\nAny chance you'll have a tree tagged with older releases?\nIs someone with access to BK working on that?\n\nI do a lot of patch merges where someone sends me a 2.6.10 patch. \nPresuming the fix is still valid, I'll clone to 2.6.10, merge the patch, \npull 2.6.latest into the 2.6.10-based repo, then push the whole she-bang \ninto one of my for-upstream repos.\n\n\tJeff\n\n\n"},{"id":"1410","messageId":"Pine.LNX.4.58.0504231318510.2344@ppc970.osdl.org","threadId":"194","inReplyTo":"7vis2d2rmv.fsf@assigned-by-dhcp.cox.net","subject":"Re: Git-commits mailing list feed.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-23T20:23:18Z","receivedAt":"2005-04-23T20:23:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 23 Apr 2005, Junio C Hamano wrote:\n> \n> If that is the case, can't you do it without introducing this\n> new tag object, like this?\n\nNo, because I also want to sign the _name_ I gave it.\n\nOtherwise somebody can take my \"signed commit\", and claim that I called it \nsomething else.\n\nJust signing the commit is indeed sufficient to just say \"I trust this\ncommit\". But I essentially what to also say what I trust it _for_ as well.\n\nAnd sure, I could make a totally bogus \"commit\" object that just points to \nthe original commit, uses the same \"tree\" from that original commit, and \nwrite what I want to trust into that commit. I then sign that, and create \nyet _another_ commit that has the signature (and the pointer to the just \nsigned commit) in its commit message, and then I point to _that_ commit.\n\nSo yes, we can certainly do this with playing games with commits. That \nsounds singularly ugly, though, since just doing a \"tag\" object is a lot \nmore straightforward, and really tells the world what's going on (and \nmakes it easy for automated tools to just browse the object database and \nsee \"that's a tag\").\n\n\t\t\tLinus\n"},{"id":"1411","messageId":"7vbr852qco.fsf@assigned-by-dhcp.cox.net","threadId":"194","inReplyTo":"7vis2d2rmv.fsf@assigned-by-dhcp.cox.net","subject":"Re: Git-commits mailing list feed.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-04-23T20:24:55Z","receivedAt":"2005-04-23T20:24:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"JCH\" == I said:\n\nJCH> If that is the case, can't you do it without introducing this\nJCH> new tag object, like this?\n\nOf course It Would Not Work.  I am an idiot X-<.  Sorry.  What I\nsuggested does not authenticate the tag itself.\n\n"},{"id":"1415","messageId":"20050423204957.GA16751@delft.aura.cs.cmu.edu","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504231228480.2344@ppc970.osdl.org","subject":"Re: Git-commits mailing list feed.","fromName":"Jan Harkes","fromEmail":"jaharkes@cs.cmu.edu","sentAt":"2005-04-23T20:49:57Z","receivedAt":"2005-04-23T20:49:57Z","isPatch":false,"sender":{"key":"jaharkes@cs.cmu.edu","avatar":"https://gravatar.com/avatar/cf95aecd150ca8ef33d6edc337ac4bb9e13aa4246fc3679257d578c7fddc1633?d=mp&s=160"},"body":"On Sat, Apr 23, 2005 at 12:30:38PM -0700, Linus Torvalds wrote:\n> On Sat, 23 Apr 2005, Jan Harkes wrote:\n> > \n> > Why not keep the tags object outside of the tree in the tags/ directory.\n> \n> Because then you have all those special cases with fetching them and with \n> fsck, and with shared object directories. In other words: no. \n\nI respectfully disagree,\n\nrsync works fine for now, but people are already looking at implementing\nsmarter (more efficient) ways to synchronize git repositories by\ngrabbing missing commits, and from there fetching any missing tree and\nfile blobs. However there is no such linkage to discover missing tag\nobjects, only a full rsync would be able to get them and for that it has\nto send the name of every object in the repository to the other side to\ncheck for any missing ones.\n\nSo fetching tags is already going to be a special case.\n\nAnd any form of validation of a tag is a special operation. In fact tags\ncould be as simple as a the sha of an (like pasky's tags) followed by\nthe detached pgp signature of the tagged object instead of trying to\nsigning the tag itself. That also avoids having to strip the signature\npart from the tag when we want to validate it.\n\nJan\n"},{"id":"1418","messageId":"426ABE1B.7000905@timesys.com","threadId":"194","inReplyTo":"20050423204957.GA16751@delft.aura.cs.cmu.edu","subject":"Git transfer protocols (was: Re: Git-commits mailing list feed)","fromName":"Mike Taht","fromEmail":"mike.taht@timesys.com","sentAt":"2005-04-23T21:28:59Z","receivedAt":"2005-04-23T21:28:59Z","isPatch":false,"sender":{"key":"mike.taht@timesys.com","avatar":null},"body":"Jan Harkes wrote:\n\n> rsync works fine for now, but people are already looking at implementing\n> smarter (more efficient) ways to synchronize git repositories by\n> grabbing missing commits, and from there fetching any missing tree and\n> file blobs. However there is no such linkage to discover missing tag\n> objects, only a full rsync would be able to get them and for that it has\n> to send the name of every object in the repository to the other side to\n> check for any missing ones.\n\nI think that one reason why rsync is inefficient for git is that it \nappears to need an acknowledgement after every file. (at least, that's \nwhat what the rhythm of the packets looked like when I sniffed it \nearlier, I don't know anything else about it) For a series of very small \nfiles this interacts badly with tcp's flow control mechanisms. Perhaps \nrsync could be modified for a \"sliding file acknowledgement window\".\n\nMost \"swarming protocols\" (e.g BitTorrent, eDonkey) work well for one \nbig file shared among multiple hosts, but poorly for lots of small files.\n\n*Nothing* out there matches the simplicity of git's sha1 filename \nlength... but\n\nSomething like robcast or fcast/flute might be of interest:\n\nhttp://www.inrialpes.fr/planete/people/roca/mcl/mcl_in_short.html\n\nOr one of the multicast netnews experiments:\n\n\"mcntp\" http://mcntp.sourceforge.net/\n\"newscaster\" http://www.dmn.tzi.org/en/newscaster.html\n\nlastly, Monotone has it's own \"netsync\" protocol\n(via http://www.venge.net/monotone/faq.html)\n\n\"[netsync] is a bi-directional pipelined protocol for synchronizing \ncollections using a tree of hashed indices. It allows any copy of \nmonotone to function as either a client or a server, and rapidly \nsynchronize or half-synchronize (push / pull) their database with \nanother user. It is somewhat similar in flavor to rsync or Unison, in \nthat it quickly and idempotently synchronizes information across the \nnetwork without needing to store any local state; however, it is much \nmore efficient than these protocols.\"\n\n\n\n-- \n\nMike Taht\n\n\n"},{"id":"1421","messageId":"20050423222226.GB16751@delft.aura.cs.cmu.edu","threadId":"194","inReplyTo":"426ABE1B.7000905@timesys.com","subject":"Re: Git transfer protocols (was: Re: Git-commits mailing list feed)","fromName":"Jan Harkes","fromEmail":"jaharkes@cs.cmu.edu","sentAt":"2005-04-23T22:22:33Z","receivedAt":"2005-04-23T22:22:33Z","isPatch":false,"sender":{"key":"jaharkes@cs.cmu.edu","avatar":"https://gravatar.com/avatar/cf95aecd150ca8ef33d6edc337ac4bb9e13aa4246fc3679257d578c7fddc1633?d=mp&s=160"},"body":"On Sat, Apr 23, 2005 at 02:28:59PM -0700, Mike Taht wrote:\n> Jan Harkes wrote:\n> \n> >rsync works fine for now, but people are already looking at implementing\n> >smarter (more efficient) ways to synchronize git repositories by\n> >grabbing missing commits, and from there fetching any missing tree and\n> >file blobs. However there is no such linkage to discover missing tag\n> >objects, only a full rsync would be able to get them and for that it has\n> >to send the name of every object in the repository to the other side to\n> >check for any missing ones.\n\nActually I just realized that I personally probably wouldn't care about\nmost of the tags that people might add to their trees. Maybe once in a\nwhile, but the tag would probably be obtained through email or the web.\n\n> I think that one reason why rsync is inefficient for git is that it \n...\n> lastly, Monotone has it's own \"netsync\" protocol\n> (via http://www.venge.net/monotone/faq.html)\n\nInteresting, probably something like any of these might end up useful to\nreplace rsync for mirroring full git repositories.\n\nI'm actually more selfish than that and am thinking on how I expect to\nuse git.\n\nSee, I don't care about most of the objects in the repository. In\npractice I would probably pull only the latest 'head' once in a while\nlook for missing commits to give me a quick overview of what has\nchanged. Then if a diff between the new head and my current tree shows\nthat anything might have changed in an area I actually do care about,\nsuch as the VFS, I'd want something that does a quick binary search to\nidentify the commits where the changes occured. But for that I only\nneed to look at a limited number of tree objects.\n\nAs long as I know that someone, somewhere is archiving the whole\nrepository I can always come back later and fill in the blanks.\n\nHTTP/1.1 with persistent connections and some request interleaving is\nprobably the fastest and most server friendly way to grab those objects\nI really care about.\n\nJan\n\n"},{"id":"1429","messageId":"Pine.LNX.4.58.0504231602010.28584@sam.ics.uci.edu","threadId":"194","inReplyTo":"200504231950.43903.FabianFranz@gmx.de","subject":"Re: Git-commits mailing list feed.","fromName":"Andreas Gal","fromEmail":"gal@uci.edu","sentAt":"2005-04-23T23:16:49Z","receivedAt":"2005-04-23T23:16:49Z","isPatch":false,"sender":{"key":"gal@uci.edu","avatar":null},"body":"\nI would prefer a generic mechanism to sign _any_ object, not just tag \nobjects:\n\n- Introduce \"signature objects\" that contains an implementation-specific \n  signature. git doesn't care about the content, as long some script can \n  verify that the signature in the signature object matches the content of \n  the object(s) it references. The \"name\" of a signature object is the \n  SHA1 hash of the content (=gpg signature, for example).\n\n- Referencing signatures in tags makes no sense IMO, because it would \n  require to change the (hash) name of tags when someone else wants to \n  co-sign it later on. I would just distribute two names for that (here is \n  tag xxxxx and its signature is yyyyy). Tags should only contain a\n  symbolic name and the hash of the commit object they point to.\n\n- A nice benefit of this is that we could sign unnamed commits (think \n  automatic signing of intermediate commit), or even sign individual\n  files in the tree.\n\nJust my 2c.\n\nAndreas\n\nOn Sat, 23 Apr 2005, Fabian Franz wrote:\n\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA1\n> \n> Am Samstag, 23. April 2005 19:31 schrieb Linus Torvalds:\n> > On Sun, 24 Apr 2005, David Woodhouse wrote:\n> > > Nah, asking Linus to tag his releases is the most comfortable way.\n> > >\n> > The reason I've not done tags yet is that I haven't decided how to do\n> > them.\n> >\n> > \tcommit a2755a80f40e5794ddc20e00f781af9d6320fafb\n> > \ttag v2.6.12-rc3\n> > \tsigner Linus Torvalds\n> >\n> > \tThis is my official original 2.6.12-rc2 release\n> >\n> > \t-----BEGIN PGP SIGNATURE-----\n> > \t....\n> > \t-----END PGP SIGNATURE-----\n> >\n> > If somebody writes a script to generate the above kind of thing (and tells\n> > me how to validate it), I'll do the rest, and start tagging things\n> > properly. Oh, and make sure the above sounds sane (ie if somebody has a\n> > better idea for how to more easily identify how to find the public key to\n> > check against, please speak up).\n> \n> To generate those you do:\n> \n> # cat unsigned_tag\n> \n> \tcommit a2755a80f40e5794ddc20e00f781af9d6320fafb\n> \ttag v2.6.12-rc3\n> \tsigner Linus Torvalds\n> \tThis is my official original 2.6.12-rc2 release\n> \n> # gpg --clearsign < unsigned_tag > signed_tag # gpg will ask here for the \n> secret key phrase\n> \n> To verify you do:\n> \n> # gpg --verify < signed_tag\n> \n> and check exit status.\n> \n> Hope that helps,\n> \n> cu\n> \n> Fabian \n> -----BEGIN PGP SIGNATURE-----\n> Version: GnuPG v1.2.4 (GNU/Linux)\n> \n> iD8DBQFCaorzI0lSH7CXz7MRAr3QAJ45f2CQTgJ0sYfF9kRyrWHbsazVQQCeMqW7\n> HCsah/llt/I8sQ36dlDnRWg=\n> =Fgq1\n> -----END PGP SIGNATURE-----\n> \n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> \n"},{"id":"1432","messageId":"Pine.LNX.4.58.0504231625470.2344@ppc970.osdl.org","threadId":"194","inReplyTo":"20050423204957.GA16751@delft.aura.cs.cmu.edu","subject":"Re: Git-commits mailing list feed.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-23T23:29:56Z","receivedAt":"2005-04-23T23:29:56Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 23 Apr 2005, Jan Harkes wrote:\n> \n> I respectfully disagree,\n> \n> rsync works fine for now, but people are already looking at implementing\n> smarter (more efficient) ways to synchronize git repositories by\n> grabbing missing commits, and from there fetching any missing tree and\n> file blobs.\n\nBit this is a _feature_.\n\nOther people normally shouldn't be interested in your tags. I think it's a \nmistake to make everybody care.\n\nSo you normally would fetch only tags you _know_ about. For example, one \nof the reasons we've been _avoiding_ personal tags in teh BK trees is that \nit just gets really ugly really quickly because they get percolated up to \neverybody else. That means that in a BK tree, you can't sanely use tags \nfor \"private\" stuff, like telling somebody else \"please sync with this \ntag\".\n\nSo having the tag in the object database means that fsck etc will notice \nthese things, and can build up a list of tags you know about. It also \nmeans that you can have tag-aware synchronization tools, ie exactly the \nkind of tools that only grab missing commits can also then be used to \nselect missing tags according to some _private_ understanding of what tags \nyou might want to find..\n\n\t\tLinus\n"},{"id":"1561","messageId":"Pine.LNX.4.62.0504250008370.14200@sheen.jakma.org","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504231234550.2344@ppc970.osdl.org","subject":"Re: Git-commits mailing list feed.","fromName":"Paul Jakma","fromEmail":"paul@clubi.ie","sentAt":"2005-04-24T23:25:59Z","receivedAt":"2005-04-24T23:25:59Z","isPatch":false,"sender":{"key":"paul@clubi.ie","avatar":null},"body":"On Sat, 23 Apr 2005, Linus Torvalds wrote:\n\n> NO.\n>\n> Guys, I will say this once more: git will not look at the signature.\n>\n> That means that we don't \"strip them off\", because dammit, they DO NOT\n> EXIST as far as git is concerned. This is why a tag-file will _always_\n> start with\n>\n> \tcommit <commit-sha1>\n> \ttag <tag-name>\n>\n> because that way we can use fsck and validate reachability and have \n> things that want trees (or commits) take tag-files instead, and git \n> will automatically look up the associated tree/commit. And it will \n> do so _without_ having to understand about signing, since signing \n> is for trust between _people_ not for git.\n\n> And that is why I from the very beginning tried to make ti very \n> clear that the signature goes at the end. Not at the beginning, not \n> in the middle, and not in a different file. IT GOES AT THE END.\n\nActually, can you make the signature be detached and a seperate \nobject? Ie, add a signature object in its own right, distinct from \ntag. They could then:\n\n- be used to sign any kind of object\n- allow objects to be signed by multiple people\n\nIdeally, there'd be an index of signature objects by the SHA-1 sum of \nthe object they sign, as the signed object should not refer to the \nsignature (or the second of the above is not possible).\n\nThe latter of the two points would, in combination with the former, \nallow for cryptographic 'signed-off-by' chains. If a 'commit' is \nsigned by $RANDOM_CONTRIBUTOR and $SUBSYSTEM_MAINTAINER and $ANDREW, \nyou know its time to pull it. Would also work for things like \"fixes \nonly\" trees, where (say) a change must be approved by X/2+1 of a \ngroup of X hacker providing oversight -> looking up the commit \nobject's signatures would tell you whether it was approved.\n\nNo idea whether this is possible or practical. :) But it would be \ngood for future flexibility to avoid including the signature in the \nobject being signed.\n\nregards,\n-- \nPaul Jakma\tpaul@clubi.ie\tpaul@jakma.org\tKey ID: 64A2FF6A\nFortune:\nYou give me space to belong to myself yet without separating me \nfrom your own life.  May it all turn out to your happiness.\n \t\t-- Goethe\n"},{"id":"1562","messageId":"Pine.LNX.4.62.0504250053560.14200@sheen.jakma.org","threadId":"194","inReplyTo":"Pine.LNX.4.62.0504250008370.14200@sheen.jakma.org","subject":"Re: Git-commits mailing list feed.","fromName":"Paul Jakma","fromEmail":"paul@clubi.ie","sentAt":"2005-04-24T23:57:11Z","receivedAt":"2005-04-24T23:57:11Z","isPatch":false,"sender":{"key":"paul@clubi.ie","avatar":null},"body":"On Mon, 25 Apr 2005, Paul Jakma wrote:\n\n> Ideally, there'd be an index of signature objects by the SHA-1 sum of the \n> object they sign, as the signed object should not refer to the signature (or \n> the second of the above is not possible).\n\nAh, this could (obviously) be done generally by providing a general \nindex of 'referals' (if desirable).\n\nI have no idea whether git already does this, I havn't checked it out \nyet but I'm very interested to see how git will mature and have been \ntrying to follow its progress - I'm a frustrated admin of a CVS \nrepository..\n\nregards,\n-- \nPaul Jakma\tpaul@clubi.ie\tpaul@jakma.org\tKey ID: 64A2FF6A\nFortune:\nDoes the name Pavlov ring a bell?\n"},{"id":"1568","messageId":"426C4168.6030008@dwheeler.com","threadId":"194","inReplyTo":"Pine.LNX.4.62.0504250008370.14200@sheen.jakma.org","subject":"Re: Git-commits mailing list feed.","fromName":"David A. Wheeler","fromEmail":"dwheeler@dwheeler.com","sentAt":"2005-04-25T01:01:28Z","receivedAt":"2005-04-25T01:01:28Z","isPatch":false,"sender":{"key":"dwheeler@dwheeler.com","avatar":"https://avatars.githubusercontent.com/u/813150?v=4"},"body":"\n\n\nOn Sat, 23 Apr 2005, Linus Torvalds wrote:\n>> That means that we don't \"strip them off\", because dammit, they DO NOT\n>> EXIST as far as git is concerned. This is why a tag-file will _always_\n>> start with\n>>\n>>     commit <commit-sha1>\n>>     tag <tag-name>\n>>\n>> because that way we can use fsck and validate reachability and have \n>> things that want trees (or commits) take tag-files instead, and git \n>> will automatically look up the associated tree/commit. And it will do \n>> so _without_ having to understand about signing, since signing is for \n>> trust between _people_ not for git.\n >\n >> And that is why I from the very beginning tried to make ti very clear\n >> that the signature goes at the end. Not at the beginning, not in the\n >> middle, and not in a different file. IT GOES AT THE END.\n\nIt may be better to have them as simple detached signatures, which are\ncompletely separate files (see gpg --detached).\nYeah, gpg currently implements detached signatures\nby repeating what gets signed, which is unfortunate,\nbut the _idea_ is the right one.\n\n\nPaul Jakma wrote:\n> Ideally, there'd be an index of signature objects by the SHA-1 sum of \n> the object they sign, as the signed object should not refer to the \n> signature (or the second of the above is not possible).\n\nYes, and see my earlier posting.  It'd be easy to store signatures in\nthe current objects directory, of course.  The trick is to be able\nto go from signed-object to the signature; this could be done\njust by creating a subdirectory using a variant of\nthe name of the signed-object's file, and in that directory store the\nhash values of the signatures.  E.G.:\n  00/\n     3b128932189018329839019          <- object to sign\n     3b128932189018329839019.d/\n     0143709289032890234323451\n  01/\n     43709289032890234323451          <- signature\n\n> The latter of the two points would, in combination with the former, \n> allow for cryptographic 'signed-off-by' chains. If a 'commit' is signed \n> by $RANDOM_CONTRIBUTOR and $SUBSYSTEM_MAINTAINER and $ANDREW, you know \n> its time to pull it. Would also work for things like \"fixes only\" trees, \n> where (say) a change must be approved by X/2+1 of a group of X hacker \n> providing oversight -> looking up the commit object's signatures would \n> tell you whether it was approved.\n\nRight.  Lots of tricks you can do once the signatures are there,\nsuch as checking to counter repository subversion\n(did everything get signed), finding out who introduced a malicious\nline of code (& \"proving\" what key signed it first), etc.\nThere are LOTS of reasons for storing signatures so that they can\nbe checked later on, just like there are lots of reasons for storing\nold code... they give you evidence that the reputed history is true\n(and if you doubt it, they give you a way to limit the doubt).\n\n--- David A. Wheeler\n"},{"id":"1572","messageId":"1114392397.3419.97.camel@localhost.localdomain","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504231010580.2344@ppc970.osdl.org","subject":"Re: Git-commits mailing list feed.","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2005-04-25T01:26:36Z","receivedAt":"2005-04-25T01:26:36Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Sat, 2005-04-23 at 10:31 -0700, Linus Torvalds wrote:\n> In other words, I actually want to create \"tag objects\", the same way we \n> have \"commit objects\". A tag object points to a commit object, but in \n> addition it contains the tag name _and_ the digital signature of whoever \n> created the tag.\n\nI'm slightly concerned that to find a given tag by its name if we do\n_just_ the above would be a fairly slow process. I suspect you'll want\na .git/tags/ directory _anyway_, but with named files which refer to tag\nobjects, instead of directly to commit objects as in Petr's current\nimplementation.\n\nOther operations we might want to be at least _reasonably_ efficient\nwould include 'show me the latest tag from Linus' and 'show me all\nextant tags'.\n\n-- \ndwmw2\n\n"},{"id":"1575","messageId":"Pine.LNX.4.62.0504250212200.14200@sheen.jakma.org","threadId":"194","inReplyTo":"426C4168.6030008@dwheeler.com","subject":"Re: Git-commits mailing list feed.","fromName":"Paul Jakma","fromEmail":"paul@clubi.ie","sentAt":"2005-04-25T01:35:45Z","receivedAt":"2005-04-25T01:35:45Z","isPatch":false,"sender":{"key":"paul@clubi.ie","avatar":null},"body":"On Sun, 24 Apr 2005, David A. Wheeler wrote:\n\n> It may be better to have them as simple detached signatures, which \n> are completely separate files (see gpg --detached). Yeah, gpg \n> currently implements detached signatures by repeating what gets \n> signed, which is unfortunate, but the _idea_ is the right one.\n\nHmm, what do you mean by \"repeating what gets signed\"?\n\n> Yes, and see my earlier posting.  It'd be easy to store signatures in\n> the current objects directory, of course.  The trick is to be able\n> to go from signed-object to the signature;\n\nTwo ways:\n\n1. An index of sigs to signed-object.\n\n(or more generally: objects to referring-objects)\n\n2. Just give people the URI of the signature, let them (or their\n    tools) follow the 'parent' link to the object of interest\n\n> this could be done just by creating a subdirectory using a variant \n> of the name of the signed-object's file, and in that directory \n> store the hash values of the signatures.  E.G.:\n\n> 00/\n>    3b128932189018329839019          <- object to sign\n>    3b128932189018329839019.d/\n>    0143709289032890234323451\n> 01/\n>    43709289032890234323451          <- signature\n\nYou could hack it in to the namespace somehow I guess. I'm not sure \nhacking it in would be a good thing though.\n\nI think it might be more useful just to provide a general index to \nlookup 'referring' objects (if git does not already - I dont think it \ndoes, but I dont know enough to know for sure). So you could ask \n\"which {commit,tag,signature,tree}(s) refer(s) to this object?\" - \nthat general concept will always work. If you wanted to make the \nimplementation of this index use some kind of sub directory as in the \nabove, fine..\n\nSee also method 2 above. Which would be more efficient for tools if, \nwithin a project, some developers sign their 'updates' and some \ndont.. (you never need to check whether there's a signature or not - \nyou'll know it from the URI automatically).\n\n> There are LOTS of reasons for storing signatures so that they can \n> be checked later on, just like there are lots of reasons for \n> storing old code... they give you evidence that the reputed history \n> is true (and if you doubt it, they give you a way to limit the \n> doubt).\n\nIndeed.\n\nAnyway, we shall see what Linus does. :)\n\n(But I do hope at least that signatures are /not/ included inline \nusing BEGIN PGP.. in the object that is signed.)\n\nregards,\n-- \nPaul Jakma\tpaul@clubi.ie\tpaul@jakma.org\tKey ID: 64A2FF6A\nFortune:\nTo err is human, to purr feline.\nTo err is human, two curs canine.\nTo err is human, to moo bovine.\n"},{"id":"1576","messageId":"Pine.LNX.4.58.0504241846290.18901@ppc970.osdl.org","threadId":"194","inReplyTo":"426C4168.6030008@dwheeler.com","subject":"Re: Git-commits mailing list feed.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-25T01:50:16Z","receivedAt":"2005-04-25T01:50:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 24 Apr 2005, David A. Wheeler wrote:\n> \n> It may be better to have them as simple detached signatures, which are\n> completely separate files (see gpg --detached).\n> Yeah, gpg currently implements detached signatures\n> by repeating what gets signed, which is unfortunate,\n> but the _idea_ is the right one.\n\nActually, if we do totally separate files, then the detached thing is ok, \nand we migth decide to not call the objects at all, since that seems to be \nunnecessarily complex.\n\nMaybe we'll just have signed tags by doing exactly that: just a collection \nof detached signature files. The question becomes one of how to name such \nthings in a distributed tree. That is the thing that using an object for \nthem would have solved very naturally.\n\n\t\tLinus\n"},{"id":"1578","messageId":"426C5266.6050200@dwheeler.com","threadId":"194","inReplyTo":"Pine.LNX.4.62.0504250212200.14200@sheen.jakma.org","subject":"Re: Git-commits mailing list feed.","fromName":"David A. Wheeler","fromEmail":"dwheeler@dwheeler.com","sentAt":"2005-04-25T02:13:58Z","receivedAt":"2005-04-25T02:13:58Z","isPatch":false,"sender":{"key":"dwheeler@dwheeler.com","avatar":"https://avatars.githubusercontent.com/u/813150?v=4"},"body":"Paul Jakma wrote:\n> On Sun, 24 Apr 2005, David A. Wheeler wrote:\n> Hmm, what do you mean by \"repeating what gets signed\"?\n\nForget it, irrelevant.  I vaguely remembered some problem with\ngpg's detached signatures, but it was probably either a really\nearly alpha version or someone was using \"--clearsign\" instead\nof \"--armor\".  I just did a quick check with:\n  gpg --armor --detach -o junk.sig junk.c\nand it worked \"as expected\"; no repeat of the data.\n\n>> Yes, and see my earlier posting.  It'd be easy to store signatures in\n>> the current objects directory, of course.  The trick is to be able\n>> to go from signed-object to the signature;\n> Two ways:\n> 1. An index of sigs to signed-object.\n> (or more generally: objects to referring-objects)\n\nRight.  I suggested putting it in the same directory as the objects,\nso that rsync users get them \"for free\", but a separate directory\nhas its own advantages & that'd be fine too.\nIn fact, the more I think about it, I think it'd be cleaner\nto have it separate.   You could prepend on top of the signature\n(if signatures are separate from assertions) WHAT got signed so\nthat the index could be recreated from scratch when desired.\n\n> 2. Just give people the URI of the signature, let them (or their\n>    tools) follow the 'parent' link to the object of interest\n\nIf you mean \"the signatures aren't stored with the objects\", NO.\nPlease don't! If the signatures are not stored in the database,\nthen over time they'll get lost.  It's important to me to\nstore the record of trust, as well as what changed, so that\nANYONE can later go back and verify that things are as they're\nsupposed to be, or exactly who trusted what.\n\n> I think it might be more useful just to provide a general index to \n> lookup 'referring' objects (if git does not already - I dont think it \n> does, but I dont know enough to know for sure).\n\ngit definitely doesn't have this currently, though you could run the\nfsck tools which end up creating a lot of the info (but it's then\nthrown away).\n\n > So you could ask \"which\n> {commit,tag,signature,tree}(s) refer(s) to this object?\" - that general \n> concept will always work.\n\nYes. The problem is that maintaining the index is a pain.\nIt's probably worth it for signatures, because the primary use\nis the other direction (\"who signed this?\"); it's not clear that\nthe other direction is common for other data.\n\n--- David A. Wheeler\n"},{"id":"1579","messageId":"200504250417.17231.FabianFranz@gmx.de","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504241846290.18901@ppc970.osdl.org","subject":"Re: Git-commits mailing list feed.","fromName":"Fabian Franz","fromEmail":"fabianfranz@gmx.de","sentAt":"2005-04-25T02:17:13Z","receivedAt":"2005-04-25T02:17:13Z","isPatch":false,"sender":{"key":"fabianfranz@gmx.de","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nAm Montag, 25. April 2005 03:50 schrieb Linus Torvalds:\n\n> Maybe we'll just have signed tags by doing exactly that: just a collection\n> of detached signature files. The question becomes one of how to name such\n> things in a distributed tree. That is the thing that using an object for\n> them would have solved very naturally.\n\nWhat about just <sha1 hash of object>.sig or <sha1 hash of object>.asc?\n\nOr would this violate the concept of the object database to just contain \nhashes?\n\ncu\n\nFabian\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.2.4 (GNU/Linux)\n\niD8DBQFCbFMsI0lSH7CXz7MRAof0AKCILjPE/M72cMSVNDC/DWYSzmrU/ACggOuS\nogNPwUf2ASAwmbwixzSTuPs=\n=pW5D\n-----END PGP SIGNATURE-----\n\n"},{"id":"1580","messageId":"20050425023420.GA14696@lists.us.dell.com","threadId":"194","inReplyTo":"426C4168.6030008@dwheeler.com","subject":"Re: Git-commits mailing list feed.","fromName":"Matt Domsch","fromEmail":"matt_domsch@dell.com","sentAt":"2005-04-25T02:34:20Z","receivedAt":"2005-04-25T02:34:20Z","isPatch":false,"sender":{"key":"matt_domsch@dell.com","avatar":null},"body":"On Sun, Apr 24, 2005 at 09:01:28PM -0400, David A. Wheeler wrote:\n> It may be better to have them as simple detached signatures, which are\n> completely separate files (see gpg --detached).\n> Yeah, gpg currently implements detached signatures\n> by repeating what gets signed, which is unfortunate,\n> but the _idea_ is the right one.\n\nI solve this with two simple scripts, \"sign\" calls \"cutsig\".\n\n--------------\nsign\n\n#!/bin/sh\n\nDEFAULT_KEY=\"my-private-key-string\"\nCUTSIG=~/bin/cutsig.pl\nusage()\n{\n    echo \"usage: $0 filename\"\n    echo \" produces filename.sign\"\n}\n\nif [ $# -lt 1 ]; then\n   usage\n   exit 1;\nfi\n\ngpg --armor --clearsign --detach-sign --default-key \"${DEFAULT_KEY} -v -v -o - ${1} | \\\n${CUTSIG} > ${1}.sign\n\nexit 0\n\n\n-----------------\ncutsig\n\n\n#!/usr/bin/perl -w\n\ndo {\n    $line = <STDIN>;\n} until $line =~ \"-----BEGIN PGP SIGNATURE-----\";\n\n\nprint $line;\nwhile ( $line = <STDIN>) {\n    print $line;\n}\n\nexit 0;\n"},{"id":"1581","messageId":"Pine.LNX.4.58.0504241930480.1394@sam.ics.uci.edu","threadId":"194","inReplyTo":"200504250417.17231.FabianFranz@gmx.de","subject":"Re: Git-commits mailing list feed.","fromName":"Andreas Gal","fromEmail":"gal@uci.edu","sentAt":"2005-04-25T02:39:45Z","receivedAt":"2005-04-25T02:39:45Z","isPatch":false,"sender":{"key":"gal@uci.edu","avatar":null},"body":"\nIt may sound a little weird, but we could actually store the signature in \nthe inode/filename. GPG signatures seem to be around 80 bytes of ASC, \nthats well below MAXPATH and should work even if your repository is \nsomewhere/deep/in/your/filesystem/hierarchy. \n\n1. Signed objects are named sha1-sig (sig is a 80 character signature \nhere, not the three letters sig).\n\n2. To make sure we can find objects without their signature, there is \n   always a soft link sha1 -> sha1-sig (fsck can check this and create \n   missing links).\n\n3. To find a signature, just follow the link and look at the real name.\n\n4. Files can be distributed without signature (content is unchanged) and\n   you can sign them in your local tree with your own signature, \n   effectively throwing my signature away.\n\nThe only limitation is that each object can only be signed by one person. \nOn the other hand, this might not be a limitation at all. If I create a \nfile, I sign it. Nobody else. Same goes for trees and commits that I \ncreate. You can sign your own commit object when you merge my stuff, and \nthen push that commit object out (along with your co-signature).\n\nAndreas\n\nOn Mon, 25 Apr 2005, Fabian Franz wrote:\n\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA1\n> \n> Am Montag, 25. April 2005 03:50 schrieb Linus Torvalds:\n> \n> > Maybe we'll just have signed tags by doing exactly that: just a collection\n> > of detached signature files. The question becomes one of how to name such\n> > things in a distributed tree. That is the thing that using an object for\n> > them would have solved very naturally.\n> \n> What about just <sha1 hash of object>.sig or <sha1 hash of object>.asc?\n> \n> Or would this violate the concept of the object database to just contain \n> hashes?\n> \n> cu\n> \n> Fabian\n> -----BEGIN PGP SIGNATURE-----\n> Version: GnuPG v1.2.4 (GNU/Linux)\n> \n> iD8DBQFCbFMsI0lSH7CXz7MRAof0AKCILjPE/M72cMSVNDC/DWYSzmrU/ACggOuS\n> ogNPwUf2ASAwmbwixzSTuPs=\n> =pW5D\n> -----END PGP SIGNATURE-----\n> \n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> \n"},{"id":"1583","messageId":"20050425024340.GI29939@delft.aura.cs.cmu.edu","threadId":"194","inReplyTo":"20050425023420.GA14696@lists.us.dell.com","subject":"Re: Git-commits mailing list feed.","fromName":"Jan Harkes","fromEmail":"jaharkes@cs.cmu.edu","sentAt":"2005-04-25T02:43:40Z","receivedAt":"2005-04-25T02:43:40Z","isPatch":false,"sender":{"key":"jaharkes@cs.cmu.edu","avatar":"https://gravatar.com/avatar/cf95aecd150ca8ef33d6edc337ac4bb9e13aa4246fc3679257d578c7fddc1633?d=mp&s=160"},"body":"On Sun, Apr 24, 2005 at 09:34:20PM -0500, Matt Domsch wrote:\n> On Sun, Apr 24, 2005 at 09:01:28PM -0400, David A. Wheeler wrote:\n> > It may be better to have them as simple detached signatures, which are\n> > completely separate files (see gpg --detached).\n> > Yeah, gpg currently implements detached signatures\n> > by repeating what gets signed, which is unfortunate,\n> > but the _idea_ is the right one.\n> \n> I solve this with two simple scripts, \"sign\" calls \"cutsig\".\n...\n> gpg --armor --clearsign --detach-sign --default-key \"${DEFAULT_KEY} -v -v -o - ${1} | \\\n> ${CUTSIG} > ${1}.sign\n\nYou could also just leave out the --clearsign option and it will DTRT.\n\nJan\n"},{"id":"1582","messageId":"Pine.LNX.4.58.0504241938410.18901@ppc970.osdl.org","threadId":"194","inReplyTo":"200504250417.17231.FabianFranz@gmx.de","subject":"Re: Git-commits mailing list feed.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-25T02:44:16Z","receivedAt":"2005-04-25T02:44:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 25 Apr 2005, Fabian Franz wrote:\n> \n> What about just <sha1 hash of object>.sig or <sha1 hash of object>.asc?\n\nWell, the SHA1 of an object really is not a very good name, unless you \nhave something to manage it with. Again, the object database has something \nto manage and find those objects with - things like .git/HEAD, but also \n\"fsck\" to find dangling and unnamed objects.\n\nMaybe we'll never have so many tags that we need to manage them, and yes,\nif so, we can just have \".git/signatures\" be a directory with objects that\nare just named for their content SHA1, the same way the object database\nis, but separately (and probably just using a flat file structure, no need\nfor the subdirectory fan-out that the object directory has).\n\nNo need for a \".sig\" thing, since they'd be defined to be signatures just \nfrom their location.\n\n> Or would this violate the concept of the object database to just contain \n> hashes?\n\nThis wouldn't be an object at all in that case, they'd be totally outside \nthe scope of the git object model.\n\nAnd yes, if they were to be git objects, they'd follow totally different\nrules: they'd have to have the \"tag+length+'\\0'\" format, and they would be \nzlib-compressed.\n\nIf they are totally outside of git, then I don't care what the object \nformat is, and then it could be just a regular text-file with a signature \nand content, and just happen to be named for the SHA1 hash so that there \nis no confusion about what happens when multiple people happen to create \ndifferent tags with the same name.\n\n\t\tLinus\n"},{"id":"1584","messageId":"Pine.LNX.4.62.0504250323040.14200@sheen.jakma.org","threadId":"194","inReplyTo":"426C5266.6050200@dwheeler.com","subject":"Re: Git-commits mailing list feed.","fromName":"Paul Jakma","fromEmail":"paul@clubi.ie","sentAt":"2005-04-25T03:03:02Z","receivedAt":"2005-04-25T03:03:02Z","isPatch":false,"sender":{"key":"paul@clubi.ie","avatar":null},"body":"On Sun, 24 Apr 2005, David A. Wheeler wrote:\n\n> Right.  I suggested putting it in the same directory as the \n> objects, so that rsync users get them \"for free\", but a separate \n> directory has its own advantages & that'd be fine too. In fact, the \n> more I think about it, I think it'd be cleaner to have it separate. \n> You could prepend on top of the signature (if signatures are \n> separate from assertions) WHAT got signed so that the index could \n> be recreated from scratch when desired.\n\nWell, i'm trying to play with git right now to see what would fit \nwith how it abstracts things.\n\nI think possibly:\n\n- add the 'signature object' to the respository after the signed\n   object\n\nSo a 'signed commit' turns into the\n\n- tool preparing the commit object,\n \t- get the user to sign it\n \t- save the detached signature for later\n- adding the commit object to the repository\n- prepare the signing object and add to repository\n\nThe repository head then refers then to signature object, which could \n(handwaving) look something like:\n\n \tObject\t\tSignature\n \tSigning \t<object ID, in this case of the commit object>\n \tSign-type \tGPG\n\n \t<signature data>\n\nTools should then treat signature objects as 'stand ins' for the \nobject they are signing (verify the signature - if desired - and then \njust retrieve the 'Signing' object ID and use that further).\n\nI have no working knowledge of git though, other than following this \nlist. So I have no idea whether above is at all appropriate or \nworkable.\n\n> If you mean \"the signatures aren't stored with the objects\", NO. \n> Please don't! If the signatures are not stored in the database, \n> then over time they'll get lost.\n\nNo more lost than anything else in the git 'fs'.\n\nIf someone prunes old objects, they'll lose the signed objects along \nwith the signatures. If those files weren't replicated anywhere else, \nwell they've just blown away history for good, both the history of \nthe source and corresponding signatures.\n\n> It's important to me to store the record of trust, as well as what \n> changed, so that ANYONE can later go back and verify that things \n> are as they're supposed to be, or exactly who trusted what.\n\nSee above.\n\n> git definitely doesn't have this currently, though you could run \n> the fsck tools which end up creating a lot of the info (but it's \n> then thrown away).\n\nWell, it could be retained then.\n\n> Yes. The problem is that maintaining the index is a pain.\n\nPossibly.\n\n> It's probably worth it for signatures, because the primary use is \n> the other direction (\"who signed this?\"); it's not clear that the \n> other direction is common for other data.\n\nIn CVS it is. If you 'cvs log' a file, you can get a report on which \nrevisions of the file belong to which tags (which can be useful \ninformation sometimes: \"ah, so that release had the buggy version\" \ntype of thing. Or as a sanity check to make sure you got a tag right \n- particularly when you have to move a wrong tag[1]). So, in addition \nto signatures, a general 'referrers of this object' index could be \nuseful for reports.\n\n1. This might be just a CVS thing, and not wanted for git -> the \nability to tag historical revisions and indeed change what tags refer \nto.\n\nregards,\n-- \nPaul Jakma\tpaul@clubi.ie\tpaul@jakma.org\tKey ID: 64A2FF6A\nFortune:\nDecaffeinated coffee?  Just Say No.\n"},{"id":"1586","messageId":"Pine.LNX.4.62.0504250405010.14200@sheen.jakma.org","threadId":"194","inReplyTo":"Pine.LNX.4.62.0504250323040.14200@sheen.jakma.org","subject":"Re: Git-commits mailing list feed.","fromName":"Paul Jakma","fromEmail":"paul@clubi.ie","sentAt":"2005-04-25T03:08:39Z","receivedAt":"2005-04-25T03:08:39Z","isPatch":false,"sender":{"key":"paul@clubi.ie","avatar":null},"body":"Ah, to add to below..\n\nIf one wished, one could optionally store the actual signature data \nas a seperate blob object and refer to it in the signing object. Not \nneeded really for a GPG ASCII clear-signed detached signature (tiny \nand they're ASCII obviously :) ), but who knows.\n\nOn Mon, 25 Apr 2005, Paul Jakma wrote:\n\n> - add the 'signature object' to the respository after the signed\n>  object\n>\n> So a 'signed commit' turns into the\n>\n> - tool preparing the commit object,\n> \t- get the user to sign it\n> \t- save the detached signature for later\n> - adding the commit object to the repository\n\n   - adding the signature blob, if it is to stored as a blob\n\n> - prepare the signing object and add to repository\n\n> The repository head then refers then to signature object, which could \n> (handwaving) look something like:\n>\n> \tObject\t\tSignature\n> \tSigning \t<object ID, in this case of the commit object>\n> \tSign-type \tGPG\n\nWith either a 'Signature  <ID of signature data blob>' or else:\n\n> \t<signature data>\n\n\nregards,\n-- \nPaul Jakma\tpaul@clubi.ie\tpaul@jakma.org\tKey ID: 64A2FF6A\nFortune:\nMay you have many beautiful and obedient daughters.\n"},{"id":"1585","messageId":"426C5F43.8010705@dwheeler.com","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504241846290.18901@ppc970.osdl.org","subject":"Re: Git-commits mailing list feed.","fromName":"David A. Wheeler","fromEmail":"dwheeler@dwheeler.com","sentAt":"2005-04-25T03:08:51Z","receivedAt":"2005-04-25T03:08:51Z","isPatch":false,"sender":{"key":"dwheeler@dwheeler.com","avatar":"https://avatars.githubusercontent.com/u/813150?v=4"},"body":"Linus Torvalds wrote:\n> \n> On Sun, 24 Apr 2005, David A. Wheeler wrote:\n> \n>>It may be better to have them as simple detached signatures, which are\n>>completely separate files (see gpg --detached).\n> \n> Actually, if we do totally separate files, then the detached thing is ok, \n> and we migth decide to not call the objects at all, since that seems to be \n> unnecessarily complex.\n> \n> Maybe we'll just have signed tags by doing exactly that: just a collection \n> of detached signature files. The question becomes one of how to name such \n> things in a distributed tree. That is the thing that using an object for \n> them would have solved very naturally.\n\nI agree, naming signatures using the same way other objects are named\nwould be very clean.  So, why not? It's perfectly reasonable to\njust store detached signatures as hashed objects, just like the rest;\njust create a new object type (\"signature\").\nIf 3 different keys are used to sign the same object, the detached\nsignatures will have different hash values, so they'll get named easily.\n\nNow you just have to FIND the signature of a signed object,\ni.e. efficiently go the \"other way\" from signed object to detached\nsignature.  A separate directory with this mapping, or embedding the\nmapping inside the object directory (HASH.d/<list>) both solve it.\n\nThe more I think about it, the more I think a separate \"reverse\"\nindex directory would be a better idea. It just needs to from\n\"me\" to \"who references me\", at least so that you can quickly\nfind all signatures of a given object. If the reverse directory\ngets wonky, anyone can just delete the reverse index directory\nat any time & reconstruct it by iterating the objects.\nBefore \"-----BEGIN PGP SIGNATURE-----\" you should add:\n  signatureof HASHVALUE\nto make reconstruction easy; PGP processors ignore stuff\nbefore \"-----\".  The PGP data does include a hash, but it's not\neasy to get it out (I don't see a way to do it in gpg from the\ncommand line), and it's quite possible that a signer won't\nuse SHA-1 when they sign something (they may not even\nrealize it; it depends on their implementation's configuration).\nBetter to include something about what was signed with the signature.\n\nHmm, probably worth backtracking to see what's needed.\nThere needs to be a way to identify tags, and a way to sign that\ntag so that you can decide to trust some tags & not others.\nThere needs to be a way to sign commits, and store that info\nfor later.  And really, these are special cases of general\nassertions about other things; you might want someone to be\nable to make other signed assertions (e.g., that it\npassed test suite XYZ).\n\nIf tags & commits are all you plan to sign for now, well, you\nalready have commits.  You can just add a \"tag\" type and a\n\"signature\" type of object (the \"signature\" is just a detached\nOpenPGP signature).  \"signature\" can sign tag or commit types.\nI still like the idea of a more general \"assertion\" type, esp.\nfor assertions that something passed a test suite on a certain date\nor was reviewed at a certain date by someone, but admittedly\nthat could be added later in the same manner.\n\nThen you need to be able to quickly find a signature, given a\ncommit or tag.  A \"reverse\" directory then does that nicely,\nand if you put enough information in front of the signature,\nyou can regenerate the reverse directory whenever you wish.\n\n--- David A. Wheeler\n"},{"id":"1588","messageId":"Pine.LNX.4.62.0504250413200.14200@sheen.jakma.org","threadId":"194","inReplyTo":"426C5F43.8010705@dwheeler.com","subject":"Re: Git-commits mailing list feed.","fromName":"Paul Jakma","fromEmail":"paul@clubi.ie","sentAt":"2005-04-25T03:24:03Z","receivedAt":"2005-04-25T03:24:03Z","isPatch":false,"sender":{"key":"paul@clubi.ie","avatar":null},"body":"On Sun, 24 Apr 2005, David A. Wheeler wrote:\n\n> Now you just have to FIND the signature of a signed object, i.e. \n> efficiently go the \"other way\" from signed object to detached \n> signature.  A separate directory with this mapping, or embedding \n> the mapping inside the object directory (HASH.d/<list>) both solve \n> it.\n\nYou dont even need it, see my other mail. If:\n\n- the signature is an object and added after the commit object\n\n- tools know that signatures are 'proxies of' or precursors to the\n   objects they are signing (which makes sense, a signature by\n   definition refers to something else)\n\n- the signature object refers to the object it is signing (eg a\n   'Signing <object ID>' header)\n\nThen head can simply be the signature object and tools can find the \ncommit by following the 'Signing' field of the signature (they dont \neven need to check the signature is valid). No index lookup needed.\n\nYou only need the index for historical verification really, and you \ncan always generate an index if needs be. (and have the tools \nmaintain it).\n\n> The more I think about it, the more I think a separate \"reverse\"\n> index directory would be a better idea. It just needs to from\n> \"me\" to \"who references me\", at least so that you can quickly\n> find all signatures of a given object. If the reverse directory\n> gets wonky, anyone can just delete the reverse index directory\n> at any time & reconstruct it by iterating the objects.\n> Before \"-----BEGIN PGP SIGNATURE-----\" you should add:\n> signatureof HASHVALUE\n> to make reconstruction easy; PGP processors ignore stuff\n> before \"-----\".\n\nOof, dont do this:\n\n- makes assumptions about the format of the signature\n \t- that it is ASCII\n \t- that you can change it\n\nJust add a git header which is independent of the signature data.\n\nIn lieu of the 'signature object as precursor' approach above, just \nhave the tools maintain an index. It can be maintained as objects as \nadded, and can always be blown away and recreated by inspection of \nthe repository data.\n\nregards,\n-- \nPaul Jakma\tpaul@clubi.ie\tpaul@jakma.org\tKey ID: 64A2FF6A\nFortune:\nTo doubt everything or to believe everything are two equally convenient\nsolutions; both dispense with the necessity of reflection.\n \t\t-- H. Poincar'\be\n"},{"id":"1589","messageId":"426C64E4.4090600@dwheeler.com","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504241938410.18901@ppc970.osdl.org","subject":"Re: Git-commits mailing list feed.","fromName":"David A. Wheeler","fromEmail":"dwheeler@dwheeler.com","sentAt":"2005-04-25T03:32:52Z","receivedAt":"2005-04-25T03:32:52Z","isPatch":false,"sender":{"key":"dwheeler@dwheeler.com","avatar":"https://avatars.githubusercontent.com/u/813150?v=4"},"body":"On Mon, 25 Apr 2005, Fabian Franz wrote:\n >> What about just <sha1 hash of object>.sig or <sha1 hash of object>.asc?\n\nIf you mean \"hash of object being signed\", the problem is that\nthere may be more than one signature of a given object.\nKeys get stolen, for example, so you want to re-sign the objects.\nYes, you could replace the files, but it's nicer to make it\nso there's never a need to replace files in the first place.\nThat's one of the nice properties of the git object database;\nso if we can have that property everywhere, I think we should.\n\nInstead, store the signatures in the normal object database, &\ngive it type \"signature\".  To speed access FROM a commit or tag\nto a signature (and FROM a commit to a tag), create a\nseparate reverse directory that tells you what objects reference\na given object.  Like this:\n.git/\n   objects/\n     00/\n       0195297c2a6336c2007548f909769e0862b509  <= a commit object\n     02/\n       0395297c2a6336c2007548f909769e0862b509  <= signature of commit\n     04/\n       0595297c2a6336c2007548f909769e0862b509  <= a tag\n     06/\n       0795297c2a6336c2007548f909769e0862b509  <= signature of tag\n   reverse/\n     00/\n       0195297c2a6336c2007548f909769e0862b509/\n         020395297c2a6336c2007548f909769e0862b509  \"this signs commit\"\n         .... other later signatures of this commit go here.\n     04/\n       0595297c2a6336c2007548f909769e0862b509/\n         060795297c2a6336c2007548f909769e0862b509\n         .... other later signatures of this tag go here.\n\nThe reverse directory's contents are basically the filenames.\nThe files themselves could be symlinks back up, or not.\nContent-free files are probably more portable across filesystems,\nand it's probably also good for space efficiency\n(though I haven't examined that carefully).\n\n\"git\"'s knowledge of signatures should be VERY limited, and\nnot dependent on PGP.  I think that'd be easy.\nYou could prepend some signature data into the \"signature\" file to\nmake it much easier to reconstruct the reverse directory and\nto make it easy to check things WITHOUT knowledge of PGP or whatever.\n\nHere's potential output:\n\n$ cat-file commit 000195297c2a6336c2007548f909769e0862b509\ntree 2aaf94eae20acc451553766f3c063bc46cfa75c6\nparent dc459bf85b3ff97333e759d641c5d18f4dad470d\nauthor Petr Baudis <pasky@ucw.cz> 1114303479 +0200\ncommitter Petr Baudis <xpasky@machine.sinus.cz> 1114303479 +0200\n\n    Added the whatsit flag.\n\n\n$ cat-file signature 000195297c2a6336c2007548f909769e0862b509\nsignatureof commit 000195297c2a6336c2007548f909769e0862b509\nsigner Petr Baudis <pasky@ucw.cz>\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.2.6 (GNU/Linux)\n\niD8DBQBCbFaRCxlT/+f+SU4RAgYSAKCWpPNlDKDkxuuA649zJop7WkQPnACdF1Fg\nJgXatbJU8YJ7JHqvgyGepRU=\n=Kttg\n-----END PGP SIGNATURE-----\n\n\n$\n\n--- David A. Wheeler\n"},{"id":"1590","messageId":"Pine.LNX.4.62.0504250435050.14200@sheen.jakma.org","threadId":"194","inReplyTo":"Pine.LNX.4.62.0504250413200.14200@sheen.jakma.org","subject":"Re: Git-commits mailing list feed.","fromName":"Paul Jakma","fromEmail":"paul@clubi.ie","sentAt":"2005-04-25T03:40:26Z","receivedAt":"2005-04-25T03:40:26Z","isPatch":false,"sender":{"key":"paul@clubi.ie","avatar":null},"body":"On Mon, 25 Apr 2005, Paul Jakma wrote:\n\n> You dont even need it, see my other mail. If:\n>\n> - the signature is an object and added after the commit object\n>\n> - tools know that signatures are 'proxies of' or precursors to the\n>  objects they are signing (which makes sense, a signature by\n>  definition refers to something else)\n>\n> - the signature object refers to the object it is signing (eg a\n>  'Signing <object ID>' header)\n>\n> Then head can simply be the signature object and tools can find the \n> commit by following the 'Signing' field of the signature (they dont \n> even need to check the signature is valid). No index lookup needed.\n\n> You only need the index for historical verification really, and you can \n> always generate an index if needs be. (and have the tools maintain it).\n\nUh, I have no idea whether verifying a signature of a commit object \nis sufficient, ie equivalent to signing each file.\n\ncommit refers to tree objects, which I presume lists the SHA-1 object \nIDs of files, but IIRC Linus already described why a signature of the \ncommit object should not be used to trust the rest of commit.. (i'll \nhave to find his mail). If so, an index is required.\n\nregards,\n-- \nPaul Jakma\tpaul@clubi.ie\tpaul@jakma.org\tKey ID: 64A2FF6A\nFortune:\nOld programmers never die, they just hit account block limit.\n"},{"id":"1591","messageId":"Pine.LNX.4.62.0504250443380.14200@sheen.jakma.org","threadId":"194","inReplyTo":"Pine.LNX.4.62.0504250435050.14200@sheen.jakma.org","subject":"Re: Git-commits mailing list feed.","fromName":"Paul Jakma","fromEmail":"paul@clubi.ie","sentAt":"2005-04-25T03:47:07Z","receivedAt":"2005-04-25T03:47:07Z","isPatch":false,"sender":{"key":"paul@clubi.ie","avatar":null},"body":"On Mon, 25 Apr 2005, Paul Jakma wrote:\n\n> Uh, I have no idea whether verifying a signature of a commit object is \n> sufficient, ie equivalent to signing each file.\n>\n> commit refers to tree objects, which I presume lists the SHA-1 object IDs of \n> files, but IIRC Linus already described why a signature of the commit object \n> should not be used to trust the rest of commit.. (i'll have to find his \n> mail). If so, an index is required.\n\nAh, apparently it is sufficient:\n\nLinus:\n\n“Just signing the commit is indeed sufficient to just say \"I trust \nthis commit\". But I essentially what to also say what I trust it \n_for_ as well.”\n\nSo this would work for commit objects.\n\nIt would also work for tag objects, if you pointed people at the signature\nobject rather than the actual tag object.\n\nregards,\n-- \nPaul Jakma\tpaul@clubi.ie\tpaul@jakma.org\tKey ID: 64A2FF6A\nFortune:\nHumor in the Court:\nQ.  Were you aquainted with the deceased?\nA.  Yes, sir.\nQ.  Before or after he died?"},{"id":"1592","messageId":"Pine.LNX.4.58.0504242132280.5064@sam.ics.uci.edu","threadId":"194","inReplyTo":"Pine.LNX.4.62.0504250443380.14200@sheen.jakma.org","subject":"[PATCH] New option (-H) for rpush/rpull to update HEAD","fromName":"Andreas Gal","fromEmail":"gal@uci.edu","sentAt":"2005-04-25T04:39:02Z","receivedAt":"2005-04-25T04:39:02Z","isPatch":true,"sender":{"key":"gal@uci.edu","avatar":null},"body":"\nThis patch adds a new option -H to rpush/rpull to update the\nHEAD pointer when pushing a new release to a remote repository. \n\nSigned-off-by: Andreas Gal <gal@uci.edu>\n\n--- c27af2c2464de28732b8ad1fff3ed8a0804250d6/rpull.c\n+++ rpull.c\n@@ -11,6 +11,7 @@\n static int tree = 0;\n static int commits = 0;\n static int all = 0;\n+static int update_head = 0;\n \n static int fd_in;\n static int fd_out;\n@@ -104,11 +105,13 @@\n \t\t\tall = 1;\n \t\t\ttree = 1;\n \t\t\tcommits = 1;\n+\t\t} else if (argv[arg][1] == 'H') {\n+\t\t\tupdate_head = 1;\n \t\t}\n \t\targ++;\n \t}\n \tif (argc < arg + 2) {\n-\t\tusage(\"rpull [-c] [-t] [-a] commit-id url\");\n+\t\tusage(\"rpull [-c] [-t] [-a] [-H] commit-id url\");\n \t\treturn 1;\n \t}\n \tcommit_id = argv[arg];\n@@ -123,6 +126,11 @@\n \t\treturn 1;\n \tif (process_commit(sha1))\n \t\treturn 1;\n+\tif (update_head) {\n+\t\tFILE* fp = fopen(\"HEAD\", \"w+\");\n+\t\tfprintf(fp, \"%s\\n\", commit_id);\n+\t\tfclose(fp);\n+\t}\n \n \treturn 0;\n }\n--- 0293a1a46311d7e20b13177143741ab9d6d0d201/rpush.c\n+++ rpush.c\n@@ -56,7 +56,7 @@\n                 arg++;\n         }\n         if (argc < arg + 2) {\n-                usage(\"rpush [-c] [-t] [-a] commit-id url\");\n+                usage(\"rpush [-c] [-t] [-a] [-H] commit-id url\");\n                 return 1;\n         }\n \tcommit_id = argv[arg];\n"},{"id":"1593","messageId":"Pine.LNX.4.21.0504250041500.30848-100000@iabervon.org","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504242132280.5064@sam.ics.uci.edu","subject":"Re: [PATCH] New option (-H) for rpush/rpull to update HEAD","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-25T04:47:10Z","receivedAt":"2005-04-25T04:47:10Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 24 Apr 2005, Andreas Gal wrote:\n\n> This patch adds a new option -H to rpush/rpull to update the\n> HEAD pointer when pushing a new release to a remote repository. \n\nUpdating the head pointer (in either direction) should be instead of\nspecifying a commit, and should also apply to http-pull. I've also\nsuggested some changes to the organization of HEAD and related items, so\nthe logical things to read and write are likely to change soon.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"1594","messageId":"Pine.LNX.4.58.0504242149330.5553@sam.ics.uci.edu","threadId":"194","inReplyTo":"Pine.LNX.4.21.0504250041500.30848-100000@iabervon.org","subject":"Re: [PATCH] New option (-H) for rpush/rpull to update HEAD","fromName":"Andreas Gal","fromEmail":"gal@uci.edu","sentAt":"2005-04-25T04:55:46Z","receivedAt":"2005-04-25T04:55:46Z","isPatch":true,"sender":{"key":"gal@uci.edu","avatar":null},"body":"\nWhy? Updating HEAD right after writing the commit id and all its children \nto the object directory seems reasonable and prevents race conditions when \nthe remote repository is shared via HTTP etc. rpull, in contrast, should \nnever touch HEAD, because conflicts might force a merge that will set\nHEAD to something else. For the pull case we should let the script(tm) do\nthat. Its local anyway. rpush is different because the script(tm) has to\ndo some SSH magic to update HEAD. I will gladly supply a patch to fix what \nto read/write once you have figured out the final layout, but I really \nneed a working rpush _NOW_ ;).\n\nAndreas\n\nOn Mon, 25 Apr 2005, Daniel Barkalow wrote:\n\n> On Sun, 24 Apr 2005, Andreas Gal wrote:\n> \n> > This patch adds a new option -H to rpush/rpull to update the\n> > HEAD pointer when pushing a new release to a remote repository. \n> \n> Updating the head pointer (in either direction) should be instead of\n> specifying a commit, and should also apply to http-pull. I've also\n> suggested some changes to the organization of HEAD and related items, so\n> the logical things to read and write are likely to change soon.\n> \n> \t-Daniel\n> *This .sig left intentionally blank*\n> \n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> \n"},{"id":"1598","messageId":"Pine.LNX.4.21.0504250057510.30848-100000@iabervon.org","threadId":"194","inReplyTo":"Pine.LNX.4.58.0504242149330.5553@sam.ics.uci.edu","subject":"Re: [PATCH] New option (-H) for rpush/rpull to update HEAD","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-25T05:18:34Z","receivedAt":"2005-04-25T05:18:34Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 24 Apr 2005, Andreas Gal wrote:\n\n> Why? Updating HEAD right after writing the commit id and all its children \n> to the object directory seems reasonable and prevents race conditions when \n> the remote repository is shared via HTTP etc.\n\nCome to think of it, the option I was thinking of is orthogonal to your\noption; I was thinking of an option to read the head from the sending\nside's file, rather than from the command line.\n\nIn any case, if you're sharing the repository by HTTP, there's no hurry to\nupdate the HEAD right after, since the old head doesn't stop being valid\n(although it's obviously not going to be current in a moment).\n\n> rpull, in contrast, should  never touch HEAD, because conflicts might\n> force a merge that will set HEAD to something else. For the pull case we\n> should let the script(tm) do that.\n\nFor the rpull case, what you want is to just say \"HEAD\" (or something),\nand the remote server will send you the HEAD and you pull down that\ncommit. You're probably right that you don't want to automatically write\nit to the local HEAD, though, although the future format should give us\nsomewhere good to put the result.\n\n> Its local anyway. rpush is different because the script(tm) has to do\n> some SSH magic to update HEAD. I will gladly supply a patch to fix what\n> to read/write once you have figured out the final layout, but I really\n> need a working rpush _NOW_ ;). \n\nThat was actually my motice in getting rpush/rpull/http-pull in, too.\n\nIf you're going to do much serious with this, you should probably remove\nthe if (has_sha1_file()) continue;\" bit in process_commit(), so that it\nwill make sure that the repository gets pulled completely with -a, even if\nsome commits have already been pulled. (This will make things less\nefficient, but less error-prone, and we'll fix the inefficiency later.)\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"1601","messageId":"426CB8F9.5010602@dgreaves.com","threadId":"194","inReplyTo":"426C64E4.4090600@dwheeler.com","subject":"Re: Git-commits mailing list feed.","fromName":"David Greaves","fromEmail":"david@dgreaves.com","sentAt":"2005-04-25T09:31:37Z","receivedAt":"2005-04-25T09:31:37Z","isPatch":false,"sender":{"key":"david@dgreaves.com","avatar":"https://gravatar.com/avatar/ca67bad50999edcdd137c9a65da2381557d175bea99ae956afdabc5785e42b79?d=mp&s=160"},"body":"David A. Wheeler wrote:\n  > $ cat-file signature 000195297c2a6336c2007548f909769e0862b509\nminor comment, cat-file gives you raw access to the object data.\n\nbetter:\n$ cat-file signature $(what-signs 000195297c2a6336c2007548f909769e0862b509)\n> signatureof commit 000195297c2a6336c2007548f909769e0862b509\n> signer Petr Baudis <pasky@ucw.cz>\n> \n> -----BEGIN PGP SIGNATURE-----\n> Version: GnuPG v1.2.6 (GNU/Linux)\n> \n> iD8DBQBCbFaRCxlT/+f+SU4RAgYSAKCWpPNlDKDkxuuA649zJop7WkQPnACdF1Fg\n> JgXatbJU8YJ7JHqvgyGepRU=\n> =Kttg\n> -----END PGP SIGNATURE-----\n\nDavid\n\n\n-- \n"}]}