{"thread":{"id":"28805","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","startedAt":"2011-10-31T08:40:48Z","lastAt":"2011-11-11T05:26:35Z","messageCount":81,"participants":["Ingo Molnar","Junio C Hamano","Ted Ts'o","Linus Torvalds","H. Peter Anvin","Jiri Kosina","Jeff Garzik","James Bottomley","Michael J Gruber","Jochen Striepe","david@lang.hm","Shawn Pearce","Jeff King","Robin H. Johnson","valdis.kletnieks@vt.edu","Johan Herland","David Woodhouse","Marc Branchaud"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"178553","messageId":"20111031084048.GA11807__21610.4542407722$1320051469$gmane$org@elte.hu","threadId":"28805","inReplyTo":"CA+55aFx1NGWfNJAKDTvZfsHDDKiEtS4t4RydSgHurBeyGPyhXg@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2011-10-31T08:40:48Z","receivedAt":"2011-10-31T08:40:48Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Linus Torvalds wrote:\n\n> That said, even the \"BEGIN PGP SIGNED MESSAGE\" things are a massive \n> pain in the butt. We need to automate this some sane way, both for \n> the sender and for the recipient.\n\nThe most practical form would be if Git supported such oneliner pull \nrequests:\n\n git pull git://foo.com bar.branch \\\n --pull-sha1 0acf00014bcfd71090c3b0d43c98e970108064e4 \\\n --gpg-by: \"Ingo Molnar \" \\\n --gpg-sig: 8a6f134afd1d212fe21345\n\nmaintainers could just paste them into a shell and it would abort if \nit's not trusted. The maintainer verifies the visible, 'Ingo Molnar' \nbit. The 8a6f134afd1d212fe21345 is a signed-by-Ingo-Molnar version of \nthis content:\n\n git://foo.com bar.branch 0acf00014bcfd71090c3b0d43c98e970108064e4\n\nAnd Git would verify that what ends up being pulled is indeed \n0acf00014bcfd and also verifies that it was signed by me.\n\n[ If we are extra diligent/paranoid then beyond the sha1 we might \n even GPG sign the shortlog, or even the full raw log of all commits \n leading to the sha1: this introduces some Git shortlog and patch \n formatting version dependency though.\n\n Git could also double check foo.com's DNS coherency, or check it \n against a known-trusted whitelist of domain names specified in the \n maintainer's .gitconfig, as an extra layer. ]\n\nDoing it in this form would remove all the mail formatting madness - \none could paste such a pull request into a shell straight away, from \nHTML email, from text email, from MIME email, etc.\n\nIn fact i would trust such a Git based solution far more than any \nopaque, invisible tool that claims to have checked a signature with \ncooperation of my mail client (ha!).\n\nThe only somewhat non-obvious bit is that Git should be *very* \ncareful about its key ID and signature parsing strategy, to protect \nagainst social engineering attacks.\n\nFor example neither this:\n\n --gpg-by: \"Ingo Molnar \"\n\nnor this:\n\n --pgp-by: \"Ingo Molnar \"\n\nmalicious pull request should slip through in any fashion:\n\n - Git should only use keys that are in your ring of trust - not pull \n keys from the public keyring automatically and just check \n coherency of the pull request or such. [I'm sure people will be \n tempted to have such a feature - but that temptation should be \n resisted.]\n\n - Git should abort the moment it sees an unknown option\n\nThanks,\n\n\tIngo\n"},{"id":"299187","messageId":"20111031084048.GA11807@elte.hu","threadId":"28805","inReplyTo":"CA+55aFx1NGWfNJAKDTvZfsHDDKiEtS4t4RydSgHurBeyGPyhXg@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2011-10-31T08:40:48Z","receivedAt":"2011-10-31T08:40:48Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Linus Torvalds wrote:\n\n> That said, even the \"BEGIN PGP SIGNED MESSAGE\" things are a massive \n> pain in the butt. We need to automate this some sane way, both for \n> the sender and for the recipient.\n\nThe most practical form would be if Git supported such oneliner pull \nrequests:\n\n git pull git://foo.com bar.branch \\\n --pull-sha1 0acf00014bcfd71090c3b0d43c98e970108064e4 \\\n --gpg-by: \"Ingo Molnar \" \\\n --gpg-sig: 8a6f134afd1d212fe21345\n\nmaintainers could just paste them into a shell and it would abort if \nit's not trusted. The maintainer verifies the visible, 'Ingo Molnar' \nbit. The 8a6f134afd1d212fe21345 is a signed-by-Ingo-Molnar version of \nthis content:\n\n git://foo.com bar.branch 0acf00014bcfd71090c3b0d43c98e970108064e4\n\nAnd Git would verify that what ends up being pulled is indeed \n0acf00014bcfd and also verifies that it was signed by me.\n\n[ If we are extra diligent/paranoid then beyond the sha1 we might \n even GPG sign the shortlog, or even the full raw log of all commits \n leading to the sha1: this introduces some Git shortlog and patch \n formatting version dependency though.\n\n Git could also double check foo.com's DNS coherency, or check it \n against a known-trusted whitelist of domain names specified in the \n maintainer's .gitconfig, as an extra layer. ]\n\nDoing it in this form would remove all the mail formatting madness - \none could paste such a pull request into a shell straight away, from \nHTML email, from text email, from MIME email, etc.\n\nIn fact i would trust such a Git based solution far more than any \nopaque, invisible tool that claims to have checked a signature with \ncooperation of my mail client (ha!).\n\nThe only somewhat non-obvious bit is that Git should be *very* \ncareful about its key ID and signature parsing strategy, to protect \nagainst social engineering attacks.\n\nFor example neither this:\n\n --gpg-by: \"Ingo Molnar \"\n\nnor this:\n\n --pgp-by: \"Ingo Molnar \"\n\nmalicious pull request should slip through in any fashion:\n\n - Git should only use keys that are in your ring of trust - not pull \n keys from the public keyring automatically and just check \n coherency of the pull request or such. [I'm sure people will be \n tempted to have such a feature - but that temptation should be \n resisted.]\n\n - Git should abort the moment it sees an unknown option\n\nThanks,\n\n\tIngo\n"},{"id":"178568","messageId":"7vy5w1ow90.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"CA+55aFz3=cbciRfTYodNhdEetXYxTARGTfpP9GL9RZK222XmKQ@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-10-31T18:23:55Z","receivedAt":"2011-10-31T18:23:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> For the people who use \"git request-pull\", I'm attaching a trivial\n> patch to make it add this kind of signature if you give it the \"-s\"\n> flag. It basically just adds a hunk like the appended crazy example to\n> the pull request, and it's small enough and simple enough that it\n> makes verification simple too with just the above kind of trivial\n> cut-and-paste thing.\n>\n> (Junio cc'd, I think he had something more complicated in mind)\n\nYou have misread me this time.\n\nI think the minimalistic \"paste this line to your 'git pull' command line\nand expect to get history leading to this commit\" like you did in your\npatch would be the solution that is the least painful and still useful,\nwhich is an important criterion for wide adoption.\n\n> Now, admittedly it would be *even nicer* if this gpg-signed block was\n> instead uploaded as a signed tag automatically, and \"git pull\" would\n> notice such a signed tag (tagname the same as the branch name + date\n> or something) and would download and verify the tag as I pull. Then I\n> wouldn't even need to actually do the cut-and-paste at all. But this\n> is the *really* simple approach that gets up 95% of the way there.\n\nI however have a small trouble with \"lieutenants use signed tags in order\nto prove who they are to Linus\", depending on the details.\n\nIt certainly lets you run \"git tag --verify\" after you pulled and will\ngive you assurance that you pulled the right thing from the right person,\nbut what do you plan to do to the tag from your lieutenants after you\nfetched and verified? I count 379 merges by you between 3.0 (2011-07-21)\nand 3.1 (2011-10-24), which would mean you would see 4-5 tags per day on\naverage. Will these tags be pushed out to your public history?\n\nOn one hand, we (not just you but the consumers of \"Linus kernel\") can\nconsider these tags are of ephemeral nature. Once they are used for _you_\nto verify the authenticity, they are not needed anymore. The consumers of\n\"Linus kernel\" by definition trusts what you publish, so as long as they\nhave a way to verify the tip commit you push out, they _should_ be happy.\nIf you take this stance, you would not push these tags out so that you do\nnot have to contaminate the tags namespace with them, and you might even\nchoose to discard them once you pulled and verified the lieutenants' tips\nto avoid contamination of your own refs namespace.\n\nOn the other hand, the consumers of \"Linus kernel\" may want to say that\nthey trust your tree and your tags because they can verify them with your\nGPG signature, but also they can independently verify the lieutenants'\ntrees you pulled from are genuine. Keeping signed tags and publishing them\nis one way to make it possible, but 400 extra tags in 3 months feels like\nan approach with too much downside (i.e. noise) for that benefit.\n\nOn Git mailing list, we have been toying with a couple of ideas. The\nsimplest one (cooking in next) is to allow committers to add gpg signature\nin an additional header of the commit objects. \"git show\" and friends are\ntaught how to verify these signatures when asked.\n\nThis might have a potential downside on the lieutenants' workflow; after\nintegrating the work by their sub-lieutenants and by themselves, they\nwould test and review the result to convince themselves that it is worth\nasking you to pull, and then they have to either\n\n (1) \"commit --amend --gpg-signature\" the tip; or\n\n (2) \"commit --allow-empty --gpg-signature\" to add an empty commit\n whose sole purpose is to hold the signature (and avoid amending\n the tip)\n\nbefore pushing it out, asking you to pull.\n\nAn alternative we have discussed was to store gpg signature for the commit\n(\"push certificate\") somewhere in notes tree and push that out, certifying\nthat the commit indeed came from the pusher, but that would:\n\n (1) require upstreams to fetch (and possibly suffer from merge conflicts\n in notes tree) push certificate whenever they pull from their\n lieutenants; and\n\n (2) require downstreams to also fetch the notes tree for \"push\n certificates\" (especially when the central repository is shared among\n multiple people) before adding their own signature and then push it\n back (and possiblly suffer from \"non-fast-forward\" in notes tree).\n\nboth of which are downsides coming from \"notes\" being not a very good\nmatch for what these signatures are trying to achieve.\n\nNamely, the current \"notes\" mechanism is designed to keep track of history\nof changes made to notes attached to commits, but for the signature\napplication, we do not care about the order that signatures came to two\nseparate commits. \"Non-fast-forward\" conflicts while pushing, or having to\nfetch and merge before adding one's own signature, are unwanted burden\nimposed only by choosing to use \"notes\" for storing and conveying the\nsignature.\n\nAlso the \"notes\" approach would end up mixing \"push certificates\" for\ndifferent branches (this won't be an issue in your repository where there\nis only one branch) into a single \"notes\" tree. We would want to use\nsomething that behaves more like the \"auto-following\" semantics of tag\nobjects. You would want to fetch only signatures that are attached to the\ncommits you are fetching. Use of signed tags, or commit objects that can\nbe signed in-place, have this property, but storing signature in notes\ntree does not give it to us.\n\nI think further discussions on this should continue on the git mailing\nlist.\n"},{"id":"178579","messageId":"20111031203059.GJ16825@thunk.org","threadId":"28805","inReplyTo":"7vy5w1ow90.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Ted Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2011-10-31T20:30:59Z","receivedAt":"2011-10-31T20:30:59Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"(removing linux-ide and linux-kernel)\n\nOn Mon, Oct 31, 2011 at 11:23:55AM -0700, Junio C Hamano wrote:\n> On the other hand, the consumers of \"Linus kernel\" may want to say that\n> they trust your tree and your tags because they can verify them with your\n> GPG signature, but also they can independently verify the lieutenants'\n> trees you pulled from are genuine. Keeping signed tags and publishing them\n> is one way to make it possible, but 400 extra tags in 3 months feels like\n> an approach with too much downside (i.e. noise) for that benefit.\n\nI wouldn't put it as \"we don't trust Linus's tree\", because it's not\ntrue. In general, we do trust Linus's tree. On the other hand, it's\nuseful if the proof which was submitted at the time of the push could\nbe verified by third parties.\n\nSuppose the project wasn't Linus, but some other project, say, a\nhypothetical Desktop system called Troll3. Let's assume that it's run\nby a sole dictator, S. Crew Powerusers, who blindly assumes that any\ntree on github is secure, and is confident he or she can detect social\nengineering attacks caused by a bad guy grabbing a developer's SSH key\nused to push to github, and who can fake a pull request to Linus that\nlooks real but is really originated by the bad guy. Let's assume\nfurther that the pull request has a signed tag which could be used to\ndetect such forgeries, but because Mr. Powerusers can't be bothered to\ncheck the tag, because he can't figure out how to update his GPG\nkeyring and besides, he hates crypto stuff --- and the bad guys know\nthis, and are good (Kevin Mitnick or better) at social engineering\nattacks.\n\nIn this sort of scenario, it's useful if *other* people could\nindependently verify the Troll3 git tree via the crypto signatures,\neven though the central maintainer couldn't be bothered to check the\ncrypto signatures.\n\n\nHere's an idea.... what if the \"signed push\" information could be\nembedded into the merge commit's description? That is, the\ninformation could sent via a signed git tag, or some other mechanism,\nbut then part of the git merge would incorporate the GPG signature\ninto the merge commit's description field (and we could always create\na merge commit so there's a place to put the digital siganture). That\nway, it's mostly out of the way, but it's in a well-defined place\nwhere it will always easy to have a third party independently verify\nthe source of a set of commits in the git tree.\n\nThe problem with notes and tags is that they have to be pushed\nseparately, and might get lost; where as if they are stored in the\nmerge commit's description, they will always be there.\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"178581","messageId":"7v8vo0q3ve.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"20111031203059.GJ16825@thunk.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-10-31T20:53:57Z","receivedAt":"2011-10-31T20:53:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ted Ts'o writes:\n\n> Suppose the project wasn't Linus, but some other project, say, a\n> ...\n> this, and are good (Kevin Mitnick or better) at social engineering\n> attacks.\n>\n> In this sort of scenario, it's useful if *other* people could\n> independently verify the Troll3 git tree via the crypto signatures,\n> even though the central maintainer couldn't be bothered to check the\n> crypto signatures.\n\nI think we are in total agreement here ;-)\n\n> Here's an idea.... what if the \"signed push\" information could be\n> embedded into the merge commit's description? That is, the\n> information could sent via a signed git tag, or some other mechanism,...\n\nI think you described what the signed-commit series that is cooking in\n'next' is about way better than I have done so far ;-)\n\nThe contributors sign the tips of their histories (which can independently\nbe validated), the integrator pulls and can choose to bother or not to\nbother the tips s/he obtains, and the integrator signs his/her tip before\ns/he pushes the integration result out for general consumption.\n\n> ...\n> The problem with notes and tags is that they have to be pushed\n> separately, and might get lost; where as if they are stored in the\n> merge commit's description, they will always be there.\n\nExactly.\n"},{"id":"178582","messageId":"7v4nyoq0o2.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"20111031084048.GA11807__21610.4542407722$1320051469$gmane$org@elte.hu","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-10-31T22:03:09Z","receivedAt":"2011-10-31T22:03:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ingo Molnar writes:\n\n> * Linus Torvalds wrote:\n>\n>> That said, even the \"BEGIN PGP SIGNED MESSAGE\" things are a massive \n>> pain in the butt. We need to automate this some sane way, both for \n>> the sender and for the recipient.\n>\n> The most practical form would be if Git supported such oneliner pull \n> requests:\n>\n> git pull git://foo.com bar.branch \\\n> --pull-sha1 0acf00014bcfd71090c3b0d43c98e970108064e4 \\\n> --gpg-by: \"Ingo Molnar \" \\\n> --gpg-sig: 8a6f134afd1d212fe21345\n>\n> maintainers could just paste them into a shell and it would abort if \n> it's not trusted. The maintainer verifies the visible, 'Ingo Molnar' \n> bit. The 8a6f134afd1d212fe21345 is a signed-by-Ingo-Molnar version of \n> this content:\n>\n> git://foo.com bar.branch 0acf00014bcfd71090c3b0d43c98e970108064e4\n\nAs a command line syntax, I think the new \"--flag\"s should all come\nbefore non flag options to the \"pull\" subcommand, i.e.\n\n git pull --sha1 0acf00014bcfd71090c3b0d43c98e970108064e4 \\\n \t --gpg-by \"Ingo Molnar \" \\\n git://foo.com bar.branch\n\nI do not understand what you meant by that \"8a6f13...\". When I run\n\n $ echo \"git://foo.com bar.branch 0acf00014bcfd71090c3b0d43c98e970108064e4\" |\n gpg -sa\n\nI would get about 20 lines of solid gibberish, nothing close to that\nclean and concise 20-or-so character sequence.\n\nIn any case, I do not think that \"this site, that branch\" information is\nessential for the purpose of validation. I think I saw Linus responding to\na pull request saying \"Your pull request says master but I found nothing\nthere; I assume you meant for-linus branch\" or something similar, and as\nlong as that matches the expectation of the contributor, especially if you\nspecify \"I want you to get _this_ commit\" in your request-pull message, it\nshould not matter how/where Linus gets the history leading to that commit.\n\nAs \"git-pull\" is still a scripted Porcelain, interested people should be\nable to experiment this idea by doing something like this:\n\n 1. The requestor signs the tip commit to be fetched with the version of\n git from the \"next\" branch, i.e. \"git commit -S\", and pushes it to his\n publishing location;\n\n 2. Around line 207, \"git pull\" spawns \"git fetch\", stops if dry-run. At\n that point, you can:\n\n - parse FETCH_HEAD and verify the SHA-1 matches what you got from the\n command line;\n\n - run \"git show -s --show-signature FETCH_HEAD\" (again, use the\n version of git from the \"next\" branch) to let GPG parse the\n signature.\n\n and stop if either test fails.\n\n"},{"id":"178583","messageId":"CA+55aFwL_s=DcT46dprcYVWEAm_=WkuTV6K9dAn3wc_bDQU8vA@mail.gmail.com","threadId":"28805","inReplyTo":"7vy5w1ow90.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-10-31T22:18:28Z","receivedAt":"2011-10-31T22:18:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Mon, Oct 31, 2011 at 11:23 AM, Junio C Hamano wrote:\n>\n> It certainly lets you run \"git tag --verify\" after you pulled and will\n> give you assurance that you pulled the right thing from the right person,\n> but what do you plan to do to the tag from your lieutenants after you\n> fetched and verified?  I count 379 merges by you between 3.0 (2011-07-21)\n> and 3.1 (2011-10-24), which would mean you would see 4-5 tags per day on\n> average.  Will these tags be pushed out to your public history?\n\nNo, you misunderstand.\n\nI can do that kind of \"crazy manual check of a tag\" today. And it's\ntoo painful to be useful in the long run (or even the short run - I'd\nmuch prefer the pgp signature in the email which is easier to check\nand more visible anyway). Fetching a tag by name and saving it as a\ntag is indeed pointless.\n\nBut what would be nice is that \"git pull\" would fetch the tag (based\non name) *automatically*, and not actually create a tag in my\nrepository at all. Instead, if would use the tag to check the\nsignature, and - if we do this right - also use the tag contents to\npopulate the merge commit message.\n\nIn other words, no actual tag would ever be left around as a turd, it\nwould simply be used as an automatic communication channel between the\n\"git push -s\" of the submitter and my subsequent \"git pull\". Neither\nside would have to do anything special, and the tag would never show\nup in any relevant tree (it could even be in a totally separate\nnamespace like \"refs/pullmarker/\" or something).\n\n Linus\n"},{"id":"178584","messageId":"4EAF1F40.3030907@zytor.com","threadId":"28805","inReplyTo":"CA+55aFwL_s=DcT46dprcYVWEAm_=WkuTV6K9dAn3wc_bDQU8vA@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2011-10-31T22:20:48Z","receivedAt":"2011-10-31T22:20:48Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"On 10/31/2011 03:18 PM, Linus Torvalds wrote:\n> On Mon, Oct 31, 2011 at 11:23 AM, Junio C Hamano wrote:\n>>\n>> It certainly lets you run \"git tag --verify\" after you pulled and will\n>> give you assurance that you pulled the right thing from the right person,\n>> but what do you plan to do to the tag from your lieutenants after you\n>> fetched and verified? I count 379 merges by you between 3.0 (2011-07-21)\n>> and 3.1 (2011-10-24), which would mean you would see 4-5 tags per day on\n>> average. Will these tags be pushed out to your public history?\n> \n> No, you misunderstand.\n> \n> I can do that kind of \"crazy manual check of a tag\" today. And it's\n> too painful to be useful in the long run (or even the short run - I'd\n> much prefer the pgp signature in the email which is easier to check\n> and more visible anyway). Fetching a tag by name and saving it as a\n> tag is indeed pointless.\n> \n> But what would be nice is that \"git pull\" would fetch the tag (based\n> on name) *automatically*, and not actually create a tag in my\n> repository at all. Instead, if would use the tag to check the\n> signature, and - if we do this right - also use the tag contents to\n> populate the merge commit message.\n> \n> In other words, no actual tag would ever be left around as a turd, it\n> would simply be used as an automatic communication channel between the\n> \"git push -s\" of the submitter and my subsequent \"git pull\". Neither\n> side would have to do anything special, and the tag would never show\n> up in any relevant tree (it could even be in a totally separate\n> namespace like \"refs/pullmarker/\" or something).\n> \n\nPerhaps we should introduce the notion of a \"private tag\" or something\nalong those lines? (I guess that would still have to be possible to\npush it, but not pull it by default...)\n\n\t-hpa\n\n"},{"id":"178586","messageId":"CA+55aFxprv9JR4gtt_UDXheHR5G8PrUA3-Mj0CPsU6E5EzNYeg@mail.gmail.com","threadId":"28805","inReplyTo":"4EAF1F40.3030907@zytor.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-10-31T22:30:32Z","receivedAt":"2011-10-31T22:30:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Mon, Oct 31, 2011 at 3:20 PM, H. Peter Anvin wrote:\n>\n> Perhaps we should introduce the notion of a \"private tag\" or something\n> along those lines?  (I guess that would still have to be possible to\n> push it, but not pull it by default...)\n\nAll tags are private by default.\n\nWe actually *only* fetch tags if somebody explicitly asks for them\n(--tags), or when fetching from a named remote (and even then it will\nonly fetch tags that point to objects you fetched by default iirc -\nyou have to mark the remote specially to get *all* tags).\n\nBut if you do the normal \"git pull git://git.kernel.org/name/of/repo\"\n- which is how things happen as a result of a pull request - you won't\nget tags at all - you have to ask for them by name or use \"--tags\" to\nget them all.\n\n Linus\n"},{"id":"178587","messageId":"alpine.LRH.2.00.1110312332410.24704@twin.jikos.cz","threadId":"28805","inReplyTo":"4EAF1F40.3030907@zytor.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Jiri Kosina","fromEmail":"jkosina@suse.cz","sentAt":"2011-10-31T22:33:09Z","receivedAt":"2011-10-31T22:33:09Z","isPatch":false,"sender":{"key":"jkosina@suse.cz","avatar":null},"body":"On Mon, 31 Oct 2011, H. Peter Anvin wrote:\n\n> Perhaps we should introduce the notion of a \"private tag\" or something\n> along those lines? (I guess that would still have to be possible to\n> push it, but not pull it by default...)\n\nThat's exactly what git does now, right? (unless you pull from a very \nspecific remote).\n\n-- \nJiri Kosina\nSUSE Labs\n\n"},{"id":"178588","messageId":"4EAF2245.90308@zytor.com","threadId":"28805","inReplyTo":"CA+55aFxprv9JR4gtt_UDXheHR5G8PrUA3-Mj0CPsU6E5EzNYeg@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2011-10-31T22:33:41Z","receivedAt":"2011-10-31T22:33:41Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"On 10/31/2011 03:30 PM, Linus Torvalds wrote:\n> \n> But if you do the normal \"git pull git://git.kernel.org/name/of/repo\"\n> - which is how things happen as a result of a pull request - you won't\n> get tags at all - you have to ask for them by name or use \"--tags\" to\n> get them all.\n> \n\nDidn't realize that... I guess I'm too used to named remotes.\n\nIf so, just using a tag should be fine, no?\n\n\t-hpa\n"},{"id":"178589","messageId":"CA+55aFzedaAzzWfzhqVf8y8ZW0jeb56hZwdV3UodSp8Q_Qhc2A@mail.gmail.com","threadId":"28805","inReplyTo":"4EAF2245.90308@zytor.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-10-31T22:38:54Z","receivedAt":"2011-10-31T22:38:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Mon, Oct 31, 2011 at 3:33 PM, H. Peter Anvin wrote:\n>\n> Didn't realize that... I guess I'm too used to named remotes.\n>\n> If so, just using a tag should be fine, no?\n\nYes, that's what I think. But the argument for using a separate\nnamespace is that\n (a) you never get confused\n (b) it would make it easier to make the 1:1 relationship between\nbranch names and these \"pull request signature tags\" without limiting\nthe naming of *normal* tags in any way\n (c) they do have separate lifetimes from \"real\" tags.\n\nBut seriously, I don't care about the *implementation* all that much.\nIf people want to use the crazy git \"notes\" capability, you can do\nthat too, although quite frankly, I don't see the point. What actually\nmatters is that \"git push\" and \"git pull\" would JustWork(tm), and\ncheck the signature if one exists, without having to cut-and-paste\ndata that simply shouldn't be visible to the user.\n\nI abhor the interface Ingo suggested, for example. Why would we have\nstupid command line options that we should cut-and-paste? Automation\nis for computers, not for people.\n\n Linus\n"},{"id":"178591","messageId":"7vzkggok6u.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"4EAF2245.90308@zytor.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-10-31T22:44:25Z","receivedAt":"2011-10-31T22:44:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n> On 10/31/2011 03:30 PM, Linus Torvalds wrote:\n>> \n>> But if you do the normal \"git pull git://git.kernel.org/name/of/repo\"\n>> - which is how things happen as a result of a pull request - you won't\n>> get tags at all - you have to ask for them by name or use \"--tags\" to\n>> get them all.\n>> \n>\n> Didn't realize that... I guess I'm too used to named remotes.\n>\n> If so, just using a tag should be fine, no?\n\nSo nobody is worried about this (quoting from my earlier message)?\n\n On the other hand, the consumers of \"Linus kernel\" may want to say that\n they trust your tree and your tags because they can verify them with your\n GPG signature, but also they can independently verify the lieutenants'\n trees you pulled from are genuine.\n\nA signed emphemeral tag is usable as means to verify authenticity in a\nhop-by-hop fashion, but that does not leave a permanent trail that can be\nused for auditing.\n"},{"id":"178592","messageId":"4EAF2567.5080108@zytor.com","threadId":"28805","inReplyTo":"7vzkggok6u.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2011-10-31T22:47:03Z","receivedAt":"2011-10-31T22:47:03Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"On 10/31/2011 03:44 PM, Junio C Hamano wrote:\n> \"H. Peter Anvin\" writes:\n> \n>> On 10/31/2011 03:30 PM, Linus Torvalds wrote:\n>>>\n>>> But if you do the normal \"git pull git://git.kernel.org/name/of/repo\"\n>>> - which is how things happen as a result of a pull request - you won't\n>>> get tags at all - you have to ask for them by name or use \"--tags\" to\n>>> get them all.\n>>>\n>>\n>> Didn't realize that... I guess I'm too used to named remotes.\n>>\n>> If so, just using a tag should be fine, no?\n> \n> So nobody is worried about this (quoting from my earlier message)?\n> \n> On the other hand, the consumers of \"Linus kernel\" may want to say that\n> they trust your tree and your tags because they can verify them with your\n> GPG signature, but also they can independently verify the lieutenants'\n> trees you pulled from are genuine.\n> \n> A signed emphemeral tag is usable as means to verify authenticity in a\n> hop-by-hop fashion, but that does not leave a permanent trail that can be\n> used for auditing.\n> \n\nWell, the permanent trail is in the maintainer's tree, but that might\nstill be suboptimal. The problem with Linus pulling those tags I assume\nthat it makes the tree too noisy?\n\n\t-hpa\n"},{"id":"178593","messageId":"20111031224905.GQ16825@thunk.org","threadId":"28805","inReplyTo":"7vzkggok6u.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Ted Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2011-10-31T22:49:05Z","receivedAt":"2011-10-31T22:49:05Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Oct 31, 2011 at 03:44:25PM -0700, Junio C Hamano wrote:\n> So nobody is worried about this (quoting from my earlier message)?\n> \n> On the other hand, the consumers of \"Linus kernel\" may want to say that\n> they trust your tree and your tags because they can verify them with your\n> GPG signature, but also they can independently verify the lieutenants'\n> trees you pulled from are genuine.\n> \n> A signed emphemeral tag is usable as means to verify authenticity in a\n> hop-by-hop fashion, but that does not leave a permanent trail that can be\n> used for auditing.\n\nOh, there are definitely people who worry about this. They tend to be\nsecurity poeple, though, so the goal is how do we leave the permanent\ntrail in a way that doesn't generate too much noise or otherwise makes\nlife difficult for developers who don't care.\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"178594","messageId":"7vvcr4ojvp.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"CA+55aFzedaAzzWfzhqVf8y8ZW0jeb56hZwdV3UodSp8Q_Qhc2A@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-10-31T22:51:06Z","receivedAt":"2011-10-31T22:51:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> But seriously, I don't care about the *implementation* all that much.\n> If people want to use the crazy git \"notes\" capability, you can do\n> that too, although quite frankly, I don't see the point.\n\nAs I already said, I do not think notes is a good match as a tool to do\nthis.\n\n> matters is that \"git push\" and \"git pull\" would JustWork(tm), and\n> check the signature if one exists, without having to cut-and-paste\n> data that simply shouldn't be visible to the user.\n>\n> I abhor the interface Ingo suggested, for example....\n\nSome cut-and-paste (or piping the e-mail to a command) would be necessary\nevil, though, as you would have GPG keys from more than one trusted person\nin your keyring, and when you are responding to a pull-request from person\nA, finding a valid commit signed by person B should not be a success, but\nat least should raise a warning.\n"},{"id":"178595","messageId":"4EAF2688.9000508@zytor.com","threadId":"28805","inReplyTo":"20111031224905.GQ16825@thunk.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2011-10-31T22:51:52Z","receivedAt":"2011-10-31T22:51:52Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"On 10/31/2011 03:49 PM, Ted Ts'o wrote:\n> On Mon, Oct 31, 2011 at 03:44:25PM -0700, Junio C Hamano wrote:\n>> So nobody is worried about this (quoting from my earlier message)?\n>>\n>> On the other hand, the consumers of \"Linus kernel\" may want to say that\n>> they trust your tree and your tags because they can verify them with your\n>> GPG signature, but also they can independently verify the lieutenants'\n>> trees you pulled from are genuine.\n>>\n>> A signed emphemeral tag is usable as means to verify authenticity in a\n>> hop-by-hop fashion, but that does not leave a permanent trail that can be\n>> used for auditing.\n> \n> Oh, there are definitely people who worry about this. They tend to be\n> security poeple, though, so the goal is how do we leave the permanent\n> trail in a way that doesn't generate too much noise or otherwise makes\n> life difficult for developers who don't care.\n> \n\nCould we introduce a tag namespace that doesn't show up in gitweb by\ndefault, and perhaps doesn't resolve in abbreviated form?\n\nThis is basically what Linus suggested, as far as I understand:\nsomething like refs/pulls/hpa/tip-123-456 which is otherwise a normal\ntag object?\n\n\t-hpa\n\n\n"},{"id":"178596","messageId":"CA+55aFwnVZ-mK3FChvFn778Z-cT107f4v-h0CDmwkP88=Z9aHA@mail.gmail.com","threadId":"28805","inReplyTo":"7vzkggok6u.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-10-31T22:52:26Z","receivedAt":"2011-10-31T22:52:26Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Mon, Oct 31, 2011 at 3:44 PM, Junio C Hamano wrote:\n>\n> So nobody is worried about this (quoting from my earlier message)?\n\nNo, because you haven't been reading what we write.\n\nThe tag is useless.\n\nThe information *in* the tag is not. But it shouldn't be saved in the\ntag (or note, or whatever). Because that's just an annoying place for\nit to be, with no upside.\n\nSave it in the commit we generate. BAM! Useful, readable, permanent,\nand independently verifiable.\n\nAnd the advantage is that we can make that same mechanism add\n\"maintainer notes\" to the merge message too. Right now some\nmaintainers write good notes about what the merge will bring in, but\nthey are basically lost, because git is so good at merging and doesn't\neven stop to ask people to edit the merge message.\n\n Linus\n"},{"id":"178597","messageId":"4EAF2724.8040001@zytor.com","threadId":"28805","inReplyTo":"CA+55aFwnVZ-mK3FChvFn778Z-cT107f4v-h0CDmwkP88=Z9aHA@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2011-10-31T22:54:28Z","receivedAt":"2011-10-31T22:54:28Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"On 10/31/2011 03:52 PM, Linus Torvalds wrote:\n> \n> Save it in the commit we generate. BAM! Useful, readable, permanent,\n> and independently verifiable.\n> \n\nNote: this means creating a commit even for a fast-forward merge. Not\nthat there is any technical problem with that, of course.\n\n\t-hpa\n\n"},{"id":"178598","messageId":"CA+55aFyKWLUMQFfaeKJKGFPV_7kfOGjf+pSZ1Y8afzkT4OYQ9Q@mail.gmail.com","threadId":"28805","inReplyTo":"7vvcr4ojvp.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-10-31T22:56:35Z","receivedAt":"2011-10-31T22:56:35Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Mon, Oct 31, 2011 at 3:51 PM, Junio C Hamano wrote:\n>\n> Some cut-and-paste (or piping the e-mail to a command) would be necessary\n> evil, though, as you would have GPG keys from more than one trusted person\n> in your keyring, and when you are responding to a pull-request from person\n> A, finding a valid commit signed by person B should not be a success, but\n> at least should raise a warning.\n\nWhy?\n\nThe signer of the message needs to be printed out *anyway*. I can\nmatch that up with the pull request, the same way I already match up\ndiffstat information.\n\nSo any extra cut-and-paste is (a) stupid, (b) unnecessary and (c) annoying.\n\nIt's also \"bad user interface\". The whole point is that we should make\nthe user interface *good*. Which means that the pushing side should\nonly need to add a \"-s\" to ask for signing, have to type his\npassphrase (and even that would go away when using gpg-agent or\nsomething), and perhaps a message (which would not be about the\nsigning, but about something that could be added to the merge commit.\n\nAnd the receiving side would just do the \"git pull\" and automatically\njust get notified that \"Yes, this push has been signed by key Xyz\nAbcdef\"\n\n Linus\n"},{"id":"178599","messageId":"CA+55aFxAcNW4obDzQ3fKvaBwj0Ssx_TD-RgrBaJ=Tb4hRtr4DA@mail.gmail.com","threadId":"28805","inReplyTo":"4EAF2724.8040001@zytor.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-10-31T23:03:48Z","receivedAt":"2011-10-31T23:03:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Mon, Oct 31, 2011 at 3:54 PM, H. Peter Anvin wrote:\n> On 10/31/2011 03:52 PM, Linus Torvalds wrote:\n>>\n>> Save it in the commit we generate. BAM! Useful, readable, permanent,\n>> and independently verifiable.\n>>\n>\n> Note: this means creating a commit even for a fast-forward merge.  Not\n> that there is any technical problem with that, of course.\n\nWell, only for the signed case, but yes. And for that case it's likely\na good thing.\n\nIn fact, even without signing, some projects always use --no-ff,\nbecause they want the merge messages with the nice summary in them.\nI've played around with it too, but haven't generally found it to be\nworth it, and tend to think that it aggrandizes the merger too much.\n\nIt generates nice merge summaries, and it can look nice, but if the\n*only* upside is the merge summary I think it's borderline worth it.\nBut with a signature, it would suddenly actually contain real\ninformation, and I think that changes the equation.\n\n Linus\n"},{"id":"178600","messageId":"7vlis0oj1m.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"7vvcr4ojvp.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-10-31T23:09:09Z","receivedAt":"2011-10-31T23:09:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Linus Torvalds writes:\n> ...\n> As I already said, I do not think notes is a good match as a tool to do\n> this.\n>\n>> matters is that \"git push\" and \"git pull\" would JustWork(tm), and\n>> check the signature if one exists, without having to cut-and-paste\n>> data that simply shouldn't be visible to the user.\n>>\n>> I abhor the interface Ingo suggested, for example....\n>\n> Some cut-and-paste (or piping the e-mail to a command) would be necessary\n> evil, though, as you would have GPG keys from more than one trusted person\n> in your keyring, and when you are responding to a pull-request from person\n> A, finding a valid commit signed by person B should not be a success, but\n> at least should raise a warning.\n\nSo here is a quick hack that does not involve cut-and-paste (it depends on\nthe signed-commit topic in 'next').\n\n $ git pull --require-signature\n\nwould trigger signature verification and stops you after fetching but\nbefore merging.\n\n git-pull.sh | 25 ++++++++++++++++++++++++-\n 1 files changed, 24 insertions(+), 1 deletions(-)\n\ndiff --git a/git-pull.sh b/git-pull.sh\nindex 9868a0b..f3b4c93 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -39,7 +39,7 @@ test -z \"$(git ls-files -u)\" || die_conflict\n test -f \"$GIT_DIR/MERGE_HEAD\" && die_merge\n \n strategy_args= diffstat= no_commit= squash= no_ff= ff_only=\n-log_arg= verbosity= progress= recurse_submodules=\n+log_arg= verbosity= progress= recurse_submodules= must_be_signed=\n merge_args=\n curr_branch=$(git symbolic-ref -q HEAD)\n curr_branch_short=\"${curr_branch#refs/heads/}\"\n@@ -60,6 +60,8 @@ do\n \t\tdiffstat=--no-stat ;;\n \t--stat|--summary)\n \t\tdiffstat=--stat ;;\n+\t--require-signature)\n+\t\tmust_be_signed=yes ;;\n \t--log|--no-log)\n \t\tlog_arg=$1 ;;\n \t--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)\n@@ -208,6 +210,27 @@ orig_head=$(git rev-parse -q --verify HEAD)\n git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok \"$@\" || exit 1\n test -z \"$dry_run\" || exit 0\n \n+if test -n \"$must_be_signed\"\n+then\n+\tsignature=$(git show -s --format='%G?' FETCH_HEAD)\n+\tcase \"$signature\" in\n+\tG)\n+\t\tcase \"$verbosity\" in\n+\t\t*' '-v*)\n+\t\t\tgit show -s --show-signature FETCH_HEAD ;;\n+\t\tesac\n+\t\t;;\n+\tB)\n+\t\techo >&2 \"Bad signature on the tip commit\"\n+\t\texit 1\n+\t\t;;\n+\t*)\n+\t\techo >&2 \"Tip commit must be signed\"\n+\t\texit 1\n+\t\t;;\n+\tfi\n+fi\n+\n curr_head=$(git rev-parse -q --verify HEAD)\n if test -n \"$orig_head\" && test \"$curr_head\" != \"$orig_head\"\n then\n"},{"id":"178603","messageId":"4EAF3556.3000001@garzik.org","threadId":"28805","inReplyTo":"7vzkggok6u.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Jeff Garzik","fromEmail":"jeff@garzik.org","sentAt":"2011-10-31T23:55:02Z","receivedAt":"2011-10-31T23:55:02Z","isPatch":false,"sender":{"key":"jeff@garzik.org","avatar":null},"body":"On 10/31/2011 06:44 PM, Junio C Hamano wrote:\n> \"H. Peter Anvin\" writes:\n>\n>> On 10/31/2011 03:30 PM, Linus Torvalds wrote:\n>>>\n>>> But if you do the normal \"git pull git://git.kernel.org/name/of/repo\"\n>>> - which is how things happen as a result of a pull request - you won't\n>>> get tags at all - you have to ask for them by name or use \"--tags\" to\n>>> get them all.\n>>>\n>>\n>> Didn't realize that... I guess I'm too used to named remotes.\n>>\n>> If so, just using a tag should be fine, no?\n>\n> So nobody is worried about this (quoting from my earlier message)?\n>\n> On the other hand, the consumers of \"Linus kernel\" may want to say that\n> they trust your tree and your tags because they can verify them with your\n> GPG signature, but also they can independently verify the lieutenants'\n> trees you pulled from are genuine.\n>\n> A signed emphemeral tag is usable as means to verify authenticity in a\n> hop-by-hop fashion, but that does not leave a permanent trail that can be\n> used for auditing.\n\nThe main worry is Linus ($human_who_pulls) gets \ncryptographically-verified data at the time he pulls. Once Linus \nrepublishes his tree (git push), there will be few, if any, wanting to \nverify Jeff Garzik's signature.\n\nSo no, I don't see that as a _driving_ need in the kernel's case.\n\nAnd IMO the kernel will be a mix of signed and unsigned content for a \nwhile, possibly forever.\n\n\nAnd Linus wrote:\n> [ Example gpg-signed small block that the attached patch adds to the\n> pull request: ]\n>\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA1\n>\n> Commit be3fa9125e708348c7baf04ebe9507a72a9d1800\n> from git.kernel.org/pub/git\n> -----BEGIN PGP SIGNATURE-----\n> Version: GnuPG v2.0.18 (GNU/Linux)\n>\n> iQEcBAEBAgAGBQJOrsILAAoJEHm+PkMAQRiGxZcH/31e0RrBitXUPKxHJajD58yh\n> SIEe/7i6E2RUSFva3KybEuFslcR8p8DYzDQTPLejStvnkO8v0lXu9s9R53tvjLMF\n> aaQXLOgrOC2RqvzP4F27O972h32YpLBkwIdWQGAhYcUOdKYDZ9RfgEgtdJwSYuL+\n> oJ7TjLrtkcILaFmr9nYZC+0Fh7z+84R8kR53v0iBHJQOFfssuMjUWCoj9aEY12t+\n> pywXuVk2FsuYvhniCAcyU6Y1K9aXaf6w5iOY2hx/ysXtUBnv92F7lcathxQkvgjO\n> fA7/TXEcummOv5KQFc9vckd5Z1gN2ync5jhfnmlT2uiobE6mNdCbOVlCOpsKQkU=\n> =l5PG\n> -----END PGP SIGNATURE-----\n\n\nThis is my preference for kernel pull requests at the moment. That has \none advantage over Junio's \"git pull --require-signature\" and signed \ncommits, notably, the URL is signed.\n\nBut in general signed commits would be nice, too. pull-generated merge \nrequests would need to be signed, potentially introducing an additional \ninteractive step (GPG passphrase request) into an automated process.\n\n\tJeff\n"},{"id":"178606","messageId":"4EAF4091.2010205@zytor.com","threadId":"28805","inReplyTo":"4EAF3556.3000001@garzik.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2011-11-01T00:42:57Z","receivedAt":"2011-11-01T00:42:57Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"> \n> The main worry is Linus ($human_who_pulls) gets\n> cryptographically-verified data at the time he pulls. Once Linus\n> republishes his tree (git push), there will be few, if any, wanting to\n> verify Jeff Garzik's signature.\n> \n> So no, I don't see that as a _driving_ need in the kernel's case.\n> \n> And IMO the kernel will be a mix of signed and unsigned content for a\n> while, possibly forever.\n> \n\nI think the desire is to be able to deconstruct things if things were to\ngo wrong.\n\n\t-hpa\n\n-- \nH. Peter Anvin, Intel Open Source Technology Center\nI work for Intel. I don't speak on their behalf.\n\n"},{"id":"178613","messageId":"1320125941.7701.14.camel@dabdike","threadId":"28805","inReplyTo":"CA+55aFwnVZ-mK3FChvFn778Z-cT107f4v-h0CDmwkP88=Z9aHA@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"James Bottomley","fromEmail":"james.bottomley@hansenpartnership.com","sentAt":"2011-11-01T05:39:01Z","receivedAt":"2011-11-01T05:39:01Z","isPatch":false,"sender":{"key":"james.bottomley@hansenpartnership.com","avatar":"https://gravatar.com/avatar/5f93022e9a8d12d6779c93c6e7c14f455b4a0183229a0a5e6974b7fb7f8d7bcb?d=mp&s=160"},"body":"On Mon, 2011-10-31 at 15:52 -0700, Linus Torvalds wrote:\n> On Mon, Oct 31, 2011 at 3:44 PM, Junio C Hamano wrote:\n> >\n> > So nobody is worried about this (quoting from my earlier message)?\n> \n> No, because you haven't been reading what we write.\n> \n> The tag is useless.\n\nIt's not useless to people who want to verify the tree after it's been\nreleased by you (say for forensics or something). As Peter said, we can\nput it in a normally invisible namespace, but having a flag to make it\nvisible allows tools like git describe --contains to tell me which\nsigned tag was used to send a particular commit.\n\n> The information *in* the tag is not. But it shouldn't be saved in the\n> tag (or note, or whatever). Because that's just an annoying place for\n> it to be, with no upside.\n> \n> Save it in the commit we generate. BAM! Useful, readable, permanent,\n> and independently verifiable.\n> \n> And the advantage is that we can make that same mechanism add\n> \"maintainer notes\" to the merge message too. Right now some\n> maintainers write good notes about what the merge will bring in, but\n> they are basically lost, because git is so good at merging and doesn't\n> even stop to ask people to edit the merge message.\n\nA signed empty commit containing the merge message as a comment also\nlooks fine to me. We'd need extra tooling to say which signed merge\ncorresponds to this patch, but I'd say its workable. The only slightly\ncounter intuitive thing is that for a non-trivial merge, my signed merge\ndescription will have to be the next commit below rather than in the\nactual merge you do (because we can't alter a cryptographically signed\ncommit).\n\nJames\n\n\n"},{"id":"178638","messageId":"7vwrbjlj5r.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"CA+55aFwL_s=DcT46dprcYVWEAm_=WkuTV6K9dAn3wc_bDQU8vA@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-01T19:47:12Z","receivedAt":"2011-11-01T19:47:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> But what would be nice is that \"git pull\" would fetch the tag (based on\n> name) *automatically*, and not actually create a tag in my repository at\n> all. Instead, if would use the tag to check the signature, and - if we\n> do this right - also use the tag contents to populate the merge commit\n> message.\n>\n> In other words, no actual tag would ever be left around as a turd, it\n> would simply be used as an automatic communication channel between the\n> \"git push -s\" of the submitter and my subsequent \"git pull\". Neither\n> side would have to do anything special, and the tag would never show\n> up in any relevant tree (it could even be in a totally separate\n> namespace like \"refs/pullmarker/\" or something).\n\nWhile I like the \"an ephemeral tag is used only for hop-to-hop\ncommunication to carry information to be recorded in the resulting\nhistory\" approach, I see a few downsides.\n\n * The ephemeral tag needs to stay somewhere under refs/ hierarchy of the\n lieutenant's tree until you pick it up, even if they are out of the way\n in refs/pullmarker/$branchname. The next time the same lieutenant makes\n a pull request, either it will be overwritten or multiple versions of\n them refs/pullmarker/$branchname/$serial need to be kept.\n\n - If the former, this makes forking of the project harder. Suppose a\n pull request is made, you fetch and reject it. The lieutenant reworks\n and makes another pull request. At this point the earlier signature\n is gone. If somebody disagreed with your rejection and wanted to run\n his tree with the initial version you rejected, his tree will not\n carry the signature from the lieutenant.\n\n - If the latter, then there needs to be a way to expire these pull\n markers when they no longer are useful (i.e. the signature in it is\n transcribed to a merge commit you create) [*1*]. But the party who\n has power to clean them (i.e. the lieutenant who owns the repository)\n is different from the party whose action determines when they no\n longer are necessary (i.e. you). In practice this would lead to these\n pull markers not cleaned at all [*2*].\n\n * To verify the commit C that was taken from the tip of lieutenant's tree\n some time ago, one has to find the merge commit that has C as a parent,\n and look at the merge commit. For example \"git log --show-signature\"\n would either show or not show the authenticity of C depending on where\n the traversal comes from. You certainly can implement it that way, but\n \"some child describes an aspect of its parent, but not necessarily all\n children do so\" feels philosophically less correct than \"the commit has\n data to describe itself\".\n\nIn your \"ephemeral tag\", the workflow for a developer (D) and his\nintegrator (U) would look like this, I think.\n\n D$ until have something worth sending; do work; done\n D$ git push -s\n Enter passphrase: ...\n\t- \"push\" internally creates a pull marker that signs the commit\n object name this is pushing, among other things, and sends it\n along the primary payload\n D$ git pull-request; mail linus\n\n U$ git pull\n \t- \"pull\" notices the pull marker and fetches it as well;\n - \"pull\" GPG validates the pull marker;\n - When preparing a merge commit message, the contents of the\n pull marker is included in .git/MERGE_MSG\n\nThe \"in-commit signature\" would give you 100% and your contributors 98% of\nthat, I think.\n\n D$ until have something worth sending; do work; done\n - The final round of reworking is concluded with \"commit -S\",\n which would GPG sign the tip commit itself\n D$ git push\n\t- Nothing needs to change in the protocol nor \"push\" itself\n D$ git pull-request; mail linus\n\n U$ git pull\n \t- \"pull\" GPG validates the tip commit\n\t- Nothing unusual needs to happen to the resulting \"merge\" commit\n\nAnd as a bonus, the code is already there ;-).\n\n\n[Footnote]\n\n*1* The common ancestor discovery in fetch uses as many refs as it can to\nreduce the amount of data that needs to be transferred, and it is known to\nhurt performance of the initial advertisement exchange when there are too\nmany useless refs.\n\n*2* Do casual git users even know how to remove refs in a\nremote/publishing repository?\n"},{"id":"178649","messageId":"CA+55aFx_rAA6TJkZn1Zvu6u9UjxnmTVt0HpMnvaE_q9Sx-jzPg@mail.gmail.com","threadId":"28805","inReplyTo":"7vwrbjlj5r.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-11-01T21:21:59Z","receivedAt":"2011-11-01T21:21:59Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Tue, Nov 1, 2011 at 12:47 PM, Junio C Hamano wrote:\n>\n> While I like the \"an ephemeral tag is used only for hop-to-hop\n> communication to carry information to be recorded in the resulting\n> history\" approach, I see a few downsides.\n\nSo I do agree.\n\nI'd actually be *happier* with a generic multi-line \"branch\ndescription\" thing that involves no git objects at all, just a nice\ndescription of what the branch is.\n\nThe fact that you could also hide a signed version of the\ntop-of-branch there would be kind of a side effect, and wouldn't be a\nrequirement.\n\nI hate how anonymous our branches are. Sure, we can use good names for\nthem, but it was a mistake to think we should describe the repository\n(for gitweb), rather than the branch.\n\nOk, \"hate\" is a strong word. I don't \"hate\" it. I don't even think\nit's a major design issue. But I do think that it would have been\nnicer if we had had some branch description model.\n\nThe only reason I suggest a tag is really because it would fit with\nexisting tooling - especially the git transport protocol. So it's not\nthat I actually think that a tag is the right way to describe (and\nsign) the branch, it's just that it's the way that wouldn't require\nany changes other than in \"git push -s\" and \"git pull\".\n\n>  * To verify the commit C that was taken from the tip of lieutenant's tree\n>   some time ago, one has to find the merge commit that has C as a parent,\n>   and look at the merge commit.  For example \"git log --show-signature\"\n>   would either show or not show the authenticity of C depending on where\n>   the traversal comes from. You certainly can implement it that way, but\n>   \"some child describes an aspect of its parent, but not necessarily all\n>   children do so\" feels philosophically less correct than \"the commit has\n>   data to describe itself\".\n\nYeah.\n\nHaving thought about it, I'm also not convinced I really want to\npollute the \"git log\" output with information that realistically\nalmost nobody cares about. The primary use is just for the person who\npulls things to verify it, after that the information is largely stale\nand almost certain to never be interesting to anybody ever again. It's\n*theoretically* useful if somebody wants to go back and re-verify, but\nat the same time that really isn't expected to be the common case.\n\nSo I'm wondering if we want to save it at all. it's quite possible\nthat realistically speaking \"google the mailing list archives\" is the\n*right* way to look up the signature if it is ever needed later.\n\nMaybe just verifying the email message (with the suggested kind of\nchange to \"git request-pull\") is actually the right approach. And what\nI should do is to just wrap my \"git pull\" in some script that I can\njust cut-and-paste the gpg-signed thing into, and which just does the\n\"gpg --verify\" on it, and then does the \"git pull\" after that.\n\nBecause in many ways, \"git request-pull\" is when you do want to sign\nstuff. A developer might well want to push out his stuff for some\nrandom internal testing (linux-next, for example), and then only later\ndecide \"Ok, it was all good, now I want to make it 'official' and ask\nLinus to pull it\", and sign it at *that* time, rather than when\nactually pushing it out.\n\nAnd I suspect signing the pull request fits better into peoples\nexisting workflow anyway - sending out the email to ask the maintainer\nto pull really is the \"special event\", rather than pushing out the\ncode itself.\n\n Linus\n"},{"id":"178652","messageId":"7vk47jld5s.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"CA+55aFx_rAA6TJkZn1Zvu6u9UjxnmTVt0HpMnvaE_q9Sx-jzPg@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-01T21:56:47Z","receivedAt":"2011-11-01T21:56:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Having thought about it, I'm also not convinced I really want to\n> pollute the \"git log\" output with information that realistically\n> almost nobody cares about. The primary use is just for the person who\n> pulls things to verify it, after that the information is largely stale\n> and almost certain to never be interesting to anybody ever again. It's\n> *theoretically* useful if somebody wants to go back and re-verify, but\n> at the same time that really isn't expected to be the common case.\n> ...\n> So I'm wondering if we want to save it at all. it's quite possible\n> that realistically speaking \"google the mailing list archives\" is the\n> *right* way to look up the signature if it is ever needed later.\n\nI'd rather want to hear opinions from people who base their work on public\nkernels (e.g. distros, and companies who roll their own prod kernels), on\nthat.\n\nBut my gut feeling is that \"usually hidden not to disturb normal users,\nbut is cast in stone in the history and cannot be lost\" strikes the right\nbalance. Both your \"next merge commit records the signature together with\nthe largely useless merge summary cruft but everybody learned to ignore it\nwith 'log --no-merges' anyway so it does not hurt to have it there\" and\nthe commit signature topic from the next branch [*1*] that puts the\nsignature in the object header and teaches '--show-signature' option to\nthe log family to show it share this property.\n\n> Maybe just verifying the email message (with the suggested kind of\n> change to \"git request-pull\") is actually the right approach. And what\n> I should do is to just wrap my \"git pull\" in some script that I can\n> just cut-and-paste the gpg-signed thing into, and which just does the\n> \"gpg --verify\" on it, and then does the \"git pull\" after that.\n>\n> Because in many ways, \"git request-pull\" is when you do want to sign\n> stuff. A developer might well want to push out his stuff for some\n> random internal testing (linux-next, for example), and then only later\n> decide \"Ok, it was all good, now I want to make it 'official' and ask\n> Linus to pull it\", and sign it at *that* time, rather than when\n> actually pushing it out.\n>\n> And I suspect signing the pull request fits better into peoples\n> existing workflow anyway - sending out the email to ask the maintainer\n> to pull really is the \"special event\", rather than pushing out the\n> code itself.\n\n\"I can silently push and re-push or even rewind-and-then-push until I\nofficially send pull-request out\" fits well with the \"defer the decision\nas much as possible\" model Git takes in general, and I find certain\nattractiveness in it.\n\nBut on the other hand, in many ways, publishing your commit to the outside\nworld, not necessarily for getting pulled into the final destination\n(i.e. your tree) but merely for other people to try it out, is the point\nof no return (aka \"don't rewind or rebase once you publish\"). \"pushing\nout\" might be less special than \"please pull\", but it still is special.\n\nAlso there is nothing lost if you sign commits whenever you push them\nout.\n\n\n[Footnote]\n\n*1* Here are three examples on the same commit that is signed for\nillustration.\n\n------------------------------------------------\n$ git show -s pu\ncommit c9d870fceac787fdb1c1c43b136c1a94ab2ab005\nMerge: 8367c51 71f45ee\nAuthor: Junio C Hamano \nDate: Mon Oct 31 20:06:58 2011 -0700\n\n Merge branch 'jc/stream-to-pack' into pu\n \n * jc/stream-to-pack:\n Bulk check-in\n finish_tmp_packfile(): a helper function\n create_tmp_packfile(): a helper function\n write_pack_header(): a helper function\n------------------------------------------------\n$ git show -s --show-signature pu\ncommit c9d870fceac787fdb1c1c43b136c1a94ab2ab005\ngpg: Signature made Mon 31 Oct 2011 08:07:04 PM PDT using RSA key ID 96AFE6CB\ngpg: Good signature from \"Junio C Hamano \"\ngpg: aka \"Junio C Hamano \"\ngpg: aka \"Junio C Hamano \"\nMerge: 8367c51 71f45ee\nAuthor: Junio C Hamano \nDate: Mon Oct 31 20:06:58 2011 -0700\n\n Merge branch 'jc/stream-to-pack' into pu\n \n * jc/stream-to-pack:\n Bulk check-in\n finish_tmp_packfile(): a helper function\n create_tmp_packfile(): a helper function\n write_pack_header(): a helper function\n------------------------------------------------\n$ git cat-file commit pu\ntree 9add290d468800c3c51ff68fedfb3d16427872ff\nparent 8367c51becc5a225b9a192348b7d7c615fb6d250\nparent 71f45eeb8278670257bea83620f7d3eac174eee7\nauthor Junio C Hamano 1320116818 -0700\ncommitter Junio C Hamano 1320116824 -0700\ngpgsig -----BEGIN PGP SIGNATURE-----\ngpgsig Version: GnuPG v1.4.10 (GNU/Linux)\ngpgsig \ngpgsig ...\ngpgsig =c62U\ngpgsig -----END PGP SIGNATURE-----\n\nMerge branch 'jc/stream-to-pack' into pu\n\n* jc/stream-to-pack:\n Bulk check-in\n finish_tmp_packfile(): a helper function\n create_tmp_packfile(): a helper function\n write_pack_header(): a helper function\n------------------------------------------------\n"},{"id":"178658","messageId":"20111101223917.GG32161@thunk.org","threadId":"28805","inReplyTo":"CA+55aFx_rAA6TJkZn1Zvu6u9UjxnmTVt0HpMnvaE_q9Sx-jzPg@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Ted Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2011-11-01T22:39:17Z","receivedAt":"2011-11-01T22:39:17Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Nov 01, 2011 at 02:21:59PM -0700, Linus Torvalds wrote:\n> So I'm wondering if we want to save it at all. it's quite possible\n> that realistically speaking \"google the mailing list archives\" is the\n> *right* way to look up the signature if it is ever needed later.\n\nGiven the number of trees that you merge in every merge window (never\nmind over an entire release), I don't think \"google the mailing list\narchives\" is going to scale. Finding some way to keep it along with\nthe merge window seems the right thing. I agree that it should hidden\nnormally, but that's a UI display issue. Heck, we could just hide\nafter the terminating NULL in the commit description, per a discussion\non the git list 2-3 weeks ago. :-)\n\n> Because in many ways, \"git request-pull\" is when you do want to sign\n> stuff. A developer might well want to push out his stuff for some\n> random internal testing (linux-next, for example), and then only later\n> decide \"Ok, it was all good, now I want to make it 'official' and ask\n> Linus to pull it\", and sign it at *that* time, rather than when\n> actually pushing it out.\n\nSure, the signed content should be buried in the commit that it\ndescribes. Whether we carry it in an emphemeral tag or in the git\nrequest-pull is not really important from a security perspective. The\ntag is nicer simply because the person doing the pull won't need to\ncut and paste the signature information.\n\nOne approach which might work is if git request-pull sends the e-mail\nmessage with the git shortlog and diffstat, *and* an MIME attachment\nthat contained all of the necessary information. The maintainer would\nthen save the attachment, and feed it to git, which will display the\ngit shortlog and diffstat, ask for confirmation, and then embed the\ndigital signature into the merge commit.\n\nThe only problem with that is (a) you'd have to get over your hatred\nof attachment (but if you're using Gmail hopefully that's relative\nconvenient :-), and (b) LKML list filter would have to be taught to\ntolerate git-generated attachments.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"178673","messageId":"20111102091126.GG18903@elte.hu","threadId":"28805","inReplyTo":"CA+55aFyKWLUMQFfaeKJKGFPV_7kfOGjf+pSZ1Y8afzkT4OYQ9Q@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2011-11-02T09:11:26Z","receivedAt":"2011-11-02T09:11:26Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Linus Torvalds wrote:\n\n> And the receiving side would just do the \"git pull\" and \n> automatically just get notified that \"Yes, this push has been \n> signed by key Xyz Abcdef\"\n\nIf this approach is used then it would be nice to have a .gitconfig \nswitch to require trusted pulls by default: to not allow doing \nnon-signed or untrusted pulls accidentally, or for Git to warn in a \nvisible, hard to miss way if there's a non-signed pull.\n\nThis adds social uncertainty (and an element of a silent alarm) to a \nrealistic attack: the attacker wouldnt know exactly how the puller \nchecks signed pull requests, it's kept private.\n\nThanks,\n\n\tIngo\n"},{"id":"178682","messageId":"4EB12122.7010803@drmicha.warpmail.net","threadId":"28805","inReplyTo":"7vwrbjlj5r.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-11-02T10:53:22Z","receivedAt":"2011-11-02T10:53:22Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 01.11.2011 20:47:\n> Linus Torvalds writes:\n> \n>> But what would be nice is that \"git pull\" would fetch the tag (based on\n>> name) *automatically*, and not actually create a tag in my repository at\n>> all. Instead, if would use the tag to check the signature, and - if we\n>> do this right - also use the tag contents to populate the merge commit\n>> message.\n>>\n>> In other words, no actual tag would ever be left around as a turd, it\n>> would simply be used as an automatic communication channel between the\n>> \"git push -s\" of the submitter and my subsequent \"git pull\". Neither\n>> side would have to do anything special, and the tag would never show\n>> up in any relevant tree (it could even be in a totally separate\n>> namespace like \"refs/pullmarker/\" or something).\n> \n> While I like the \"an ephemeral tag is used only for hop-to-hop\n> communication to carry information to be recorded in the resulting\n> history\" approach, I see a few downsides.\n> \n> * The ephemeral tag needs to stay somewhere under refs/ hierarchy of the\n> lieutenant's tree until you pick it up, even if they are out of the way\n> in refs/pullmarker/$branchname. The next time the same lieutenant makes\n> a pull request, either it will be overwritten or multiple versions of\n> them refs/pullmarker/$branchname/$serial need to be kept.\n\nIf we are interested in commit sigs, the easiest tag-based approach is\nto name the sig carrying tag by the commit's sha1. Just like the sig is\ntied (in)to a commit in Junio's approach, it would be indexed by it. We\ncan do that now:\n\ngit config --global alias.sign '!f() { c=$(git rev-parse \"$1\") || exit;\nshift; git tag -s $@ sigs/$c $c; }; f'\n\nBut a different place rather than refs/tags/sigs/ will be more\nappropriate, so that we don't pollute the tag namespace. (Yes, this is\nsimilar to storing them in notes.) tags have a message etc.\n\nWith an appropriate refspec, these sigs can be pushed out automatically\n(by the lieutenant).\n\npull-request as in next will list the expected at tip.\n\ngit pull needs to learn to (fetch and) use refs// to\nverify that the tip is signed.\n\ngit log --show-signature can do the same tricks as with in-commit sigs.\n\nSome things to decide in this approach:\n- Should git-pull (pull sigs and) verify by default?\n- Should we worry about overwriting existings sigs? We have union-merge\nfor notes already, and that would be appropriate for sigs. (Yes, our\ntags code does verify multiple concatenated sigs.)\n\nThe advantage of tags is that they can be added without rewriting the\ncommit, of course.\n\nMichael\n"},{"id":"178683","messageId":"20111102112018.GF17259@pompeji.miese-zwerge.org","threadId":"28805","inReplyTo":"20111102091126.GG18903@elte.hu","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Jochen Striepe","fromEmail":"jochen@tolot.escape.de","sentAt":"2011-11-02T11:20:18Z","receivedAt":"2011-11-02T11:20:18Z","isPatch":false,"sender":{"key":"jochen@tolot.escape.de","avatar":null},"body":"\tHi,\n\nOn Wed, Nov 02, 2011 at 10:11:26AM +0100, Ingo Molnar wrote:\n> If this approach is used then it would be nice to have a .gitconfig \n> switch to require trusted pulls by default: to not allow doing \n> non-signed or untrusted pulls accidentally, or for Git to warn in a \n> visible, hard to miss way if there's a non-signed pull.\n> \n> This adds social uncertainty (and an element of a silent alarm) to a \n> realistic attack: the attacker wouldnt know exactly how the puller \n> checks signed pull requests, it's kept private.\n\nBut that way you get a false sense of alarm when someone sent a\nperfectly trustable pull request, e.g. by signed email.\n\n\nAnother question: If store the actual pgp/gpg signatures in the git tree,\nhow do you handle signatures by keys which were valid by the time the\nsignature was made but expired when checking some time afterwards? AFAICT,\ngpg will only tell you the key is expired _now_, and will make no statement\nregarding the time the actual signature was made.\n\n\nThanks,\nJochen.\n"},{"id":"178708","messageId":"7v1utqjqre.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"4EB12122.7010803@drmicha.warpmail.net","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-02T18:58:13Z","receivedAt":"2011-11-02T18:58:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> The advantage of tags is that they can be added without rewriting the\n> commit, of course.\n\nAnd you did neither think about the downsides of tags, nor read what\nothers already explained for you?\n"},{"id":"178713","messageId":"CA+55aFz7TeQQH3D4Tpp31cZYZoQKeK37jouo+2Kh61Wa07knfw@mail.gmail.com","threadId":"28805","inReplyTo":"7vk47jld5s.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-11-02T20:04:30Z","receivedAt":"2011-11-02T20:04:30Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Tue, Nov 1, 2011 at 2:56 PM, Junio C Hamano wrote:\n>\n> But on the other hand, in many ways, publishing your commit to the outside\n> world, not necessarily for getting pulled into the final destination\n> (i.e. your tree) but merely for other people to try it out, is the point\n> of no return (aka \"don't rewind or rebase once you publish\").  \"pushing\n> out\" might be less special than \"please pull\", but it still is special.\n\nSo I really think that signing the top commit itself is fundamentally wrong.\n\nThat commit may not even be *yours*. You may have pulled it from a\nsub-lieutenant as a fast-forward, or similar. Amending it later would\nbe actively very very *wrong*.\n\nSo quite frankly, I think the stuff in pu (or next?) is completely\nmis-designed. Doing it in the commit is wrong for fundamental reasons,\nwhich all boil down to a simple issue:\n\n - you absolutely *need* to add the signature later. You *cannot* do\nit at \"git commit\" time.\n\nThat's a fundamental issue both from a \"workflow model\" issue (ie you\nwant to sign stuff after it has passed testing etc, but you may need\nto commit it in order to *get* testing), as well as from a\n\"fundamental git datastructures\" issue (ie you would want to sign\ncommits that aren't yours.\n\n\"git commit --amend\" is not the answer - that destroys the fundamental\nconcept of history being immutable, and while it works for your local\ncommits, it doesn't work for anybody elses commits, or for stuff you\nalready pushed out.\n\nAnd \"add a fake empty commit just for the signature\" is not the answer\neither - because that is clearly inferior to the tags we already had.\n\nI dunno. Did I miss something? As far as I can tell, the signed tags\nthat we've had since day one are *clearly* much better in very\nfundamental ways.\n\n Linus\n"},{"id":"178722","messageId":"4EB1B099.5030701@drmicha.warpmail.net","threadId":"28805","inReplyTo":"7v1utqjqre.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-11-02T21:05:29Z","receivedAt":"2011-11-02T21:05:29Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 02.11.2011 19:58:\n> Michael J Gruber writes:\n> \n>> The advantage of tags is that they can be added without rewriting the\n>> commit, of course.\n> \n> And you did neither think about the downsides of tags, nor read what\n> others already explained for you?\n\nWe're just weighing things differently here, and no accusations of\n\"misinformation\" or \"not thinking\" will change this.\n"},{"id":"178723","messageId":"7vipn2i5xl.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"CA+55aFz7TeQQH3D4Tpp31cZYZoQKeK37jouo+2Kh61Wa07knfw@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-02T21:13:26Z","receivedAt":"2011-11-02T21:13:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> And \"add a fake empty commit just for the signature\" is not the answer\n> either - because that is clearly inferior to the tags we already had.\n>\n> I dunno. Did I miss something? As far as I can tell, the signed tags\n> that we've had since day one are *clearly* much better in very\n> fundamental ways.\n\nOk, back to the drawing board (which is not a loss as I wasn't expecting\nthis to be in the official release in upcoming 1.7.8 anyway).\n"},{"id":"178735","messageId":"7vsjm6gkte.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"CA+55aFx_rAA6TJkZn1Zvu6u9UjxnmTVt0HpMnvaE_q9Sx-jzPg@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-02T23:34:53Z","receivedAt":"2011-11-02T23:34:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> I hate how anonymous our branches are. Sure, we can use good names for\n> them, but it was a mistake to think we should describe the repository\n> (for gitweb), rather than the branch.\n>\n> Ok, \"hate\" is a strong word. I don't \"hate\" it. I don't even think\n> it's a major design issue. But I do think that it would have been\n> nicer if we had had some branch description model.\n> ...\n> Maybe just verifying the email message (with the suggested kind of\n> change to \"git request-pull\") is actually the right approach. And what\n> I should do is to just wrap my \"git pull\" in some script that I can\n> just cut-and-paste the gpg-signed thing into, and which just does the\n> \"gpg --verify\" on it, and then does the \"git pull\" after that.\n>\n> Because in many ways, \"git request-pull\" is when you do want to sign\n> stuff. A developer might well want to push out his stuff for some\n> random internal testing (linux-next, for example), and then only later\n> decide \"Ok, it was all good, now I want to make it 'official' and ask\n> Linus to pull it\", and sign it at *that* time, rather than when\n> actually pushing it out.\n\nYou keep saying cut-and-paste, but do you mind feeding the e-mail text\nitself to a tool, instead of cut-and-paste?\n\nThe reason I am wondering about this is because in another topic (also in\n'next') cooking there is an extended support for topic description for the\nbranch that states what the purpose of the topic is why the requestor\nwants you to have it (this information can be set and updated with \"git\nbranch --edit-description\").\n\nA respond-to-request-pull wrapper you would use could be:\n\n - Get the e-mail from the standard input;\n - Pick up the signed bits and validate the signature;\n - Perform the requested fetch; and\n - Record the merge (or prepare .git/MERGE_MSG) with both the signed bits.\n\nand the \"signed bits\" could include:\n\n - the repository and the branch you were expected to pull;\n - the topic description.\n\namong other things the requestor can edit when request-pull message is\nprepared.\n\nThat would get us back to your \"the lieutenant tip is not so special, but\nthe merge commit the integrator makes using that tip has the signature for\nthis particular pull\" model.\n"},{"id":"178738","messageId":"alpine.DEB.2.02.1111021640340.20915@asgard.lang.hm","threadId":"28805","inReplyTo":"7vsjm6gkte.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"","fromEmail":"david@lang.hm","sentAt":"2011-11-02T23:41:55Z","receivedAt":"2011-11-02T23:41:55Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Wed, 2 Nov 2011, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n>\n>> I hate how anonymous our branches are. Sure, we can use good names for\n>> them, but it was a mistake to think we should describe the repository\n>> (for gitweb), rather than the branch.\n>>\n>> Ok, \"hate\" is a strong word. I don't \"hate\" it. I don't even think\n>> it's a major design issue. But I do think that it would have been\n>> nicer if we had had some branch description model.\n>> ...\n>> Maybe just verifying the email message (with the suggested kind of\n>> change to \"git request-pull\") is actually the right approach. And what\n>> I should do is to just wrap my \"git pull\" in some script that I can\n>> just cut-and-paste the gpg-signed thing into, and which just does the\n>> \"gpg --verify\" on it, and then does the \"git pull\" after that.\n>>\n>> Because in many ways, \"git request-pull\" is when you do want to sign\n>> stuff. A developer might well want to push out his stuff for some\n>> random internal testing (linux-next, for example), and then only later\n>> decide \"Ok, it was all good, now I want to make it 'official' and ask\n>> Linus to pull it\", and sign it at *that* time, rather than when\n>> actually pushing it out.\n>\n> You keep saying cut-and-paste, but do you mind feeding the e-mail text\n> itself to a tool, instead of cut-and-paste?\n\nthink webmail (i.e. gmail), to feed the e-mail itself to a tool you either \nneed to cut-n-paste the entire e-mail or you have to first save the mail \nto a text file. both of which are significantly harder than doing a \ncut-n-past of a portion of the message.\n\nDavid Lang\n\n> The reason I am wondering about this is because in another topic (also in\n> 'next') cooking there is an extended support for topic description for the\n> branch that states what the purpose of the topic is why the requestor\n> wants you to have it (this information can be set and updated with \"git\n> branch --edit-description\").\n>\n> A respond-to-request-pull wrapper you would use could be:\n>\n> - Get the e-mail from the standard input;\n> - Pick up the signed bits and validate the signature;\n> - Perform the requested fetch; and\n> - Record the merge (or prepare .git/MERGE_MSG) with both the signed bits.\n>\n> and the \"signed bits\" could include:\n>\n> - the repository and the branch you were expected to pull;\n> - the topic description.\n>\n> among other things the requestor can edit when request-pull message is\n> prepared.\n>\n> That would get us back to your \"the lieutenant tip is not so special, but\n> the merge commit the integrator makes using that tip has the signature for\n> this particular pull\" model.\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":"178739","messageId":"CA+55aFxeMgpVDPJ1aEza5oeKYhBTbbZQ4wdjVG-t8MFBjuOK7w@mail.gmail.com","threadId":"28805","inReplyTo":"7vsjm6gkte.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-11-02T23:42:22Z","receivedAt":"2011-11-02T23:42:22Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Wed, Nov 2, 2011 at 4:34 PM, Junio C Hamano wrote:\n>\n> You keep saying cut-and-paste, but do you mind feeding the e-mail text\n> itself to a tool, instead of cut-and-paste?\n\nFeeding the email to a tool is actually a fair amount of extra work.\nIt would have worked well in the days when I used text-based email\nclients that just had a \"pipe email to command\" model, but that's long\ngone.\n\nIn contrast, cut-and-paste to another program is easy - but then you\nreally can't depend on whitespace or headers or other subtle things.\n\n> A respond-to-request-pull wrapper you would use could be:\n>\n>  - Get the e-mail from the standard input;\n>  - Pick up the signed bits and validate the signature;\n>  - Perform the requested fetch; and\n>  - Record the merge (or prepare .git/MERGE_MSG) with both the signed bits.\n\nSo is there any reason this couldn't be cut-and-paste? Make the signed\npart small (*not* including diffstat and shortlog), and make it\nwhitespace-safe, and I wouldn't mind a tool at all.\n\nIf it *can* take the whole email, that would probably be a good design\n(so that a \"pipe email to command\" model would still work), but it\nwould be much better if it doesn't require it.\n\n> and the \"signed bits\" could include:\n>\n>   - the repository and the branch you were expected to pull;\n>   - the topic description.\n>\n> among other things the requestor can edit when request-pull message is\n> prepared.\n\nOne thing I'd like is that it would also fire up an editor for the\nmerge, even if it gets the topic description from the email or\ncut-and-paste. I often want to fix up peoples grammar etc. That's a\nseparate argument for trying to keep the signed part minimal - because\n I really don't want to have to maintain spelin errors just because\nthey are part of what was signed..\n\n Linus\n"},{"id":"178741","messageId":"CAJo=hJv5nAKH_ptYSWfMvFQv0Dj+naPXK35wSzKYkfPOYsWkxg@mail.gmail.com","threadId":"28805","inReplyTo":"CA+55aFz7TeQQH3D4Tpp31cZYZoQKeK37jouo+2Kh61Wa07knfw@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-11-03T01:02:37Z","receivedAt":"2011-11-03T01:02:37Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Wed, Nov 2, 2011 at 13:04, Linus Torvalds\n wrote:\n> On Tue, Nov 1, 2011 at 2:56 PM, Junio C Hamano wrote:\n>>\n>> But on the other hand, in many ways, publishing your commit to the outside\n>> world, not necessarily for getting pulled into the final destination\n>> (i.e. your tree) but merely for other people to try it out, is the point\n>> of no return (aka \"don't rewind or rebase once you publish\").  \"pushing\n>> out\" might be less special than \"please pull\", but it still is special.\n>\n> So I really think that signing the top commit itself is fundamentally wrong.\n\nI really disagree. I like the signed commit approach. It allows for a\nlot more workflows than just providing a way for you to validate a\npull from a trusted lieutenant. Debian/Gentoo folks want a way to sign\nevery commit in their workflow. Just because you don't want that and\nthink its crazy doesn't mean its not a valid workflow for that\ncommunity and is something Git shouldn't support. I never use `git\nstash`. I hate the damn command. Yet its still there. I just choose\nnot to use it. Junio's gpgsig header on each commit is also optional,\nand communities/contributors can choose to use (or ignore) the feature\nas they need to.\n\n> That commit may not even be *yours*. You may have pulled it from a\n> sub-lieutenant as a fast-forward, or similar. Amending it later would\n> be actively very very *wrong*.\n\nObviously you shouldn't amend a commit that would otherwise be a\nfast-forward. But why not write a new empty signed commit on top, and\nteach `git log` without the verify signatures flag to skip over\ncommits that have a gpgsig header line, have exactly one parent, and\nwhose parent tree matches the commit's own tree? This removes these\ncommits from the normal `git log` revision output, but yet the flow of\nchanges is still very visible within the history.\n\nAs I understand it, the point of multiple Signed-off-by lines in\ncommit message bodies is to show the flow of a change, who reviewed\nand applied a given commit, until it finally lands in a tree where its\ncommit SHA-1 is frozen in stone and you can later pull it. The empty\nsigned commit on top of a fast-forward provides that same flow of a\nchange, readily visible with standard `git log` tools, but doesn't\nhave to clutter up history if we teach log how to skip this particular\ntype. Similar to the --no-merges way to skip merges. :-)\n\n> So quite frankly, I think the stuff in pu (or next?) is completely\n> mis-designed. Doing it in the commit is wrong for fundamental reasons,\n> which all boil down to a simple issue:\n\nTotally disagree. I'm really in favor of embedding these into the\ncommit headers the way Junio has done.\n\n>  - you absolutely *need* to add the signature later. You *cannot* do\n> it at \"git commit\" time.\n\nWhy can't you add it at commit time? What is stopping me from running\n`git commit -S` every time I make a commit? Is it that my fingers will\nwear out more quickly because I have to type my pass-phrase too often?\n\nWhat is wrong with making a signed commit on a commit I have a high\nlevel of confidence in, but not signing the others? In my own workflow\nI make a lot of commit --amends / rebases until I am pretty confident\nin the code being written and organized the way I think it should be\nfor distribution to others. But at some point in that workflow I'm\ndoing an --amend or a rebase to make that last final touch, and during\nthat commit I can add -S to make it signed, because I'm pretty certain\nits ready to go. At that point, barring some horrific bug or reviewer\ncomments, I am unlikely to change the commit. I know at the time I\nmake that commit that I am pretty confident in the commit, so I take\nthe extra few key strokes to sign it.\n\n> That's a fundamental issue both from a \"workflow model\" issue (ie you\n> want to sign stuff after it has passed testing etc,\n\nWhy do I have to wait until its tested to sign it? The gpgsig\nsignature isn't any more special than the Signed-off-by line I put\ninto my commit message to agree to the developer's certificate of\norigin, nor is it any more special than the committer line in the\ncommit header. Its just a statement on the commit that I have a\nreasonable enough confidence in the value of this particular commit\nand its ancestors that I should take the time to unlock my GPG key and\nsign the content in case I do distribute this to others.\n\nIf you are going to spend time testing a commit, its probably going to\ntake longer to perform that testing than it is to perform the GPG key\nunlock and signature. So why are you complaining about the time it\ntakes to sign something you think is worthy of testing? If the tests\nfail, you'll need to rewind/amend/whatever to address the breakage. If\nthe tests pass, the commit is already signed and ready for\ndistribution. If you are spending a lot of time signing commits that\nare highly likely to fail tests, well, maybe you should look at other\nways to improve your workflow so that you have a higher level of\nconfidence in the code you record and assume will be a permanent part\nof the project's history.\n\n> but you may need\n> to commit it in order to *get* testing),\n\nMaybe consider allowing a \".dirty\" suffix like git-core does on\nbuilds? Or if you are submitting the code to a remote test cluster\nthat auto-compiles the code for you (and that is why you need a\ncommit), it sounds like the time it takes for that to push, compile,\ntest, and report back is way higher than the time it takes to make the\nsignature. So you probably should only be submitting something that\nyou had a reasonable level of confidence in. So you should go ahead\nand sign it before sending it for testing, in case the tests do pass\nand you want to publish that commit.\n\n> as well as from a\n> \"fundamental git datastructures\" issue (ie you would want to sign\n> commits that aren't yours.\n\nSure. But this is why you can make an empty commit and sign that.\n\n> \"git commit --amend\" is not the answer - that destroys the fundamental\n> concept of history being immutable, and while it works for your local\n> commits, it doesn't work for anybody elses commits, or for stuff you\n> already pushed out.\n\nNobody said you had to amend everything. You can add an empty commit.\n\n> And \"add a fake empty commit just for the signature\" is not the answer\n> either - because that is clearly inferior to the tags we already had.\n\nReally? I disagree. The commit DAG scales quite well. The tag\nnamespace does not. A refs/signatures/$COMMIT_SHA1 namespace also does\nnot scale well.\n\nAn empty commit with a gpgsig header has about the same object cost as\nan annotated tag once packed. But it has the advantage that the damn\nthing doesn't clog up the reference space, the reference handling\ncode, or the advertisements in the native protocol. As history goes\non, older signatures are less relevant, and automatically are\navoided/skipped/bypassed by the normal DAG walking code. Tags don't do\nthis well because they have no relationship to the project history.\n\nThe only downside to an empty commit with the gpgsig header is I\ncannot grab an arbitrarily deep ancestor and say \"Who has signed a\ncommit that depends on this\"? Today we already have this with git\ndescribe --contains (aka git name-rev) for annotated tags. Its a new\nfeature we have to teach to some part of the log machinery, but the\nalgorithm will be easier because it doesn't have to mess with the\nmapping table of tag objects. It just has to start digging from roots,\nremembering each commit that has a gpgsig on any given branch path,\nand then outputting the matches when it finds the commit in question.\n\nThe commit approach also has the advantage that your tree\nautomatically carries any lieutenant's signatures, by virtue of them\nalready being frozen in the commits. This allows anyone downstream of\nyou to verify the same signatures, and check them against their own\nkeyring contents. If the signatures are all detached in some transient\nannotated tag space, its impossible for anyone other than you to\nverify pull requests. I would hate to say we have this nice\ndistributed version control system, but only Linus can prove the pull\nrequests in his repository are what they claim, and we have to then\nimplicitly trust you to resign that data without the original\nsignatures being present. $DAY_JOB would feel a lot better about the\nintegrity of the Linux kernel repository if _ANYONE_ can validate pull\nrequests offline after they have happened.\n\n> I dunno. Did I miss something? As far as I can tell, the signed tags\n> that we've had since day one are *clearly* much better in very\n> fundamental ways.\n\nCompletely disagree. :-)\n"},{"id":"178742","messageId":"CA+55aFx0oCd6-sh0psYxho-s=sHAK0RHXJHfLewRuUcdXzxZbg@mail.gmail.com","threadId":"28805","inReplyTo":"CAJo=hJv5nAKH_ptYSWfMvFQv0Dj+naPXK35wSzKYkfPOYsWkxg@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-11-03T01:19:36Z","receivedAt":"2011-11-03T01:19:36Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Wed, Nov 2, 2011 at 6:02 PM, Shawn Pearce wrote:\n>>\n>> So I really think that signing the top commit itself is fundamentally wrong.\n>\n> I really disagree. I like the signed commit approach.\n\nIf you like it so much, go ahead and use them.\n\nBut stop with the crazy excuses for the downsides. I explained exactly\nwhy amending is stupid and wrong, and why empty commits are f*cking\nmoronic. But even apart from the *technical* problems with the stupid\nmis-designed feature, I explained why it was fundamentally broken from\na workflow standpoint too.\n\nI'm not saying that you shouldn't use them - go ahead and use the\nfeature if you like it. But please spare me your excuses for stupid\nworkarounds that come from the fact that they aren't a good match for\nsane workflows.\n\n Linus\n"},{"id":"178744","messageId":"CA+55aFwXu=+HdQ5nW11Ts5p-V=KgpxjyagKqB+Xv+qBOEEWXvQ@mail.gmail.com","threadId":"28805","inReplyTo":"CA+55aFx0oCd6-sh0psYxho-s=sHAK0RHXJHfLewRuUcdXzxZbg@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-11-03T01:45:26Z","receivedAt":"2011-11-03T01:45:26Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Wed, Nov 2, 2011 at 6:19 PM, Linus Torvalds\n wrote:\n>\n> I'm not saying that you shouldn't use them - go ahead and use the\n> feature if you like it. But please spare me your excuses for stupid\n> workarounds that come from the fact that they aren't a good match for\n> sane workflows.\n\nBtw, having now done odd things with signed tags (because we've used\nthem as a side-band verification mechanism), I can certainly also say\nthat the signed tags have their set of problems too.\n\nSo signed tags aren't perfect. They were designed for making releases,\nand that shows very clearly in how git works with them. The default\nchoices that git makes are very awkward indeed when you use signed\ntags as \"security tokens\".\n\nBut unlike the \"sign the commit\" approach, those are implementation\nand UI issues, not \"fundamentally broken design\" issues.\n\nFor example, fetching a single signed tag with git is surprisingly\nhard. It *shouldn't* be hard - and there's no underlying technical or\ndesign reason why it would be hard, but it is. Why? Because all the\ngit actions when it comes to tags are all geared towards one\nparticular use, that is *not* about the signature checking aspect of\nthem.\n\nHere's an example: Rusty Russell now makes nice signed tags for the\nthings he asks me to pull, and then states them in the pull message.\nSo he will mention that he has a tag named\n\n rusty@rustcorp.com.au-v3.1-8068-g5087a50\n\nin his git repository at\n\n git://github.com/rustyrussell/linux.git\n\nand while I don't think his tag names are all that wonderful, it makes\nsense from an automated script kind of standpoint.\n\nNow, let's try to get that tag:\n\n [torvalds@i5 linux]$ git fetch\ngit://github.com/rustyrussell/linux.git\nrusty@rustcorp.com.au-v3.1-8068-g5087a50\n fatal: Couldn't find remote ref rusty@rustcorp.com.au-v3.1-8068-g5087a50\n\noops. Ok, so his tag naming is *really* akward. Whatever. Let's try again:\n\n [torvalds@i5 linux]$ git fetch\ngit://github.com/rustyrussell/linux.git\nrefs/tags/rusty@rustcorp.com.au-v3.1-8068-g5087a50\n From git://github.com/rustyrussell/linux\n * tag\nrusty@rustcorp.com.au-v3.1-8068-g5087a50 -> FETCH_HEAD\n\nAhh, success!\n\nOops. Nope. It turns out that git will *peel* the tag when you fetch\nit, so FETCH_HEAD actually doesn't contain the tag object at all, but\nthe commit object that the tag pointed to. MAJOR FAIL.\n\nQuite frankly, I think that's a git bug, but it's a git bug because\n\"git fetch\" was designed to get the commit to merge. Fair enough.\nLet's work around it, and rename the tag at the same time:\n\n [torvalds@i5 linux]$ git fetch\ngit://github.com/rustyrussell/linux.git\nrefs/tags/rusty@rustcorp.com.au-v3.1-8068-g5087a50:refs/tags/rusty\n From git://github.com/rustyrussell/linux\n * [new tag]\nrusty@rustcorp.com.au-v3.1-8068-g5087a50 -> rusty\n * [new tag]\nrusty@rustcorp.com.au-v3.1-2-gb1e4d20 ->\nrusty@rustcorp.com.au-v3.1-2-gb1e4d20\n * [new tag]\nrusty@rustcorp.com.au-v3.1-4896-g0acf000 ->\nrusty@rustcorp.com.au-v3.1-4896-g0acf000\n * [new tag]\nrusty@rustcorp.com.au-v3.1-8068-g5087a50 ->\nrusty@rustcorp.com.au-v3.1-8068-g5087a50\n\nWTF? Now we finally *did* get the tag, and we can do\n\n git verify-tag rusty\n\nand that will work. But what the hell happened? We got three other\ntags too that we didn't even ask for!\n\nSo we have actual git bugs here, that relate to the fact that we've\ntreated signed tags specially, and have magic code to basically say\n\"if there's a signed tag that is reachable from the thing you pull,\nand you're not just doing a temporary pull into FETCH_HEAD, we'll\nfetch that signed tag too\".\n\nAgain - not a fundamental design mistake in the data structures, and\nit actually made sense from a \"signed tags are important release\npoints\" standpoint, but it makes it *really* inconvenient to use\nsigned tags for signature verification.\n\nAlso, the fact that the signed tag gets peeled when we do fetch into\nFETCH_HEAD also means that we can't actually save the signature in\nresulting the merge commit. The merge, instead of being able to\nperhaps save the information that we merged a nice trusted signed\npoint, only has the commit.\n\nBut practically, all of these issues should be pretty easily solvable.\nSo it should be quite easy to make\n\n git pull \n\njust do the right thing - including verifying the tag, and adding the\ninformation in the tag into the merge commit message.\n\nSo signed tags are not mis-designed from a conceptual standpoint -\nthey just work really really awkwardly right now for what the kernel\nwould like to do with them.\n\nWith a few UI fixes, I think the signed tag thing would \"just work\".\n\nThat said, I do think that the \"signature in the pull request\" should\nalso \"just work\", and I'm not entirely sure which one is better. It\nmight be more convenient to get the signature data from the pull\nrequest. So I'm not at all married the the notion of using signed tags\nfor this.\n\n Linus\n"},{"id":"178746","messageId":"CAJo=hJsXvSyB65KBp8sfciT=h5uZSqSUdxkpWtZJRtr4hXAh5A@mail.gmail.com","threadId":"28805","inReplyTo":"CA+55aFwXu=+HdQ5nW11Ts5p-V=KgpxjyagKqB+Xv+qBOEEWXvQ@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-11-03T02:14:26Z","receivedAt":"2011-11-03T02:14:26Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Wed, Nov 2, 2011 at 18:45, Linus Torvalds\n wrote:\n> On Wed, Nov 2, 2011 at 6:19 PM, Linus Torvalds\n> wrote:\n>>\n>> I'm not saying that you shouldn't use them - go ahead and use the\n>> feature if you like it. But please spare me your excuses for stupid\n>> workarounds that come from the fact that they aren't a good match for\n>> sane workflows.\n\nWe often disagree. :-)\n\n> Btw, having now done odd things with signed tags (because we've used\n> them as a side-band verification mechanism), I can certainly also say\n> that the signed tags have their set of problems too.\n...\n> But practically, all of these issues should be pretty easily solvable.\n> So it should be quite easy to make\n>\n>    git pull \n>\n> just do the right thing - including verifying the tag, and adding the\n> information in the tag into the merge commit message.\n\nUhm, sure.\n\nQuoting you 2 days ago:\n\nOn Mon, Oct 31, 2011 at 15:52, Linus Torvalds\n wrote:\n> On Mon, Oct 31, 2011 at 3:44 PM, Junio C Hamano wrote:\n>>\n>> So nobody is worried about this (quoting from my earlier message)?\n>\n> No, because you haven't been reading what we write.\n>\n> The tag is useless.\n>\n> The information *in* the tag is not. But it shouldn't be saved in the\n> tag (or note, or whatever). Because that's just an annoying place for\n> it to be, with no upside.\n>\n> Save it in the commit we generate. BAM! Useful, readable, permanent,\n> and independently verifiable.\n\nSo you propose we put the tag contents into the merge commit message\nso it can be verified after the fact? So merges are now going to be\nsomething much more horrific to read, because it will end with Git\nobject tag cruft, the tag message, and the PGP signature spew that no\nhuman can decode in the head?\n\nOh, right, tags are almost good enough. Elsewhere in this thread you\nalso stated we have to redo the way tags are signed so that the tag\nmessage body itself is not part of the signature, allowing you to fix\nspelin errors so you are not stuck with them in your commit history.\nBut I assume we will have to keep the more typical headers of object /\ntype / tag / tagger fields, as that is the key information the\nsignature needs to be over to be of any value. So now there will be\ntwo different ways in which a Git annotated tag object will have its\nsignature created, as certainly you don't mean to remove the tag\nmessage body from the PGP signature content for release tags.\n\nI fail to see how shoving Git object data fields and a complete PGP\nsignature block into a merge commit message body, which will show by\ndefault in all git log type tools, and exist in cherry-picks or\nrebases that might make that data less valuable, is somehow better\nthan the gpgsig header that neatly tucks it away until requested. I\nalso fail to see how scraping the message body for the proper fields\nin order to implement automated verification of the signature (because\nno human can do it themselves and copy-paste sucks) is a good idea.\nEverywhere else in Git that we have machine readable formats its very\nwell structured so that no guessing is required.\n\n> So signed tags are not mis-designed from a conceptual standpoint -\n> they just work really really awkwardly right now for what the kernel\n> would like to do with them.\n>\n> With a few UI fixes, I think the signed tag thing would \"just work\".\n\nWell, UI fixes, protocol changes, improvements to manage a large\nreference space which we have previously said is an insane and stupid\nworkflow, etc. One reason you picked up all of those extra tags was\nthe include-tag capability kicking on and picking up older tag\nhistory. We now have to disable it in certain cases.\n\nIts not just a few UI fixes. And there is a lot more work to write a\nverify for the tag contents+signature that appears in the body of a\nmerge commit message. Not to mention we now have to do that verify\nlogic twice, once in the signed pull request tag like but not quite a\ntag but uses a tag thing you are advocating, and again for the merge\ncommit message body that contains the tag object data that we don't\nnormally show to an end user, but will now be in every merge commit\nyou make.\n\nGo ahead and call me stupid, but this already is a bigger amount of\nsurgery to the git-core code, not to mention worse user experience for\nthe average `git log` reading human, than having a hidden by default\ngpgsig header that might ask a contributor to take 2 extra seconds\nbefore making a commit to consider the useful lifespan of that commit.\nOr $DEITY forbid, write a new empty commit to record the equivalent of\ntheir Signed-off-by.\n\nOh, and while I am on that subject...\n\n\n\nI have never grasped why sometimes a Signed-off-by is added to a\npatch, and why sometimes its not. It seems to be this weird function\nof \"If the commit SHA-1 is already stable DON'T FUCKING TOUCH IT BY\nADDING SIGNED-OFF-BY IT RUINS THE HISTORY\", but if you are too far\ndown the food chain to be fortunate enough for your commit SHA-1 to\nremain frozen, the Signed-off-by has to be added to assert that the\ncode can be contributed. It sounds like the workflow developed around\nwhere it wasn't acceptable to force history rewriting, you suffer by\nnot having the SOB, but whenever possible you force a history rewrite\non the contributor just so you can add a SOB and feel good about the\nfact that the SOB is added to the commit message.\n\nGet over it. Add the fucking empty commit to show the flow of a\nchange. Stop forcing every fucking contributor to rebase/rewrite his\ncommits just so someone higher up in the food chain can wank with\ntheir SOB line.\n\nEveryone I talk to that contributes code to the kernel who isn't Linus\nor Ted Tso complains about this, and then asks me to fucking fix it.\nThey want stable SHA-1s so they know their change arrived into Linus'\ntree unmolested. Unfortunately, despite their volume of changes, they\naren't high enough in the food chain to be this lucky. Nope, someone\nhas to wank their SOB in first. And maybe fix a spelin error.\n\n"},{"id":"178747","messageId":"CA+55aFzstE-+NzfSAWMEokB7-rYsZOcZe9Ez-LxPNOKnciJ3UQ@mail.gmail.com","threadId":"28805","inReplyTo":"CA+55aFwXu=+HdQ5nW11Ts5p-V=KgpxjyagKqB+Xv+qBOEEWXvQ@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-11-03T02:19:34Z","receivedAt":"2011-11-03T02:19:34Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Wed, Nov 2, 2011 at 6:45 PM, Linus Torvalds\n wrote:\n>\n>   [torvalds@i5 linux]$ git fetch git://github.com/rustyrussell/linux.git refs/tags/rusty@rustcorp.com.au-v3.1-8068-g5087a50\n\nSo this trivial patch removes one line of code, and makes this actually work.\n\nHowever, it also makes us fail many tests that *test* that we peeled\nwhat we fetched. However, I think the tests are wrong.\n\nIf the tag doesn't resolve into a commit, we happily output the SHA1\nof the tag itself - and we say that it shouldn't be merged.\n\nAnd it the tag *does* resolve into a commit, why would we output the\nSHA1 of the commit? The tag should be peeled properly later when it\ngets used, so peeling it here seems to be just a misfeature that makes\nsigned tags not work well.\n\nSo I suspect we should just apply this patch, but I didn't check\nexacty what the failed tests are - except for the first one, that just\ncompares against a canned response (and the canned response should\njust be changed). Maybe there was some reason for the peeling,\nalthough I suspect it was just a fairly mindless case of \"make it a\ncommit, because the merge needs the commit\" - never mind that the\nmerge would peel it anyway.\n\n Linus\n\n\n builtin/fetch.c | 3 +--\n 1 files changed, 1 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/fetch.c b/builtin/fetch.c\nindex 91731b909aeb..494a7f9976f8 100644\n--- a/builtin/fetch.c\n+++ b/builtin/fetch.c\n@@ -436,8 +436,7 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,\n \t\t}\n \t\tnote[note_len] = '\\0';\n \t\tfprintf(fp, \"%s\\t%s\\t%s\",\n-\t\t\tsha1_to_hex(commit ? commit->object.sha1 :\n-\t\t\t\t rm->old_sha1),\n+\t\t\tsha1_to_hex(rm->old_sha1),\n \t\t\trm->merge ? \"\" : \"not-for-merge\",\n \t\t\tnote);\n \t\tfor (i = 0; i < url_len; ++i)\n"},{"id":"178748","messageId":"CA+55aFyXg32mko8TOGCfGHpr3jHBEgcKiK7HdVwq0Wez0fAs9A@mail.gmail.com","threadId":"28805","inReplyTo":"CAJo=hJsXvSyB65KBp8sfciT=h5uZSqSUdxkpWtZJRtr4hXAh5A@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-11-03T02:25:17Z","receivedAt":"2011-11-03T02:25:17Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Wed, Nov 2, 2011 at 7:14 PM, Shawn Pearce wrote:\n>\n> So you propose we put the tag contents into the merge commit message\n> so it can be verified after the fact? So merges are now going to be\n> something much more horrific to read, because it will end with Git\n> object tag cruft, the tag message, and the PGP signature spew that no\n> human can decode in the head?\n\nActually, I wanted to just drop the damn thing.\n\nTo me, the point of the tag is so that the person doing the merge can\nverify that he merges something trusted.\n\nHowever, everybody else seems to disagree, and wants that stupid\nsignature to live along in the repository. And I can live with that,\nalthough I do agree with you that it's not exactly pretty. I can live\nwith \"ugly signature that I don't care for\" way more than \"stupid\ndesign\".\n\nBecause unlike your crazy empty commit, it at least fits the workflow,\nand it certainly isn't any uglier that extraneous pointless commit.\n\nYou can disagree. You obviously do. I simply don't care. Because I'm right.\n\n(And your claim that it's big UI fixes and protocol changes is pure\nand utter garbage. I just sent a patch that cleans the code up,\nremoves a line that improperly drops information and gets rid of the\nbiggest problem with our current handling of tags. No protocol changes\ninvolved, no big UI fixup).\n\n Linus\n"},{"id":"178749","messageId":"CA+55aFzbNxTn83DdQd9cVpDujNYEdEP0Aimv5k1hCD0ebTDzcQ@mail.gmail.com","threadId":"28805","inReplyTo":"CAJo=hJsXvSyB65KBp8sfciT=h5uZSqSUdxkpWtZJRtr4hXAh5A@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-11-03T02:31:00Z","receivedAt":"2011-11-03T02:31:00Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Wed, Nov 2, 2011 at 7:14 PM, Shawn Pearce wrote:\n>\n> \n\nI'm answering this separately, because it's a separate rant.\n\nIt's also totally bogus, but whatever.\n\n> Get over it. Add the fucking empty commit to show the flow of a\n> change. Stop forcing every fucking contributor to rebase/rewrite his\n> commits just so someone higher up in the food chain can wank with\n> their SOB line.\n\nShawn, stop using whatever drugs you are using.\n\nNOBODY EVER REBASES ANYTHING FOR SIGNED-OFF-BY.\n\nIf they do, they are doing things very very wrong.\n\nSigned-off-by: is *purely* for sending patches by email. No git\noperations involved. None. Nada. Zilch. No rebasing involved, because\nthere's not even a git repository involved, for chissake!\n\nOnce something is in git, it's not signed off on - there should be a\nsign-off-chain from the author to the committer, and that's it.\nAnything else would be crazy.\n\nSo stop the crazy rants. Stop with the bad drugs. Seriously. You're\nacting crazy.\n\n Linus\n"},{"id":"178751","messageId":"20111103025532.GB9492@sigill.intra.peff.net","threadId":"28805","inReplyTo":"CAJo=hJv5nAKH_ptYSWfMvFQv0Dj+naPXK35wSzKYkfPOYsWkxg@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-11-03T02:55:32Z","receivedAt":"2011-11-03T02:55:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 02, 2011 at 06:02:37PM -0700, Shawn O. Pearce wrote:\n\n> > So I really think that signing the top commit itself is fundamentally wrong.\n> \n> I really disagree. I like the signed commit approach. It allows for a\n> lot more workflows than just providing a way for you to validate a\n> pull from a trusted lieutenant. Debian/Gentoo folks want a way to sign\n> every commit in their workflow. Just because you don't want that and\n> think its crazy doesn't mean its not a valid workflow for that\n> community and is something Git shouldn't support. I never use `git\n> stash`. I hate the damn command. Yet its still there. I just choose\n> not to use it. Junio's gpgsig header on each commit is also optional,\n> and communities/contributors can choose to use (or ignore) the feature\n> as they need to.\n\nStop for a minute and think about what it _means_ to sign a commit. Is\nit saying \"I wrote this commit?\" Or \"I think this commit is good?\" Or \"I\nthink all of the history leading to this is good?\" It's obviously going\nto be a per-project thing, but it's very constricting. Leaving aside\nall of the workflow issues Linus brought up (but which I do agree with),\nthink about what it would mean for Linus to fetch a commit from a\nlieutenant and then sign it. Whatever it means, it can really only be\n_one_ thing.\n\nBut big projects that are interested in signatures probably want to say\nmore. They want to say \"this developer really wrote this commit\". They\nwant to say \"QA passed this commit\". They want to say \"the history up to\nhere looks good\". And so on.\n\nBut they can't say those things without binding some data to the commit\n(i.e., making a certificate saying \"this commit passed QA\"). Data which\nmight only make sense to assert much later than the commit is written.\n\nSo you're going to need to support detached commit signatures in some\nform anyway to make everybody happy. Which isn't to say in-commit\nsignatures are wrong, but they are just one tool in a toolbox.\n\nPersonally, I think the only thing that makes sense to assert inside a\ncommit itself is that you are the author, and the author line of the key\nshould match the email UID of the signing key. And then anything you\nwant to say about _other_ people's commits (or even your own commits,\nbut later) should come in the form of detached signatures with some\ncontent.\n\nThat's how signed tags work. It's not just Linus signing a commit. It's\nLinus signing a binding between a commit and the statement \"this is\nv2.6.28\". The only thing wrong with the signed tag model for more\ngeneral use is that you need some way of naming and organizing large\nnumbers of tags (e.g., several per commit if you have things like QA\nsignatures).\n\n-Peff\n"},{"id":"178752","messageId":"robbat2-20111103T030225-511273733Z@orbis-terrarum.net","threadId":"28805","inReplyTo":"20111103025532.GB9492@sigill.intra.peff.net","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Robin H. Johnson","fromEmail":"robbat2@gentoo.org","sentAt":"2011-11-03T03:16:49Z","receivedAt":"2011-11-03T03:16:49Z","isPatch":false,"sender":{"key":"robbat2@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/373898?v=4"},"body":"On Wed, Nov 02, 2011 at 10:55:32PM -0400, Jeff King wrote:\n> But big projects that are interested in signatures probably want to say\n> more. They want to say \"this developer really wrote this commit\". They\n> want to say \"QA passed this commit\". They want to say \"the history up to\n> here looks good\". And so on.\nOn the Gentoo side, we've also pondered the question of:\nauthor != committer != pusher\nAnd how to preserve many signatures from sources.\n\nWe're on a central repo model, with some ~250 committers.\n\nI was originally primarily after the push certificates/signed-push, and\nrecording that data in the notes, but that still has the problems of\nthird-party verification as mentioned in the thread.\n\nIf we require that the tip of every push is a signed commit via a hook,\nwe get knowledge of the pushers. Either your real commit itself is\nsigned, or you have a signed merge commit on top, or you have a signed\nempty commit. In all of the cases, I can verify your signature at the\nrecv hook. Having signed push in this case has a benefit that you could\nship the data as a bundle, or async from the signing.\n\nThe QA value of multiple signatures per commit is also valuable, to\nassert SOB WITHOUT altering the commit. I see spearce's rant and the\nretort, and really think there needs to be a middle ground - some of\ncommits that are coming from pulls, and not getting additional SOB,\ncould really benefit from them being recorded (I see them on mailing\nlists, but not introduced since that would break 'stable' IDs).\n\n> But they can't say those things without binding some data to the commit\n> (i.e., making a certificate saying \"this commit passed QA\"). Data which\n> might only make sense to assert much later than the commit is written.\n> \n> So you're going to need to support detached commit signatures in some\n> form anyway to make everybody happy. Which isn't to say in-commit\n> signatures are wrong, but they are just one tool in a toolbox.\nI was proposing that Git supports _all_ of these models:\n- signed commits\n- signed pushes (via certs)\n- whatever signed lightweight tag idea happens\n- existing annotated tags\n\nChoices. Each with their own costs and advantages.\n\n-- \nRobin Hugh Johnson\nGentoo Linux: Developer, Trustee & Infrastructure Lead\nE-Mail : robbat2@gentoo.org\nGnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85\n"},{"id":"178754","messageId":"20111103032205.GA25888@pompeji.miese-zwerge.org","threadId":"28805","inReplyTo":"CA+55aFyXg32mko8TOGCfGHpr3jHBEgcKiK7HdVwq0Wez0fAs9A@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Jochen Striepe","fromEmail":"jochen@tolot.escape.de","sentAt":"2011-11-03T03:22:05Z","receivedAt":"2011-11-03T03:22:05Z","isPatch":false,"sender":{"key":"jochen@tolot.escape.de","avatar":null},"body":"\tHi,\n\nOn Wed, Nov 02, 2011 at 07:25:17PM -0700, Linus Torvalds wrote:\n> To me, the point of the tag is so that the person doing the merge can\n> verify that he merges something trusted.\n> \n> However, everybody else seems to disagree, and wants that stupid\n> signature to live along in the repository.\n\nIt seems quite useless and leading to false conclusions in several cases\nwhere the merger's gpg output differs from someone's checking later on,\ne.g. when\n\n - the signing key has been revoked in the mean time (for whatever\n reasons)\n - the signing key has expired\n - the public part of the signing key is not available for the general\n public.\n\nAFAIK gpg just gives you an error code and a message like e.g. \"Key has\nexpired\" without stating if the key was valid _when signing the commit_.\n\nHow do you plan to handle this when keeping the signature in the\nrepository? Or am I overlooking something?\n\n\nThanks,\nJochen.\n"},{"id":"178756","messageId":"CA+55aFyG4VuiRN3kcyDVF4sw7b89m-2bOBeQLOGWTcd9o3akzQ@mail.gmail.com","threadId":"28805","inReplyTo":"20111103032205.GA25888@pompeji.miese-zwerge.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-11-03T04:13:32Z","receivedAt":"2011-11-03T04:13:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Wed, Nov 2, 2011 at 8:22 PM, Jochen Striepe wrote:\n>\n> It seems quite useless and leading to false conclusions in several cases\n> where the merger's gpg output differs from someone's checking later on,\n> e.g. when\n>\n>  - the signing key has been revoked in the mean time (for whatever\n>   reasons)\n>  - the signing key has expired\n>  - the public part of the signing key is not available for the general\n>   public.\n\nSo I don't think those are *big* issues. Sure, you'd want the public\nkey to be public for it to make any real sense to save, but on the\nother hand, they *are* generally public. Yes, yes, you might have keys\nthat are only used - and only made public - within some particular\norganization, but in that case the source code that gets signed with\nthose keys would tend to be private to that organization too, so..\n\nAnd yes, keys get revoked or they expire, but that's still a pretty\nrare event, so it doesn't really invalidate the argument that making\nthe original signed content available can quite often be useful - even\nif it's not guaranteed to *always* be useful.\n\nNo, my main objection to saving the data is that it's ugly and it's\nredundant. Sure, in practice you can check the signatures later fine\n(with the rare exceptions you mention), but even when you can do it,\nwhat's the big upside?\n\nAnd there are much bigger real downsides, imho.\n\nFor example, let's say that we do eventually end up switching from\nSHA1 to SHA256 in git, and we do a full re-import of the tree. Guess\nwhat? All those signatures are now just so much garbage. Sure, you can\nrecreate them (create some trusted script that you agree does a 1:1\ntransform, and re-sign everything), but in practice you can't ever\nreally do that - because all those things are tied to the tree, so you\nneed to have *everybodys* private keys in one place to do so. And the\npeople who signed things initially would have to be insane to allow\nthat.\n\nSo I'm actually of the opinion that \"internal signatures\" are bad\ndesign at a rather fundamental level.\n\nIn contrast, the \"external signed tags\" are fine: it's not just that\nthere are much fewer of them, it's that they are *independent*. So you\ncan easily re-generate the signed tags, because each signer can\n*individually* decide to validate the newly converted tree, and sign\noff on the fact that the conversion was done identically using new\nexternal tags with signatures.\n\nThis was one of the reasons I made the signed tags work the way they\ndo. And it wasn't because I was extremely far-sighted and thought of\nall the problems that internal signatures have - it's because monotone\nhad their internal signatures, and every other email on the monotone\nlist was about all the problems it caused.\n\n> AFAIK gpg just gives you an error code and a message like e.g. \"Key has\n> expired\" without stating if the key was valid _when signing the commit_.\n>\n> How do you plan to handle this when keeping the signature in the\n> repository? Or am I overlooking something?\n\nSo see above - I just wouldn't worry about it. The possible few cases\nwhere it would occur are dwarfed by the cases where it *doesn't*\noccur, and those are the ones I'd concentrate on. They are the ones\nthat need to be important enough that it's even worth carrying the\nrandom noise around.\n\nAre they?\n\nSo I do think that there are real upsides at the *process* level where\nyou can use the signatures to verify that what is pulled is pulled\nfrom the person you thought it was. I don't think anybody disputes\nthose advantages. But outside of that I think it gets very gray, and\nthere real disadvantages.\n\nThat said, I don't care *that* much. I don't mind polluting the merge\ncommits with information that I don't think is really worth it. So I'd\nbe willing to carry the signature information around, although I'd\nhope to minimize it and have some sane way to hide it.\n\n Linus\n"},{"id":"178784","messageId":"7v62j1gitn.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"CA+55aFwXu=+HdQ5nW11Ts5p-V=KgpxjyagKqB+Xv+qBOEEWXvQ@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-03T18:16:37Z","receivedAt":"2011-11-03T18:16:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> [torvalds@i5 linux]$ git fetch\n> git://github.com/rustyrussell/linux.git\n> rusty@rustcorp.com.au-v3.1-8068-g5087a50\n> fatal: Couldn't find remote ref rusty@rustcorp.com.au-v3.1-8068-g5087a50\n>\n> oops. Ok, so his tag naming is *really* akward. Whatever.\n\nIt is not \"Whatever\".\n\n $ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git v3.0\n fatal: Couldn't find remote ref v3.0\n\nI do not think we ever DWIMmed fetch refspecs to prefix refs/tags/, so it\nis not the naming but fetching tags without saying \"git fetch tag v3.0\"\n(which IIRC was your invention long time ago). \n\nIf we changed this \"git fetch $there v3.0\" to fetch tag, it would help the\nfinal step in your illustration, and I do not think it would be a huge\nregression---the only case it becomes fuzzy is when they have v3.0 branch\nat the same time, but the owner of such a repository is already playing\nwith fire.\n\n> [torvalds@i5 linux]$ git fetch\n> git://github.com/rustyrussell/linux.git\n> refs/tags/rusty@rustcorp.com.au-v3.1-8068-g5087a50\n> From git://github.com/rustyrussell/linux\n> * tag\n> rusty@rustcorp.com.au-v3.1-8068-g5087a50 -> FETCH_HEAD\n>\n> Ahh, success!\n>\n> Oops. Nope. It turns out that git will *peel* the tag when you fetch\n> it, so FETCH_HEAD actually doesn't contain the tag object at all, but\n> the commit object that the tag pointed to. MAJOR FAIL.\n>\n> Quite frankly, I think that's a git bug, but it's a git bug because\n> \"git fetch\" was designed to get the commit to merge. Fair enough.\n\nAnd because FETCH_HEAD started as (and probably still is) an internal\nimplementation detail of communication between fetch and merge inside\npull. So I do not have any issue in changing it to store tags unpeeled\nthere.\n> [torvalds@i5 linux]$ git fetch\n> git://github.com/rustyrussell/linux.git\n> refs/tags/rusty@rustcorp.com.au-v3.1-8068-g5087a50:refs/tags/rusty\n> From git://github.com/rustyrussell/linux\n> * [new tag]\n> rusty@rustcorp.com.au-v3.1-8068-g5087a50 -> rusty\n> * [new tag]\n> rusty@rustcorp.com.au-v3.1-2-gb1e4d20 ->\n> rusty@rustcorp.com.au-v3.1-2-gb1e4d20\n> * [new tag]\n> rusty@rustcorp.com.au-v3.1-4896-g0acf000 ->\n> rusty@rustcorp.com.au-v3.1-4896-g0acf000\n> * [new tag]\n> rusty@rustcorp.com.au-v3.1-8068-g5087a50 ->\n> rusty@rustcorp.com.au-v3.1-8068-g5087a50\n>\n> WTF?\n\nThis is not WTF but \"fetching a history to store the tip of it in your\nrefs/ namespace causes tags pointing into the history line followed\nautomatically\", and it exactly is what you want to happen if rusty asked\nyou to fetch his for-linus branch (which the tag may point at) instead.\n\n> We got three other\n> tags too that we didn't even ask for!\n\nWe could change the rule to read \"fetching a history to store the tip of it\nin your refs/heads namespace causes autofollow\". I am not sure if that is\nwhat we really want, though.\n\n> Again - not a fundamental design mistake in the data structures, and\n> it actually made sense from a \"signed tags are important release\n> points\" standpoint, but it makes it *really* inconvenient to use\n> signed tags for signature verification.\n\nWe could update three things:\n\n - DWIM $name in \"git fetch $there $name\" to refs/tags/$name when it makes\n sense;\n - FETCH_HEAD stores unpeeled object names; and\n - \"git pull\" learns --verify option.\n\nThen\n\n $ git pull --verify rusty rusty@rustcorp.com.au-v3.1-8068-g5087a50\n\ncould integrate the history leading to that tag to your current branch\nwhile running verify-tag on it.\n\nFor this, disabling the tag-auto-following is not necessary, as you are\nnot storing the retrieved tag anywhere.\n\nThat is a longwinded way to say I agree what you said below.\n\n> So signed tags are not mis-designed from a conceptual standpoint -\n> they just work really really awkwardly right now for what the kernel\n> would like to do with them.\n>\n> With a few UI fixes, I think the signed tag thing would \"just work\".\n>\n> That said, I do think that the \"signature in the pull request\" should\n> also \"just work\", and I'm not entirely sure which one is better.\n\nI do not think it is necessarily either/or choice.\n\nEither way does not solve anything other than validating the last hop\nbetween the last lieutenant to the integrator without having a way to give\nthe verification material to third parties.\n\nYour earlier \"pull request signature could be copied into the message of\nthe merge that integrates the pulled history\" solves 90% of the \"third\nparty validation\" issue.\n\nWith the signed tags approach, you could push out these signed tags you\nget from lieutenants, but there are quite a few things that need to happen\nfor it to be usable:\n\n - You or your lieutenants do not want to keep these tags in your working\n repository, to be listed in \"git tag -l\". They are ephemeral to you and\n your lieutenant, even though they have to be permanent for third\n party auditors.\n\n - Normal users of your project do not want to see them in \"git tag -l\"\n either.\n\n - Responses to \"git fetch\" and \"git ls-remote\" produced by \"git\n upload-pack\" do need to (optionally) include them to allow third party\n auditors to ask for them.\n\nI wonder if an approach like the following, in addition to the three\nthings I listed above, may give us a workable solution:\n\n * \"git fetch linus v3.0\" called by \"git pull --verify linus v3.0\" fetches\n the v3.0 unpeeled into FETCH_HEAD, GPG verifies it, creates\n refs/audit/$u, before running \"git merge\". $u is derived from v3.0\n (given tag), the identity of the GPG signer, and perhaps timestamp to\n make it both identifiable and unique under refs/audit/ hierarchy.\n\n * You \"git push origin\". This causes refs/audit/* refs that point at\n commits in the transferred history to auto-follow, just like the\n current \"git fetch $there $src:$dst\" causes refs/tags/* auto-follow.\n The refs/audit/* hierarchy in your public repository will be populated\n by lieutenant signatures.\n\n * (Optional) You may have signed \"git tag -s 'Linux v3.2' v3.2 master\"\n before you push origin out, or you may have not. Currently, you do have\n to \"git push origin v3.2\" separately if you did. The above auto-follow\n could be extended to push refs/tags/* hierarchy to eliminate this step\n as well.\n\nNote that because of the way \"upload-pack\" protocol is structured, the\nfirst response from \"upload-pack\" after it gets connection is the\nadvertisement of refs, and there is no way for \"fetch-pack\" to ask for\ncustomized refs advertisement to it. So for this to work without incurring\nundue overhead for normal users, we would need to exclude refs/audit/*\nfrom the normal ref advertisement (i.e. \"ls-remote\" does not see it) so\nthat \"git fetch\" by casual users will not have to wait for megabytes of\nref advertisements before issuing its first \"want\" request. Probably we\ncan change \"upload-pack\" to advertise only refs/heads/*, refs/tags/*, and\nHEAD by default, and a protocol extension could be added to ask for other\nhierarchies for specialized needs like third party auditors.\n\nBUT.\n\nThis does not allow third party auditors to audit how sub-subsystem\nhistories came into your lieutenants' history unless you also fetch from\nyour lieutenants in \"auditor\" mode to retrieve their refs/audit/* refs to\nbe propagated to your public repository, which all of us involved in this\nthread know you wouldn't bother if it is an additional manual step (and I\npersonally do not think I would bother if I were you).\n\nSo the audit trail will end at one level unless we have even more complex\narrangements. The auditors know the history up to some point in the past\ncame from you (your last signed tag at release time, which some people may\nfeel a bit too sparse for auditing purposes when a security incident like\nthat one happens in between releases), and they know subhistories of what\nyou merged came from your direct lieutenants (the refs/audit/* tags the\nabove change allowed you to forward automatically when you published), but\nthey have to take the word of your direct lieutenants at face value.\n\nI do not know if that is acceptable for $DAYJOB types, though.\n"},{"id":"178785","messageId":"7vzkgdf493.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"CA+55aFz7TeQQH3D4Tpp31cZYZoQKeK37jouo+2Kh61Wa07knfw@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-03T18:29:28Z","receivedAt":"2011-11-03T18:29:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Tue, Nov 1, 2011 at 2:56 PM, Junio C Hamano wrote:\n>>\n>> But on the other hand, in many ways, publishing your commit to the outside\n>> world, not necessarily for getting pulled into the final destination\n>> (i.e. your tree) but merely for other people to try it out, is the point\n>> of no return (aka \"don't rewind or rebase once you publish\"). \"pushing\n>> out\" might be less special than \"please pull\", but it still is special.\n>\n> So I really think that signing the top commit itself is fundamentally wrong.\n\nIt merely is a stronger form of the \"committer\" line in the commit\nobject. A random repository at Github anybody can create repositories at\ncan serve you a random commit with any random name on \"committer\" line,\nand the new gpgsig header is a way to let the committer certify it\ngenuinely is from the committer.\n\nI do not think for that purpose, in-commit signature is fundamentally\nwrong. I was hoping it would be more useful than it turned out to be, but\nI agree that it just is not suitable as a vehicle to convey \"I made that\ncommit some time ago, and now I want you to pull it for such and such\nreasons\" in a larger workflow.\n\nThe \"now I want you to pull it for such and such reasons\" part is the pull\nrequest, and if we are to protect them with GPG signatures, and perhaps\ncopy the signed part in the resulting merge, don't we have a reasonable\nsolution, without all the downsides the signed tag approach would cause if\nwe wanted to allow third party auditors to have access to the signatures\nfor independent auditing purposes (described in a separate message)?\n\nPerhaps what is causing the problem is the desire to allow third party\nauditors finer grained audit trail, but after having heard that $DAYJOB\nfolks went through each and every commit after known release points with\nfine-toothed comb, I am not brave/rude/blunt enough to dismiss it as\nunimportant.\n"},{"id":"178787","messageId":"7vvcr1f38j.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"7v62j1gitn.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-03T18:52:12Z","receivedAt":"2011-11-03T18:52:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> BUT.\n\nAhh, sorry for the noise. I realize that we already have a winner, namely,\nthe proposal outlined in your message I was responding to.\n\nIt just didn't click to me that you were replacing \"signed material from\npull request copied into the merge\" with \"contents of signed tag copied\ninto the merge\".\n\nSo forget everything I said in the later parts of my response that talks\nabout refs/audit/*, and the other message except for gpgsig header being a\nstronger form of existing committer line.\n\n\n\n"},{"id":"178790","messageId":"CA+55aFzZgECmCVBeu2+f+DUUpk4TOrvJB0NYeu-5XKSjRZS+xA@mail.gmail.com","threadId":"28805","inReplyTo":"7v62j1gitn.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-11-03T19:06:05Z","receivedAt":"2011-11-03T19:06:05Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Thu, Nov 3, 2011 at 11:16 AM, Junio C Hamano wrote:\n>\n> It is not \"Whatever\".\n>\n>  $ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git v3.0\n>  fatal: Couldn't find remote ref v3.0\n>\n> I do not think we ever DWIMmed fetch refspecs to prefix refs/tags/, so it\n> is not the naming but fetching tags without saying \"git fetch tag v3.0\"\n> (which IIRC was your invention long time ago).\n\nAhh. Yeah, and not DWIM'ing tags is probably ok. I'd completely\nforgotten about the special \"tag\" shortcut.\n\nWhich probably means it was a bad ui decision to begin with. But once\nmore, the UI is clearly designed for fetching the tags into your own\ntag-space (ie it does \"refs/tags/:refs/tags/\") rather than\nfetching the tag just for verification.\n\n> If we changed this \"git fetch $there v3.0\" to fetch tag, it would help the\n> final step in your illustration, and I do not think it would be a huge\n> regression---the only case it becomes fuzzy is when they have v3.0 branch\n> at the same time, but the owner of such a repository is already playing\n> with fire.\n\nYeah, extending DWIM for remote repos to do the same thing it does for\nlocal repositories is probably the right thing regardless of any other\nissues.\n\nWe already have the \"tag and branch with the same name\" issue for\nlocal repositories, and we have perfectly good disambiguation rules\nfor when disambiguation is necessary. Making the DWIM rules be the\nsame for a remote case sounds sane.\n\nThat said, I don't think it's a big deal either. I was just confused\nby the expansion being different, but having to have the refs/tags/\nthere isn't a dealbreaker by any means.\n\n>> Quite frankly, I think that's a git bug, but it's a git bug because\n>> \"git fetch\" was designed to get the commit to merge. Fair enough.\n>\n> And because FETCH_HEAD started as (and probably still is) an internal\n> implementation detail of communication between fetch and merge inside\n> pull.\n\nWell, I certainly don't consider it to be just \"an implementation\ndetail\" personally. I use FETCH_HEAD all the time (the same way I use\nORIG_HEAD and just plain HEAD). It's very useful for \"fetch and check\nwhat they have\", when you want to look at something but you don't want\nall the remote tags and crud. So I consider it a honest-to-goodness\nreal user feature.\n\n>So I do not have any issue in changing it to store tags unpeeled there.\n\nIn fact, storing the peeled was really surprising to me, especially\nsince it actually *says* \"tag\" in the .git/FETCH_HEAD file. So the\n.git/FETCH_HEAD file really currently ends up being actively wrogn and\nmisleading for tags we fetch: it looks something like\n\n tag '' of \n\nand says it is a tag, but the SHA1 is of the peeled commit. That's\njust crazy, and actually made me think the other end (Rusty, in this\ncase) had done something wrong initially (ie I quite reasonably - I\nthought - blamed it on Rusty using a non-signed tag).\n\n>> WTF?\n>\n> This is not WTF but \"fetching a history to store the tip of it in your\n> refs/ namespace causes tags pointing into the history line followed\n> automatically\", and it exactly is what you want to happen if rusty asked\n> you to fetch his for-linus branch (which the tag may point at) instead.\n\nWell, yes and no. But mostly no.\n\nIf I just fetch his for-linus branch, I don't get (and I don't want)\nhis tags. It's only because I fetched it into my ref-space.\n\nAnd I only fetched it into my ref-space, because otherwise the crazy\ngit peeling happened if I don't do that.\n\nSo I didn't want those other tags, and I really normally wouldn't have\ngotten them. Only because I had to do that odd work-around to avoid\nthe peeling did I get it, because then the totally unrelated logic of\n\"ok, get the tags too\" triggered.\n\nSo it's a WTF, because this work-around ends up having the special\nside effects - and they make sense when you *really* fetch his branch\nand make it part of your name-space, but not when you only did the\n\"part of my namespace\" as a workaround for another git issue.\n\nObviously, you can use \"-n\" (--no-tags) to fetch the tag, and that\nactually fixes the issue, but that is it's own kind of WTF too: in\norder to fetch just *one* tag, you have to specify that you don't want\ntags? Not exactly a greatly intuitive use case ;)\n\nAnyway, the one-line rpatch I sent basically avoids all these WTF\nmoments, by just making \"git fetch \" work (apart from\nthe DWIMmery on the tag-name, but that's a totally independent small\ndetail that doesn't really matter)\n\n>> We got three other\n>> tags too that we didn't even ask for!\n>\n> We could change the rule to read \"fetching a history to store the tip of it\n> in your refs/heads namespace causes autofollow\". I am not sure if that is\n> what we really want, though.\n\nNo, I think the current \"follow tags\" rule is fine. It's just that it\ndidn't really mesh well with \"damn, I have to work around this other\ngit issue\".\n\n> We could update three things:\n>\n>  - DWIM $name in \"git fetch $there $name\" to refs/tags/$name when it makes\n>   sense;\n>  - FETCH_HEAD stores unpeeled object names; and\n>  - \"git pull\" learns --verify option.\n\nYes. I think that would indeed solve everything.\n\n> Then\n>\n>  $ git pull --verify rusty rusty@rustcorp.com.au-v3.1-8068-g5087a50\n>\n> could integrate the history leading to that tag to your current branch\n> while running verify-tag on it.\n\nAgreed. The only remaining issue then would be how that \"yes, I\nverified the tag\" part would be actually saved for posterity. My\nsuggestion would be to to just punt that question, and let the user\ndecide, by simply:\n\n - start the editor by default with \"--verify\"\n\n - output the \"gpg --verify\" result into the end of the commit file,\nalong with the tag content (which has the original pgp signature, of\ncourse).\n\n - let the user decide what part of it he wants to use.\n\nIn particular, the \"gpg --verify\" result may well be something that\nthe user wants to *act* on - maybe the key didn't exist in the key\nring, or maybe it does exist but doesn't have quite enough trust and\ngpg complains about that etc etc. But that's all something that \"start\nthe editor and show the user what is up\" would let the user decide on.\n\n> For this, disabling the tag-auto-following is not necessary, as you are\n> not storing the retrieved tag anywhere.\n\nExactly,\n\n>> That said, I do think that the \"signature in the pull request\" should\n>> also \"just work\", and I'm not entirely sure which one is better.\n>\n> I do not think it is necessarily either/or choice.\n\nNo, I think we can do both, and it actually ends up being just a\nmatter of convenience which one a particular project ends up using (or\neven use both depending on preferences of particular sub-lieutenants\nwithin the project).\n\n> I wonder if an approach like the following, in addition to the three\n> things I listed above, may give us a workable solution:\n>\n>  * \"git fetch linus v3.0\" called by \"git pull --verify linus v3.0\" fetches\n>   the v3.0 unpeeled into FETCH_HEAD, GPG verifies it, creates\n>   refs/audit/$u, before running \"git merge\". $u is derived from v3.0\n>   (given tag), the identity of the GPG signer, and perhaps timestamp to\n>   make it both identifiable and unique under refs/audit/ hierarchy.\n\nSo far so good, but see above: it may turn out that the user will\n*re-verify* the key after having done some gpg action. So..\n\n>  * You \"git push origin\". This causes refs/audit/* refs that point at\n>   commits in the transferred history to auto-follow, just like the\n>   current \"git fetch $there $src:$dst\" causes refs/tags/* auto-follow.\n>   The refs/audit/* hierarchy in your public repository will be populated\n>   by lieutenant signatures.\n\nSo I don't think auto-follow is good here.\n\nI could *easily* see various companies using this for their own\ninternal audit, without really wanting to expose things outside of the\ncompany. So auto-following sounds like the wrong approach. Make it an\nexplicit \"expose audit checks\" thing.\n\n>  * (Optional) You may have signed \"git tag -s 'Linux v3.2' v3.2 master\"\n>   before you push origin out, or you may have not. Currently, you do have\n>   to \"git push origin v3.2\" separately if you did. The above auto-follow\n>   could be extended to push refs/tags/* hierarchy to eliminate this step\n>   as well.\n\nSo far I haven't really had any issues with having to do a \"git push\n--tags\" to push things out.\n\nThat said, maybe the auto-push could just be a per-repo option, and\nthen you can have it both ways.\n\n> Note that because of the way \"upload-pack\" protocol is structured, the\n> first response from \"upload-pack\" after it gets connection is the\n> advertisement of refs, and there is no way for \"fetch-pack\" to ask for\n> customized refs advertisement to it. So for this to work without incurring\n> undue overhead for normal users, we would need to exclude refs/audit/*\n> from the normal ref advertisement (i.e. \"ls-remote\" does not see it) so\n> that \"git fetch\" by casual users will not have to wait for megabytes of\n> ref advertisements before issuing its first \"want\" request.\n\nI think that would be a good thing, and make it much more palatable.\nAfter all, th elikelihood is that *nobody* will ever care about the\naudit cases at all. They are very much a \"..but what if xyz happens\"\nkind of safety net for the extreme badness, not anything you'd expect\nto use.\n\n Linus\n"},{"id":"178791","messageId":"CA+55aFyRawm9CoJMiEXDFCX4YTidPOiV4oqSS2d7nNv7Ecw8BQ@mail.gmail.com","threadId":"28805","inReplyTo":"7vvcr1f38j.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-11-03T19:09:55Z","receivedAt":"2011-11-03T19:09:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Thu, Nov 3, 2011 at 11:52 AM, Junio C Hamano wrote:\n>\n> Ahh, sorry for the noise. I realize that we already have a winner, namely,\n> the proposal outlined in your message I was responding to.\n\nNo, no, don't consider my \"put in the merge message\" a winner at all.\n\nI personally dislike it, and don't really think it's a wonderful thing\nat all. I really does have real downsides:\n\n - internal signatures really *are* a disaster for maintenance. You\ncan never fix them if they need fixing (and \"need fixing\" may well be\n\"you want to re-sign things after a repository format change\")\n\n - they are ugly as heck, and you really don't want to see them in\n99.999% of all cases.\n\nSo putting those things iin the merge commit message may have some\nupsides, but it has tons of downsides too.\n\nI think your refs/audit/ idea should be given real thought, because\nmaybe that's the right idea.\n\n Linus\n"},{"id":"178826","messageId":"20111104145908.GA3903@thunk.org","threadId":"28805","inReplyTo":"CA+55aFyRawm9CoJMiEXDFCX4YTidPOiV4oqSS2d7nNv7Ecw8BQ@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Ted Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2011-11-04T14:59:08Z","receivedAt":"2011-11-04T14:59:08Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Nov 03, 2011 at 12:09:55PM -0700, Linus Torvalds wrote:\n> I personally dislike it, and don't really think it's a wonderful thing\n> at all. I really does have real downsides:\n> \n> - internal signatures really *are* a disaster for maintenance. You\n> can never fix them if they need fixing (and \"need fixing\" may well be\n> \"you want to re-sign things after a repository format change\")\n\nNote that a repository format change will break a bunch of other\nthings as well, including references in commit descriptions (\"This\nfixes a regression introduced in commit 42DEADBEEF\") So if SHA-1 is in\ndanger of failing in way that would threaten git's use of it (highly\nunlikely), we'd probably be well advised to find a way to add a new\ncrypto checksum (i.e., SHA-256) in parallel, but keep the original\nSHA-1 checksum for UI purposes.\n\n> - they are ugly as heck, and you really don't want to see them in\n> 99.999% of all cases.\n\nSo we can make them be hidden from \"git log\" and \"gik\" by default.\nThat bit is a bit gross, I agree, but 3rd party verification really is\na good thing, which I'm hoping can be added in a relatively clean\nfashion.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"178827","messageId":"CA+55aFw6JJDkkSJnp=X4cQuibXMHVBgbQ99iPqEbd7p_7J=VfQ@mail.gmail.com","threadId":"28805","inReplyTo":"20111104145908.GA3903@thunk.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-11-04T15:14:52Z","receivedAt":"2011-11-04T15:14:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Fri, Nov 4, 2011 at 7:59 AM, Ted Ts'o wrote:\n>\n> Note that a repository format change will break a bunch of other\n> things as well, including references in commit descriptions (\"This\n> fixes a regression introduced in commit 42DEADBEEF\")\n\nNo they won't. Not if you do it right. It's easy enough to\nautomatically replace the SHA1's in the description, the same way we\nreplace everything else.\n\nReally. It's *trivial*.\n\nMaybe some current tools don't do it, but if I were to convert the\nkernel tree, I'd absolutely *require* the conversion to be done right.\nAnd \"right\" means \"don't just get the parent SHA1's right, but the\nones hiding in the description too\".\n\nAny conversion tool has to keep track of the translation from \"old\nSHA1 to new SHA1\" *anyway* because of all the other issues (ie exactly\nthings like parent pointers etc), so conversion tools by definition\nhave the information to do things like this right.\n\nBut \"internal cryptographic signatures\" are fundamentally different. A\nconversion tool *cannot* convert them, since it won't have access to\nthe private keys in question, and thus cannot fix up the signature.\n\nSure, if I do the conversion, I could make *my* signatures match. And\nthat is true for every signer out there - individually. But only\nindividually, never collectively. Sure, we could all meet in one place\nand synchronously re-sign things on our private machines with some\n\"distributed conversion tool\", but realistically that really really\ndoesn't work.\n\nIt's a fundamental problem. And it really isn't a theoretical one -\nit's one we know will happen *some* day.\n\nI haven't worried about SHA1, exactly because I know it's not a real\nproblem - we can always convert. But internal signatures very\nfundamentally change that.\n\nAnd it really is about *internal* signatures. The kinds of signed tags\nwe have now are not a problem. Those can trivially be converted in a\ndistributed manner, exactly because they are \"detatched\" from what\nthey sign. We carry them along with the git repo, but they don't mess\nup history, and they can be re-created individually without changing\nanything else.\n\nAnd yes, this was actually a design issue for me, which is why I feel\nso strongly about it. I actually *thought* about issues like this\nfive+ years ago: I wanted to have cryptographic security, but I very\nmuch on purpose wanted it to be \"outside\" the repo.\n\n(Ok, so the git tag objects can sign other git tag objects\nrecursively, and in that case you have an ordering issue where a\nconversion would first have to get somebody to re-sign their \"inner\"\ntag before the \"outer\" signature can be re-created, but even if that\nwere to happen - and I don't think anybody does it - it's a trivial\nproblem with no real complexity issues).\n\n>>  - they are ugly as heck, and you really don't want to see them in\n>> 99.999% of all cases.\n>\n> So we can make them be hidden from \"git log\" and \"gik\" by default.\n> That bit is a bit gross, I agree, but 3rd party verification really is\n> a good thing, which I'm hoping can be added in a relatively clean\n> fashion.\n\nI agree that we can hide them - that's after all what the pgpsig thing\ndoes in the \"internal commit signature\" that git has in pu/next. That\none hides ie even more specifically, by putting it in the headers of\nthe commit, but that's just a random implementation detail.\n\nBut I really think that \"internal signatures\" that actually affect the\nSHA1 of the object and its history have fundamental design problems.\nThey may not be \"insurmountably bad\", but they are definitely real.\n\n Linus\n"},{"id":"178854","messageId":"7vlirvbq47.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"CA+55aFzstE-+NzfSAWMEokB7-rYsZOcZe9Ez-LxPNOKnciJ3UQ@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-04T20:16:08Z","receivedAt":"2011-11-04T20:16:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> So I suspect we should just apply this patch, but I didn't check\n> exacty what the failed tests are - except for the first one, that just\n> compares against a canned response (and the canned response should\n> just be changed).\n\nAfter applying your patch and running\n\n$ perl -pi -e 'if (/\\ttag /) {\n s/754b754407bf032e9a2f9d5a9ad05ca79a6b228f/6c9dec2b923228c9ff994c6cfe4ae16c12408dc5/;\n s/0567da4d5edd2ff4bb292a465ba9e64dcad9536b/c61a82b60967180544e3c19f819ddbd0c9f89899/;\n s/6134ee8f857693b96ff1cc98d3e2fd62b199e5a8/525b7fb068d59950d185a8779dc957c77eed73ba/;\n}' t/t5515/fetch.*\n\nto unpeel the three tags used in the test 5515 that used to expect\nFETCH_HEAD to have peeled tags to expect tag objects themselves instead,\nall tests passes.\n\n> although I suspect it was just a fairly mindless case of \"make it a\n> commit, because the merge needs the commit\" - never mind that the\n> merge would peel it anyway.\n\nI am 100% sure the machinery that comes up with the tree (or half-merged\nconflicted state) does not mind being fed tags. After all they need to\npeel them down to commits for common ancestor discovery, and they need to\nfurther peel them down to trees to perform three-way merges.\n\nHowever we would need to audit so that we do not accidentally record the\ntag object names in the \"parent\" headers in the merge commits, which is\nwhat I'll be doing next.\n"},{"id":"178856","messageId":"7vaa8bbni3.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"7v62j1gitn.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-04T21:12:36Z","receivedAt":"2011-11-04T21:12:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Linus Torvalds writes:\n>\n>> [torvalds@i5 linux]$ git fetch\n>> git://github.com/rustyrussell/linux.git\n>> rusty@rustcorp.com.au-v3.1-8068-g5087a50\n>> fatal: Couldn't find remote ref rusty@rustcorp.com.au-v3.1-8068-g5087a50\n>>\n>> oops. Ok, so his tag naming is *really* akward. Whatever.\n>\n> It is not \"Whatever\".\n>\n> $ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git v3.0\n> fatal: Couldn't find remote ref v3.0\n>\n> I do not think we ever DWIMmed fetch refspecs to prefix refs/tags/, so it\n> is not the naming but fetching tags without saying \"git fetch tag v3.0\"\n> (which IIRC was your invention long time ago). \n\nIf we really wanted to go this route, the attached single-liner should be\nsufficient for the DWIMmery.\n\nNote that the DWIMmery rules for \"git fetch\" and local \"git rev-parse\" are\nstill different even after this patch.\n\n\"git log frotz\" can DWIM to \"refs/remotes/frotz/HEAD\", but in the remote\naccess context, \"git fetch frotz\" to fetch what the other side happened to\nhave fetched from what it calls 'frotz' (which may not have any relation\nto what we consider is 'frotz') the last time would not make much sense,\nso the fetch rules table does not include \"refs/remotes/%.*s/HEAD\".\n\nWhen the user really wants to, \"git fetch $there remotes/frotz/HEAD\" would\nlet her do so anyway, so this is not about safety or security; it merely\nis about confusion avoidance and discouraging meaningless usage.\n\nSpecifically, it is _not_ about ambiguity avoidance. A name that would\nbecome ambiguous if we use the same rules table for both fetch and local\nrev-parse would be ambiguous locally at the remote side.\n\nIf we really wanted to, we could \n\n\t#define ref_fetch_rules ref_rev_parse_rules\n \nin cache.h and remove the array's declaration from cache.h and its\ndefinition from refs.c to really unify the two, but I haven't thought\nthings through.\n\n-- >8 --\nSubject: [PATCH] fetch: allow \"git fetch $there v1.0\" to fetch a tag\n\nYou can already do so with \"git fetch $there tags/v1.0\" but if it is not\nambiguous there is no reason to force users to type more.\n\nSigned-off-by: Junio C Hamano \n---\n refs.c | 1 +\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\ndiff --git a/refs.c b/refs.c\nindex e69ba26..670a7b3 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -1001,6 +1001,7 @@ const char *ref_rev_parse_rules[] = {\n const char *ref_fetch_rules[] = {\n \t\"%.*s\",\n \t\"refs/%.*s\",\n+\t\"refs/tags/%.*s\",\n \t\"refs/heads/%.*s\",\n \tNULL\n };\n-- \n1.7.8.rc0.108.g71b5ec\n"},{"id":"178857","messageId":"7v39e3bn1n.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"7vlirvbq47.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"junio@pobox.com","sentAt":"2011-11-04T21:22:28Z","receivedAt":"2011-11-04T21:22:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> However we would need to audit so that we do not accidentally record the\n> tag object names in the \"parent\" headers in the merge commits, which is\n> what I'll be doing next.\n\nJust reporting my findings.\n\nbuiltin/merge.c was updated to use want_commit() that uses peel_to_type()\nto commit to make sure we do not get fed anything funky, and also uses\nstruct commit_list to pass around list of parents to be recorded, so we\nshould be OK in this department.\n"},{"id":"178861","messageId":"CA+55aFzKPPqwGOe5Ov0FHF1DHbKmNhm=ePvcaY5uqR7cwFhQGQ@mail.gmail.com","threadId":"28805","inReplyTo":"7v39e3bn1n.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-11-04T23:10:59Z","receivedAt":"2011-11-04T23:10:59Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Fri, Nov 4, 2011 at 2:22 PM, Junio C Hamano wrote:\n>\n> builtin/merge.c was updated to use want_commit() that uses peel_to_type()\n> to commit to make sure we do not get fed anything funky, and also uses\n> struct commit_list to pass around list of parents to be recorded, so we\n> should be OK in this department.\n\nI'm pretty sure people have already done \"git merge v3.1\" kind of\nthings using local tags (where no peeling of FETCH_HEAD has been\ndone). See\n\n git log --merges --grep 'Merge.*v[23]\\.[0-9]'\n\nfor a ton of examples of this (and there's something odd going on: we\nhave \"Merge commit ..\" and \"Merge tag ..\", and I suspect the latter is\npeople editing it to be correct by hand, but I dunno).\n\nSo this has always worked, methinks.\n\nHowever - exactly beause git apparently makes it do that \"Merge commit\n\" message, I suspect we've peeled things too early and too much. We've\npeeled it so early that once again something thinks it's a commit, not\na tag.\n\nSo if anything, I suspect \"git merge\" not only peels, but peels too\nmuch (or at the wrong point). We should probably peel as late as\npossible.\n\nBut it's a small detail.\n\n Linus\n"},{"id":"178862","messageId":"CA+55aFzCuEG7ZpSJ5BLFF3Rfe1Tqjr82fUwFGJTqMvzB=fbVcA@mail.gmail.com","threadId":"28805","inReplyTo":"7vaa8bbni3.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-11-04T23:45:10Z","receivedAt":"2011-11-04T23:45:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Fri, Nov 4, 2011 at 2:12 PM, Junio C Hamano wrote:\n>\n> If we really wanted to go this route, the attached single-liner should be\n> sufficient for the DWIMmery.\n\nMy first reaction on reading the patch was \"maybe it would be safer to\nput the tags case after 'branches', so that the behavior in the\npresense of ambiguity would stay the same as with the old case\", but\nthinking it through I think it's more important to be consistent with\nthe other lookups, which all prefer tags over branches when ambiguous.\n\nSo Ack, patch looks sane to me, and clearly makes it easier to fetch\ntags individually.\n\n Linus\n"},{"id":"178869","messageId":"20111105035542.GA1974@sigill.intra.peff.net","threadId":"28805","inReplyTo":"CA+55aFzKPPqwGOe5Ov0FHF1DHbKmNhm=ePvcaY5uqR7cwFhQGQ@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-11-05T03:55:42Z","receivedAt":"2011-11-05T03:55:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 04, 2011 at 04:10:59PM -0700, Linus Torvalds wrote:\n\n> I'm pretty sure people have already done \"git merge v3.1\" kind of\n> things using local tags (where no peeling of FETCH_HEAD has been\n> done). See\n> \n> git log --merges --grep 'Merge.*v[23]\\.[0-9]'\n> \n> for a ton of examples of this (and there's something odd going on: we\n> have \"Merge commit ..\" and \"Merge tag ..\", and I suspect the latter is\n> people editing it to be correct by hand, but I dunno).\n\nIt looks like fmt-merge-msg looks in FETCH_HEAD to see if each line is\nmarked as \"branch\" or \"tag\". So I get \"Merge tag ...\" with:\n\n git pull . tag v1.0\n\nbut I get \"Merge commit ...\" with:\n\n git merge v1.0\n\nWhen \"git merge\" is run, it actually creates a fake FETCH_HEAD in memory\nand feeds it to fmt-merge-msg. But that process doesn't seem to bother\nlooking at tags. I think we just need this:\n\n---\ndiff --git a/builtin/merge.c b/builtin/merge.c\nindex dffd5ec..6a44b6d 100644\n--- a/builtin/merge.c\n+++ b/builtin/merge.c\n@@ -439,10 +439,15 @@ static void merge_name(const char *remote, struct strbuf *msg)\n \t\tif (!prefixcmp(found_ref, \"refs/heads/\")) {\n \t\t\tstrbuf_addf(msg, \"%s\\t\\tbranch '%s' of .\\n\",\n \t\t\t\t sha1_to_hex(branch_head), remote);\n \t\t\tgoto cleanup;\n \t\t}\n+\t\tif (!prefixcmp(found_ref, \"refs/tags/\")) {\n+\t\t\tstrbuf_addf(msg, \"%s\\t\\ttag '%s' of .\\n\",\n+\t\t\t\t sha1_to_hex(branch_head), remote);\n+\t\t\tgoto cleanup;\n+\t\t}\n \t\tif (!prefixcmp(found_ref, \"refs/remotes/\")) {\n \t\t\tstrbuf_addf(msg, \"%s\\t\\tremote-tracking branch '%s' of .\\n\",\n \t\t\t\t sha1_to_hex(branch_head), remote);\n \t\t\tgoto cleanup;\n \t\t}\n\nwhere the result of merge_name is just fed to fmt-merge-msg eventually.\n\n-Peff\n"},{"id":"178870","messageId":"7vipmz9oca.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"CA+55aFzKPPqwGOe5Ov0FHF1DHbKmNhm=ePvcaY5uqR7cwFhQGQ@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-05T04:37:25Z","receivedAt":"2011-11-05T04:37:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> However - exactly beause git apparently makes it do that \"Merge commit\n> \" message, I suspect we've peeled things too early and too much. We've\n> peeled it so early that once again something thinks it's a commit, not\n> a tag.\n\nAnd you are right.\n\nI am working on a larger series that should sit on top of 89587fa (Split\nGPG interface into its own helper library, 2011-09-07), which is the first\ncommit in jc/signed-commit topic.\n\n-- >8 --\nSubject: [PATCH] merge: notice local merging of tags and keep it unwrapped\n\nSigned-off-by: Junio C Hamano \n---\n builtin/merge.c | 5 +++++\n 1 files changed, 5 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin/merge.c b/builtin/merge.c\nindex f61b367..ce3b4f8 100644\n--- a/builtin/merge.c\n+++ b/builtin/merge.c\n@@ -428,6 +428,11 @@ static void merge_name(const char *remote, struct strbuf *msg)\n \t\t\t\t sha1_to_hex(branch_head), remote);\n \t\t\tgoto cleanup;\n \t\t}\n+\t\tif (!prefixcmp(found_ref, \"refs/tags/\")) {\n+\t\t\tstrbuf_addf(msg, \"%s\\t\\ttag '%s' of .\\n\",\n+\t\t\t\t sha1_to_hex(branch_head), remote);\n+\t\t\tgoto cleanup;\n+\t\t}\n \t\tif (!prefixcmp(found_ref, \"refs/remotes/\")) {\n \t\t\tstrbuf_addf(msg, \"%s\\t\\tremote-tracking branch '%s' of .\\n\",\n \t\t\t\t sha1_to_hex(branch_head), remote);\n-- \n1.7.8.rc0.108.g71b5ec\n\n"},{"id":"178883","messageId":"7v1utn9it8.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"CA+55aFyRawm9CoJMiEXDFCX4YTidPOiV4oqSS2d7nNv7Ecw8BQ@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-05T06:36:51Z","receivedAt":"2011-11-05T06:36:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Thu, Nov 3, 2011 at 11:52 AM, Junio C Hamano wrote:\n>>\n>> Ahh, sorry for the noise. I realize that we already have a winner, namely,\n>> the proposal outlined in your message I was responding to.\n>\n> No, no, don't consider my \"put in the merge message\" a winner at all.\n>\n> I personally dislike it, and don't really think it's a wonderful thing\n> at all. I really does have real downsides:\n>\n> - internal signatures really *are* a disaster for maintenance. You\n> can never fix them if they need fixing (and \"need fixing\" may well be\n> \"you want to re-sign things after a repository format change\")\n>\n> - they are ugly as heck, and you really don't want to see them in\n> 99.999% of all cases.\n>\n> So putting those things iin the merge commit message may have some\n> upsides, but it has tons of downsides too.\n>\n> I think your refs/audit/ idea should be given real thought, because\n> maybe that's the right idea.\n\nWhile I agree that re-signing is a problem, I do not see it as a huge\nissue. In your \"SHA-1 to SHA-256 transtion\" scenario, the conversion is a\nflag day event in the hopefully fairly distant (in the git timescale)\nfuture, and I am reasonably sure that by that time we would already have\ninfrastructure updates necessary to support huge number of refs, including\nthe \"lazily scan only the refs necessary\" and the \"some refs are optional\nin advertisement\" topics that are useful for other purposes.\n\nIn the worst case, even if we used your \"merge commit records the merged\ntag as the record of requested pull\" design today, we could choose not to\nrewrite these in-merge-commit signatures when the conversion becomes\nnecessary. Instead, the conversion procedure can prepare a mapping table\nbetween the old SHA-1 and the rewritten SHA-256, and contributors can\nprepare detached signature for the mappings of their own commits after\nverifying that the conversion produced what they are happy with. And then\nwe store concatenation of these detached signatures in a blob to help\nfuture third party auditors to audit these (by-then) historical commits.\n\nAbout the ugliness of the merge commit log messages, you have already\nlearned to ignore them with \"log --no-merges\" ;-) and the material the\npatch series I sent out adds are at the end, so \"/^commit.*$\" in less\nwould hopefully work well enough in \"log --no-merges\" as well.\n\nBecause the refs/audit/ approach requires too much infrastructure we still\ndo not have today, and workflow elements are not fully worked out\n(e.g. propagating audit trails fully from sub-sub-sub-...-lieutenants\nupwards is tricky as I outlined in the other message), I think we should\nstart from a design that we can see how it would work now.\n\nWith the posted series, the workflow would become something like this:\n\n contributor$ work work work\n\n contributor$ git tag -s -m 'Signed pull\n\n This series is to allow the integrator to pull from contributors\n by specifying a signed tag, not the tip of the branch, and verify\n the authenticity of the series while merging' for-linus\n\n contributor$ git push public for-linus\n\n contributor$ git request-pull origin \\\n $(git config remote.public.url) for-linus >msg\n contributor$ edit msg\n contributor$ mail torvalds@...\n\n integrator$ mail ;# read the pull request\n integrator$ git pull git://github.com/contributor/linux.git for-linus\n ... editor opens with the usual merge message, but with\n ... the contents of the tag and the \"GPG verify\" result at\n ... the end.\n\nIt might make sense to also teach the \"git tag\" part somehow use branch\ndescription of the tip of branch being tagged to prime the tag message.\n"},{"id":"178917","messageId":"CA+55aFy0gA0ROSyE03h6Lw0zn4B4j-oEFBmffOcWs6NfyYy8JA@mail.gmail.com","threadId":"28805","inReplyTo":"7v1utn9it8.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-11-05T16:41:25Z","receivedAt":"2011-11-05T16:41:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Fri, Nov 4, 2011 at 11:36 PM, Junio C Hamano wrote:\n>\n> About the ugliness of the merge commit log messages, you have already\n> learned to ignore them with \"log --no-merges\" ;-)\n\nAbsolutely not. I look at merges all the time. I never use\n\"--no-merges\" except when I'm doing certain statistics (ie \"How many\nreal changes do we have\") or when I do release files.\n\nBut I actually think it's important that people write *good* merge\nmessages. I've berated some people for it when they just have\n\n Merge branch 'origin'\n\nin their commit message, because I think a merge commit should say why\nit happened or what it brought in.\n\n> and the material the\n> patch series I sent out adds are at the end, so \"/^commit.*$\" in less\n> would hopefully work well enough in \"log --no-merges\" as well.\n\nI agree that being at the end helps, but I do a lot of \"git log\nORIG_HEAD..\" etc, and I don't do a lot of \"/^commit\" searching.\n\nThe \"/commit\" thing I do tends to be because I do \"git log -p\" to see\npatches, but at the same time am not going to read through\neverything..\n\nSo I'd really like some way to not see it.\n\nTed suggested a NUL character in the commit message in front of the\n\"hidden content\". What do you think?\n\n Linus\n"},{"id":"178931","messageId":"7vsjm2870k.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"CA+55aFy0gA0ROSyE03h6Lw0zn4B4j-oEFBmffOcWs6NfyYy8JA@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"junio@pobox.com","sentAt":"2011-11-05T23:49:15Z","receivedAt":"2011-11-05T23:49:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> So I'd really like some way to not see it.\n>\n> Ted suggested a NUL character in the commit message in front of the\n> \"hidden content\". What do you think?\n\nYou do not have to resort to NUL; we could just stuff whatever you do not\nneed to see but needs to be left *intact* in the new header fields just\nlike the embedded GPG signatures are stored in signed commits.\n\nBy the time the integrator is presented the merge commit template, we\nwould have:\n\n 1. The merge title (e.g. \"Merge tag for-linus of git://.../rusty.git/\");\n\n 2. Payload of the signed tag (or just \"annotated tag\"), which is used to\n convey meaningful topic description from the lieutenant;\n\n 3. The signature in the tag, if the tag is not just merely annotated, but\n is signed;\n\n 4. The output from GPG verification of the above (only when 3. is\n available); and\n\n 5. The traditional \"merge summary\", if merge.log is enabled.\n\nThe 10-patch series I sent earlier appends 2 and 3 with \"tag:\" prefix and\n4 with \"# \" prefix in the commit log template, but it does not have to be\nthat way. We could arrange things so that we put only 1, 2, 4 (still with\n\"# \" prefix because this is meant to help you verify the authenticity, not\nfor later third-party audit, and to be stripped away with stripspace\nbefore the commit is made) and 5 in the commit log template, and the\noriginal signed tag contents (only when the tag is signed, not merely\nannotated) in a separate file MERGE_SIG in $GIT_DIR/ next to MERGE_MSG,\nand teach \"git commit\" to pick it up and stuff it in a new header field.\n\nThat way, the integrator can use the message 2 for the commit log message\nand is free to typofix it, without breaking later third-party audit which\nwould use what is taken literally from the signed tag and stored in the\nnew header field, because the integrator's editor would never touch the\nlatter.\n"},{"id":"178942","messageId":"CA+55aFzxmDC407EDcm8MV55R7BnRhuxuTOyhZ-jyg2q39=NKfw@mail.gmail.com","threadId":"28805","inReplyTo":"7vsjm2870k.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-11-06T00:53:30Z","receivedAt":"2011-11-06T00:53:30Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Sat, Nov 5, 2011 at 4:49 PM, Junio C Hamano wrote:\n>\n> You do not have to resort to NUL; we could just stuff whatever you do not\n> need to see but needs to be left *intact* in the new header fields just\n> like the embedded GPG signatures are stored in signed commits.\n\nAgreed, [ details removed ] that sounds perfect. And makes it easy to\nget at if you want to with just \"git cat-file commit\" - without ever\nreally being visible to people who don't care. And having it visible\nin the editor with '#' means that the user who does the merge gets to\nsee what actually ended up being put in there, along with the fact\nthat yes, it verified correctly.\n\nSo I think I really like that approach - it seems to solve all problems.\n\n Linus\n"},{"id":"179007","messageId":"22879.1320652337@turing-police.cc.vt.edu","threadId":"28805","inReplyTo":"CA+55aFw6JJDkkSJnp=X4cQuibXMHVBgbQ99iPqEbd7p_7J=VfQ@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"","fromEmail":"valdis.kletnieks@vt.edu","sentAt":"2011-11-07T07:52:17Z","receivedAt":"2011-11-07T07:52:17Z","isPatch":false,"sender":{"key":"valdis.kletnieks@vt.edu","avatar":null},"body":"On Fri, 04 Nov 2011 08:14:52 PDT, Linus Torvalds said:\n> On Fri, Nov 4, 2011 at 7:59 AM, Ted Ts'o wrote:\n> > Note that a repository format change will break a bunch of other\n> > things as well, including references in commit descriptions (\"This\n> > fixes a regression introduced in commit 42DEADBEEF\")\n\n> No they won't. Not if you do it right. It's easy enough to\n> automatically replace the SHA1's in the description, the same way we\n> replace everything else.\n\nOK.. I'll bite. How do you disambiguate a '42deadbeef' in the changelog part\nof a commit as being a commit ID, as opposed to being an address in a traceback\nor something similar? Yes, I know you only change the ones that actually map to\na commit ID, but I'd not be surprised if by now we've got enough commits and\nstack tracebacks in the git history that we'll birthday-paradox ourselves into\na false-positive in an automatic replacement.\n\n(And it's OK to say \"the 3 stack tracebacks in changelogs we just mangled can\njust go jump\", but it does need at least a few seconds consideration..)\n\n"},{"id":"179042","messageId":"CA+55aFyKocxDUD2YhhBhfDzp+WHOddOZ_3mfqwADri86aUOUFQ@mail.gmail.com","threadId":"28805","inReplyTo":"22879.1320652337@turing-police.cc.vt.edu","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2011-11-07T16:24:34Z","receivedAt":"2011-11-07T16:24:34Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Sun, Nov 6, 2011 at 11:52 PM, wrote:\n>\n> OK.. I'll bite.  How do you disambiguate a '42deadbeef' in the changelog part\n> of a commit as being a commit ID, as opposed to being an address in a traceback\n> or something similar? Yes, I know you only change the ones that actually map to\n> a commit ID, but I'd not be surprised if by now we've got enough commits and\n> stack tracebacks in the git history that we'll birthday-paradox ourselves into\n> a false-positive in an automatic replacement.\n\nI don't think we are quite there yet. And (sadly) most of the commit\nID's in the history are 7 hex characters, because that used to be the\ndefault git abbreviation. So there is unlikely to be any real\nconflicts.\n\nIf we do miss one or two, that will be sad and embarrassing, but is\nnot a real problem in practice.\n\nWe probably could add various heuristics (the SHA1 values are *often*\npreceded by the string \"commit\"), and a really good import would also\nhave somebody at least visually inspecting ones that other heuristics\nsay might be debatable (for example - because they have 8 hex digits\nand there are other numbers around them that were *not* converted),\nbut in the end perfection is the enemy of good. It's not really worth\nthe headache to worry about *all* the cases, if you can cheaply and\nsimply get 99+% right.\n\nAnd I think the 99% is almost trivial. While the last 1% may or may\nnot be worth worrying about.\n\n Linus\n"},{"id":"179212","messageId":"7v4nydurzh.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"CA+55aFyRawm9CoJMiEXDFCX4YTidPOiV4oqSS2d7nNv7Ecw8BQ@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-09T17:26:42Z","receivedAt":"2011-11-09T17:26:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> No, no, don't consider my \"put in the merge message\" a winner at all.\n>\n> I personally dislike it, and don't really think it's a wonderful thing\n> at all. I really does have real downsides:\n>\n> - internal signatures really *are* a disaster for maintenance. You\n> can never fix them if they need fixing (and \"need fixing\" may well be\n> \"you want to re-sign things after a repository format change\")\n>\n> - they are ugly as heck, and you really don't want to see them in\n> 99.999% of all cases.\n>\n> So putting those things iin the merge commit message may have some\n> upsides, but it has tons of downsides too.\n>\n> I think your refs/audit/ idea should be given real thought, because\n> maybe that's the right idea.\n\nWith the latest round of touch-ups, modulo a few bugs I will be fixing\nbefore the 1.7.8 final, I think what we have is more or less OK in the\nshorter term and should be ready for general consumption. The ugliness is\ngone, but the issue around internal signatures may remain to be solved in\nthe longer term. At least, by storing the full contents of the tag today\nin an extended header, when we figure out how a detached signature should\nreally work, we could convert by extracting them from the history.\n\nIn a separate message earlier in the thread, you raised another issue.\n\n> I hate how anonymous our branches are. Sure, we can use good names for\n> them, but it was a mistake to think we should describe the repository\n> (for gitweb), rather than the branch.\n> \n> Ok, \"hate\" is a strong word. I don't \"hate\" it. I don't even think\n> it's a major design issue. But I do think that it would have been\n> nicer if we had had some branch description model.\n\nAt the first glance, our branch model is indeed peculiar in that a branch\ndoes not have a global identity. The scope of its name is local to the\nrepository, and it is just a pointer into the history. A \"note\" [*1*] that\ncan annotate a commit long after the commit is made is not a good way to\ndescribe what a branch is about, because the tip of the branch can advance\nbeyond the commit that is annotated by such a note. A commit on a branch\ndoes not serve as a good anchoring point to describe the branch.\n\nHowever, a commit that merges the history of a branch, whether the merged\nbranch is from a local repository or from a remote one, does serve as a\ngood anchoring point. The work on a branch is finished as complete as\npossible at the time of the merge, and the committer who merges the branch\nagrees with both the objective and the implementation of the work done on\nthe branch, and that is why the merge is made [*2*]. Describing what the\nhistory of the side branch was about in the resulting merge is a perfectly\nsensible way to explain the branch. So in that sense, I am very happy with\nthe way the merge message template uses the pull request tag to let the\nlieutenant explain and defend the history behind the tag used for the pull\nrequest. Such an explanation does not have to be keyed with anybody's\nlocal branch name (e.g. \"for-linus\" would mean different things for\ndifferent pull requests even from the same person), but keying it with the\nresulting merge commit is a sensible way to leave the record in the\nhistory.\n\nAfter justifying with the above two paragraphs that it is perfectly\nsensible to record the annotations on commits and not on \"branch names\", I\ndo agree that we would eventually want to be able to have such annotations\non commits after the fact. Neither \"tags\" nor \"notes\" is necessarily a\nvery good mechanism, however, for the purpose of \"signed pull requests\"\nand \"signed commits\" [*3*]. Here are some pros and cons:\n\n - tags must be named, but the only thing we need is to be able to look\n the contents (with signature if signed) up given a commit object.\n Unlike the usual \"I want to check out v3.0 release\" look-up that goes\n from tag names to the commits, annotation look-ups go the other way, do\n not have to have a tagname, and having tagname does not help our\n look-up in any way. If we want to use tag to annotate various commits\n by various people and keep them around, we would need global namespace\n that would not cause them to crash (we can work this around by using\n the object name of the tag, e.g. renaming 'for-linus' tag to $(git\n rev-parse tags/for-linus), but that is merely a workaround of having to\n name things that do not have to be named in the first place). As a\n local storage machinery for annotations, tags hanging below refs/tags/\n (or refs/audit for that matter) hierarchy with their own names is an\n inappropriate model.\n\n + tags can auto-follow the commits when object transfer happens (at least\n in the fetch direction), and for the purpose of \"signed pull requests\"\n and \"signed commits\", this is a desirable property. When a repository\n gains a commit, the annotations attached to the commit that are missing\n from the receiving repository are automatically transferred from the\n place the commit comes from. Annotations given to other commits that\n are not transferred into the repository do not come to the repository.\n\n - \"git notes\" is represented as a commit that records a tree that holds\n the entire mapping from commit to its annotations, and the only way to\n transferr it is to send it together with its history as a whole. It\n does not have the nice auto-following property that transfers only the\n relevant annotations.\n\n + \"git notes\" maps the commits to its annotations in the right direction;\n the object name of an annotated object to its annotation.\n\nIn the longer term, I think we would need to extend the system in the\nfollowing way:\n\n - Introduce a mapping machanism that can be locally used to map names of\n the objects being annotated to names of other objects (most likely\n blobs but there is nothing that fundamentally prevents you from\n annotating a commit with a tree). The current \"git notes\" might be a\n perfectly suitable representation of this, or it may turn out to be\n lacking (I haven't thought things through), but the important point is\n that this \"mapping store\" is _local_. fsck, repack and prune need to be\n told that objects that store the annotation are reachable from the\n annotated objects.\n\n - Introduce a protocol extension to transfer this mapping information for\n objects being transferred in an efficient way. When \"rev-list --objects\n have..want\" tells us that the receiving end (in either fetch/push\n direction) would have an object at the end of the primary transfer\n (note that I did not say \"an object will be sent in this transfer\n transaction\"; \"have\" does not come into the picture), we make sure that\n missing annotations attached to the object is also transferred, and new\n mapping is registered at the receiving end.\n\nThe detailed design for the latter needs more thought. The auto-following\nof tags works even if nothing is being fetched in the primary transfer\n(i.e. \"git fetch\" && \"git fetch\" back to back to update our origin/master\nwith the master at the origin) when a new tag is added to ancient part of\nthe history that leads to the master at the origin, but this is exactly\nbecause the sending end advertises all the available tags and the objects\nthey point at so that we can tell what new tags added to an old object is\nmissing from the receiving end. This obviously would not scale well when\nwe have tens of thousands of objects to annotate. Perhaps an entry in the\n\"mapping store\" would record:\n\n - The object name of the object being annotated;\n\n - The object name of the annotation;\n\n - The \"timestamp\", i.e. when the association between the above two was\n made--this can be local to the repository and a simple counter would\n do.\n\nand also maintain the last \"timestamp\" this repository sent annotations to\nthe remote (one timestamp per remote repository). When we push, we would\nsend annotations pertaining to the object reachable from what we are\npushing (not limited by what they already have, as the whole point of this\nexercise is to allow us to transfer annotations added to an object long\nafter the object was created and sent to the remote) that is newer than\nthat \"timestamp\". Similarly, when fetching, we would send the \"timestamp\"\nthis repository last fetched annotations from the other end (which means\nwe would need one such \"timestamp\" per remote repository) and let the\nremote side decide the set of new annotations they added since we last\nsynched that are on objects reachable from what we \"want\".\n\nOr something like that.\n\n[Footnote]\n\n*1* By this word, I do not necessarily mean what the \"git notes\" command\nmanipulates. A tag that points at a commit is also equally a good vehicle\nto annotate a commit after the fact.\n\n*2* For this reason, it may make sense to \"commit -S\" such a merge\ncommit. The \"mergetag\" asserts the authenticity of the pull request from\nthe lieutenant whose history is being integrated, and the \"gpgsig\" asserts\nthe authenticity of the merge itself--the fact that it was made by the\nintegrator.\n\n*3* I do not mean what \"git commit -S\" parked in 'pu' produces, which is\nto store the signature in the commit. Adding \"Signed-off-by:\" after the\nfact to an existing commit by many people is a more appropriate example.\n\n"},{"id":"179265","messageId":"CALKQrgfZtELcK3H5ZYvmcW8RrtKMVRACFTvw3s5SidFvmFWkGw@mail.gmail.com","threadId":"28805","inReplyTo":"7v4nydurzh.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-11-10T08:02:53Z","receivedAt":"2011-11-10T08:02:53Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wed, Nov 9, 2011 at 18:26, Junio C Hamano wrote:\n>  - \"git notes\" is represented as a commit that records a tree that holds\n>   the entire mapping from commit to its annotations, and the only way to\n>   transferr it is to send it together with its history as a whole. It\n>   does not have the nice auto-following property that transfers only the\n>   relevant annotations.\n\nTrue. However, consider these mitigating factors:\n\n - The annotations in question (the \"signing\" of commits) are all intended to\n be merged eventually (i.e. there is no reason for a developer to (after the\n fact) sign a commit that will never end up in the public record). Therefore,\n most or all of the notes in the notes tree are already relevant, or\nwill become\n relevant in the near future (when the associated commits are merged).\n\n - Additionally, you could organize these notes into two (or more) notes trees,\n one for merged/official annotations, and one for unmerged/pending\nannotations.\n Then make the relevant tools (e.g. \"git merge\") transfer notes from one tree\n to the other, thereby making sure that the \"official\" record only contains\n notes that are relevant to the merged history.\n\n - Finally, there's always \"git notes prune\" to purge annotations for commits\n that ended up never being merged.\n\nMy point is that although \"notes\" might end up transferring more annotations\nthan strictly necessary, I believe that in practice all the notes\nbeing transferred\nare already (or will soon become) relevant.\n\n>  + \"git notes\" maps the commits to its annotations in the right direction;\n>   the object name of an annotated object to its annotation.\n>\n> In the longer term, I think we would need to extend the system in the\n> following way:\n>\n>  - Introduce a mapping machanism that can be locally used to map names of\n>   the objects being annotated to names of other objects (most likely\n>   blobs but there is nothing that fundamentally prevents you from\n>   annotating a commit with a tree). The current \"git notes\" might be a\n>   perfectly suitable representation of this, or it may turn out to be\n>   lacking (I haven't thought things through), but the important point is\n>   that this \"mapping store\" is _local_. fsck, repack and prune need to be\n>   told that objects that store the annotation are reachable from the\n>   annotated objects.\n\nIMHO this is precisely what \"git notes\" does today.\n\n>  - Introduce a protocol extension to transfer this mapping information for\n>   objects being transferred in an efficient way. When \"rev-list --objects\n>   have..want\" tells us that the receiving end (in either fetch/push\n>   direction) would have an object at the end of the primary transfer\n>   (note that I did not say \"an object will be sent in this transfer\n>   transaction\"; \"have\" does not come into the picture), we make sure that\n>   missing annotations attached to the object is also transferred, and new\n>   mapping is registered at the receiving end.\n>\n> The detailed design for the latter needs more thought. The auto-following\n> of tags works even if nothing is being fetched in the primary transfer\n> (i.e. \"git fetch\" && \"git fetch\" back to back to update our origin/master\n> with the master at the origin) when a new tag is added to ancient part of\n> the history that leads to the master at the origin, but this is exactly\n> because the sending end advertises all the available tags and the objects\n> they point at so that we can tell what new tags added to an old object is\n> missing from the receiving end. This obviously would not scale well when\n> we have tens of thousands of objects to annotate. Perhaps an entry in the\n> \"mapping store\" would record:\n>\n>  - The object name of the object being annotated;\n>\n>  - The object name of the annotation;\n>\n>  - The \"timestamp\", i.e. when the association between the above two was\n>   made--this can be local to the repository and a simple counter would\n>   do.\n>\n> and also maintain the last \"timestamp\" this repository sent annotations to\n> the remote (one timestamp per remote repository). When we push, we would\n> send annotations pertaining to the object reachable from what we are\n> pushing (not limited by what they already have, as the whole point of this\n> exercise is to allow us to transfer annotations added to an object long\n> after the object was created and sent to the remote) that is newer than\n> that \"timestamp\". Similarly, when fetching, we would send the \"timestamp\"\n> this repository last fetched annotations from the other end (which means\n> we would need one such \"timestamp\" per remote repository) and let the\n> remote side decide the set of new annotations they added since we last\n> synched that are on objects reachable from what we \"want\".\n>\n> Or something like that.\n\nYou would also have to keep track of deleted annotations, to enable the local\nside to delete an annotation corresponding to an already-deleted annotation\non the remote side.\n\nPretty soon, you end up having to record something similar to a DAG,\ndescribing the history of manipulating these annotations. At that point, your\n\"timestamp\" calculation starts to look very similar to the \"have..want\"\ncalculation already done when transferring \"regular\" refs. At which point you\nhave a system that is very similar to what \"git notes\" does today...\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"179277","messageId":"1320933118.17392.23.camel@i7.infradead.org","threadId":"28805","inReplyTo":"CA+55aFyG4VuiRN3kcyDVF4sw7b89m-2bOBeQLOGWTcd9o3akzQ@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2011-11-10T13:51:58Z","receivedAt":"2011-11-10T13:51:58Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Wed, 2011-11-02 at 21:13 -0700, Linus Torvalds wrote:\n> No, my main objection to saving the data is that it's ugly and it's\n> redundant. Sure, in practice you can check the signatures later fine\n> (with the rare exceptions you mention), but even when you can do it,\n> what's the big upside? \n\nAnother objection (although it may not be insurmountable) is that it's\nnot necessarily *entirely* clear what's being signed.\n\nIn the simple case where I clone your tree, make a few commits with my\nSigned-off-by:, sign a tag and then ask you to pull, that's easy enough.\nI'm vouching for what I committed, and not for everything that was in\nyour tree beforehand.\n\nBut what if I'm working on top of someone else's published git tree?\nDoes a signed tag at the top of *my* work imply that I'm vouching for\nall of theirs too?\n\nIn the case where the signature is ephemeral and only used for you to\ntrust my pull request, the answer is simple: If that other work wasn't\nin your tree yet at the time I send my pull request, I'd damn well\nbetter be vouching for it when I ask you to pull it. Nothing new there.\n\nBut if we're keeping signatures around for auditing purposes, we'd\nbetter have a coherent answer to that question. One that isn't \"a\nsignature cover everything since the last commit with torvalds@ as the\ncommitter\", if we want it to be useful for the general case.\n\n-- \ndwmw2\n\n"},{"id":"179278","messageId":"1320933165.17392.24.camel@i7.infradead.org","threadId":"28805","inReplyTo":"CA+55aFx_rAA6TJkZn1Zvu6u9UjxnmTVt0HpMnvaE_q9Sx-jzPg@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2011-11-10T13:52:45Z","receivedAt":"2011-11-10T13:52:45Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Tue, 2011-11-01 at 14:21 -0700, Linus Torvalds wrote:\n> I hate how anonymous our branches are. Sure, we can use good names for\n> them, but it was a mistake to think we should describe the repository\n> (for gitweb), rather than the branch.\n> \n> Ok, \"hate\" is a strong word. I don't \"hate\" it. I don't even think\n> it's a major design issue. But I do think that it would have been\n> nicer if we had had some branch description model. \n\nI actually quite like it. I take it as a hint: if the contents of a\nbranch are *so* wildly different from the main repository that they need\na different description, perhaps I should be using a separate repository\ninstead of just a branch.\n\n-- \ndwmw2\n\n"},{"id":"179281","messageId":"7vaa84t3ek.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"CALKQrgfZtELcK3H5ZYvmcW8RrtKMVRACFTvw3s5SidFvmFWkGw@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"junio@pobox.com","sentAt":"2011-11-10T15:15:15Z","receivedAt":"2011-11-10T15:15:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland writes:\n\n> On Wed, Nov 9, 2011 at 18:26, Junio C Hamano wrote:\n>>  - \"git notes\" is represented as a commit that records a tree that holds\n>>   the entire mapping from commit to its annotations, and the only way to\n>>   transferr it is to send it together with its history as a whole. It\n>>   does not have the nice auto-following property that transfers only the\n>>   relevant annotations.\n>\n> True. However, consider these mitigating factors:\n> ...\n>\n> My point is that although \"notes\" might end up transferring more\n> annotations than strictly necessary, I believe that in practice all the\n> notes being transferred are already (or will soon become) relevant.\n\nSorry, but I do not think you are considering what would happen when you\nhave many branches with different purposes, whose commits near tips will\nnever get merged with each other. \"automatic following\" semantics like\nwhat \"git fetch\" does for signed tags is absolutely necessary in such a\ncase, and the above are not mitigating factors at all in that context.\n"},{"id":"179282","messageId":"4EBBEC59.3020502@xiplink.com","threadId":"28805","inReplyTo":"1320933118.17392.23.camel@i7.infradead.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-11-10T15:23:05Z","receivedAt":"2011-11-10T15:23:05Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 11-11-10 08:51 AM, David Woodhouse wrote:\n> On Wed, 2011-11-02 at 21:13 -0700, Linus Torvalds wrote:\n>> No, my main objection to saving the data is that it's ugly and it's\n>> redundant. Sure, in practice you can check the signatures later fine\n>> (with the rare exceptions you mention), but even when you can do it,\n>> what's the big upside? \n> \n> Another objection (although it may not be insurmountable) is that it's\n> not necessarily *entirely* clear what's being signed.\n\nI think this is a non-issue as far as the implementation is concerned. That\nis, the question exists regardless of what actual bits get (hashed and)\nencrypted by a private key. Furthermore, the answer will depend on who's\nusing the signatures and in what context, and it's not appropriate for the\ngit tool to make assumptions about those things.\n\n> In the simple case where I clone your tree, make a few commits with my\n> Signed-off-by:, sign a tag and then ask you to pull, that's easy enough.\n> I'm vouching for what I committed, and not for everything that was in\n> your tree beforehand.\n> \n> But what if I'm working on top of someone else's published git tree?\n> Does a signed tag at the top of *my* work imply that I'm vouching for\n> all of theirs too?\n\n\n\nIt all depends on what you mean by \"vouch for\".\n\nYou obviously thought that the 3rd-party repo was good for something,\notherwise why did you base your work on it in the first place? So maybe\nyou're just vouching for the 3rd-party repo being good enough for what you're\ntrying to do.\n\nOr, maybe you've done a thorough analysis of the 3rd-party code and are ready\nto certify it as completely memory-leak-free or something.\n\nOr or, maybe you're only making a statement about the commits that you've\nauthored yourself. (You probably want to individually sign each of those\ncommits in this case.)\n\nThese sorts of issues have been debated on PKI mailing lists ad nauseum. I\nthink the best approach is that if you want your signature to have a\nparticular meaning, then put that into some text that's part of what's being\nsigned. Let other humans read that text and make their own decisions.\n\n\n\nAnd whatever the case, the software that makes and validates the signatures\nshouldn't make any assertions about how to interpret good or bad signatures.\n (Yes, other software could interpret meanings according to some criteria,\nand that software could exist alongside or be incorporated into the basic\ndigital signature software, but the interpretation software is doing a\ndifferent job.)\n\n\t\tM.\n"},{"id":"179283","messageId":"CALKQrgdxEXQGKQ3t9Sh82=U933ypHNg8duyVmG9uJbg2iST5fw@mail.gmail.com","threadId":"28805","inReplyTo":"7vaa84t3ek.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-11-10T16:03:17Z","receivedAt":"2011-11-10T16:03:17Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Thu, Nov 10, 2011 at 16:15, Junio C Hamano wrote:\n> Johan Herland writes:\n>> On Wed, Nov 9, 2011 at 18:26, Junio C Hamano wrote:\n>>>  - \"git notes\" is represented as a commit that records a tree that holds\n>>>   the entire mapping from commit to its annotations, and the only way to\n>>>   transferr it is to send it together with its history as a whole. It\n>>>   does not have the nice auto-following property that transfers only the\n>>>   relevant annotations.\n>>\n>> True. However, consider these mitigating factors:\n>> ...\n>>\n>> My point is that although \"notes\" might end up transferring more\n>> annotations than strictly necessary, I believe that in practice all the\n>> notes being transferred are already (or will soon become) relevant.\n>\n> Sorry, but I do not think you are considering what would happen when you\n> have many branches with different purposes, whose commits near tips will\n> never get merged with each other. \"automatic following\" semantics like\n> what \"git fetch\" does for signed tags is absolutely necessary in such a\n> case, and the above are not mitigating factors at all in that context.\n\nWhat about having one notes ref per branch? If/when the branch is merged,\nthe associated notes ref containing the annotations for the commits on that\nbranch would be merged as well (using \"git notes merge\").\n\nSure, using one notes ref per branch is more expensive than a single notes\nref, but it's still cheaper than one ref per signed commit (which is what we\nget when using annotated tags). And it prevents the added code and\ncomplexity of the timestamped mapping approach.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"179290","messageId":"7v39dvuca4.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"CALKQrgdxEXQGKQ3t9Sh82=U933ypHNg8duyVmG9uJbg2iST5fw@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"junio@pobox.com","sentAt":"2011-11-10T17:18:11Z","receivedAt":"2011-11-10T17:18:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland writes:\n\n> What about having one notes ref per branch? If/when the branch is merged,\n> the associated notes ref containing the annotations for the commits on that\n> branch would be merged as well (using \"git notes merge\").\n\nThat is a crude workaround that you could (with help from users) make it\nwork, but it does not change the fact that the current mechanism to\ntransfer and integrate notes across repositories is a bad match for what\nthe \"signed commit\" type annotations wants to achieve. In fact, the need\nfor such a workaround is an illustration of how bad a match the mechanism\nis.\n\nWhen you merge a history that has commit A into another history that did\nnot have that commit, the act of creating a merge commit itself should be\nenough to make the resulting history to contain that commit. The commit\nDAG already expresses it, and if a parallel \"notes\" mechanism needs to be\nfutzed with to match that DAG, and command like \"merge\" needs to be told\nto help that process, that is a shortcoming of the \"notes\" mechanism.\n"},{"id":"179293","messageId":"7vr51fslia.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"CALKQrgfZtELcK3H5ZYvmcW8RrtKMVRACFTvw3s5SidFvmFWkGw@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-10T21:41:49Z","receivedAt":"2011-11-10T21:41:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland writes:\n\n> You would also have to keep track of deleted annotations, to enable the local\n> side to delete an annotation corresponding to an already-deleted annotation\n> on the remote side.\n\nFor the \"signed commit or pull request\" use case, I think \"delete\" is\nprobably not something you want to do in the first place.\n\nIf there is a \"certificate\" that says \"I made this commit\" or \"I agree\nthis is a good topic to be merged to my history\" that later turns out to\nbe incorrect, you do not just want to excise it from your repository and\nthe place you push to. You would instead want to distribute revocation\nnotice for such certificiate, which would be a new \"note\" that will be\nattached to the commit or merge in question, so that other people who got\nthe \"certificate\" from you or the place you push to will know about the\nremoval using the same mechanism.\n\nOf course the \"UI\" layer could match a \"certificate\" and a \"revocation\"\nagainst each other and do something intelligent about them (like, not\nshowing revoked ones by default), so in that sense a moral equivalent of\n\"delete\" from the end user's point of view can easily be supported [*1*].\n\nNote that in this thread, I am not saying that \"git notes\" mechanism is\nnot good for anything. A tree whose node names encode an object name is a\nvalid way to store the mapping from that object to a set of other objects,\nand we already agreed that as the \"local\" storage mechanism, \"git notes\"\nmay be used as-is for the purpose of this thread.\n\nBut the transfer and merge semantics \"git notes\" mechanism offers treats\nthe entire \"notes\" that appear in _one_ repository and merging that set to\nthe entire \"notes\" in another repository and it is not a good match for\nthe purpose of this thread.\n\n\n[Footnote]\n\n*1* The point is, it is not the only way to implement a \"delete\" to keep a\nhistory with common ancestor that has something and your latest that does\nnot have that thing, which is what \"git notes\" gives you. If having to\nkeep the history brings other undesired semantic baggage, other ways that\ndo not have such undesired property need to be explored.\n"},{"id":"179297","messageId":"CALKQrgcJmPHZG0bbgwoH6_htQODYVJtXYyHgSb_7qRKkJkb2Yw@mail.gmail.com","threadId":"28805","inReplyTo":"7v39dvuca4.fsf@alter.siamese.dyndns.org","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-11-11T01:17:58Z","receivedAt":"2011-11-11T01:17:58Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Thu, Nov 10, 2011 at 18:18, Junio C Hamano wrote:\n> Johan Herland writes:\n>\n>> What about having one notes ref per branch? If/when the branch is merged,\n>> the associated notes ref containing the annotations for the commits on that\n>> branch would be merged as well (using \"git notes merge\").\n>\n> That is a crude workaround that you could (with help from users) make it\n> work, but it does not change the fact that the current mechanism to\n> transfer and integrate notes across repositories is a bad match for what\n> the \"signed commit\" type annotations wants to achieve. In fact, the need\n> for such a workaround is an illustration of how bad a match the mechanism\n> is.\n>\n> When you merge a history that has commit A into another history that did\n> not have that commit, the act of creating a merge commit itself should be\n> enough to make the resulting history to contain that commit. The commit\n> DAG already expresses it, and if a parallel \"notes\" mechanism needs to be\n> futzed with to match that DAG, and command like \"merge\" needs to be told\n> to help that process, that is a shortcoming of the \"notes\" mechanism.\n\n[ ...and from elsewhere in this thread: ]\n\n> Note that in this thread, I am not saying that \"git notes\" mechanism is\n> not good for anything. A tree whose node names encode an object name is a\n> valid way to store the mapping from that object to a set of other objects,\n> and we already agreed that as the \"local\" storage mechanism, \"git notes\"\n> may be used as-is for the purpose of this thread.\n>\n> But the transfer and merge semantics \"git notes\" mechanism offers treats\n> the entire \"notes\" that appear in _one_ repository and merging that set to\n> the entire \"notes\" in another repository and it is not a good match for\n> the purpose of this thread.\n\nOk. Point taken.\n\nGiven that we need an alternative way to transfer annotations between\nrepos (using auto-follow to select the relevant set of annotations, and\nthen transferring only those annotations): Can we leverage existing\nfunctionality in \"notes\" where useful (e.g. using existing notes merge\nstrategies to deal with colliding annotations), while at the same time\nextending the current \"notes\" feature with this alternative transfer\nmechanism? FWIW, I expect there are other \"notes\" use cases that\nwould also prefer the auto-follow only-relevant transfer behavior.\n\nSo, how can we use \"notes\" to better support the transfer semantics you\nsuggest? The mapping from the object being annotated to the annotation\nobject is already contained in the notes tree, but the \"timestamp\" you\ndescribe (needed to efficiently calculate the set of annotations to\nauto-follow) is not [1]. However, we could easily enough add a sorted\nlist of (timestamp, annotated object name) pairs, to allow fast lookup\nof annotations created after a given timestamp. We could even store this\nlist in a blob or tree object referenced directly from the notes tree [2].\n\n\nHave fun! :)\n\n...Johan\n\n\n[1]: Although I did at some point experiment with using timestamps in the\ninternal organization of the notes tree (see for example\nhttp://article.gmane.org/gmane.comp.version-control.git/127966 ), I ended\nup using only the annotated object name (with flexible fanout). I don't\nthink that reintroducing timestamps in the notes tree organization will\npay off, because we need both lookup by annotated SHA1 and lookup by\nnewer-than-given-timestamp to be fast, and there's AFAIK no way to get\nboth from a single notes tree organzation.\n\n[2]: E.g. accessible with \"git cat-file refs/notes/foo:timestamps\". When\na notes tree contains an entry that is obviously not an object name (SHA1),\nthe notes code will leave it alone/untouched in the tree (see \"struct\nnon_note\" and associated code in notes.c for further details).\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"179299","messageId":"7vd3czrzzo.fsf@alter.siamese.dyndns.org","threadId":"28805","inReplyTo":"CALKQrgcJmPHZG0bbgwoH6_htQODYVJtXYyHgSb_7qRKkJkb2Yw@mail.gmail.com","subject":"Re: [git patches] libata updates, GPG signed (but see admin notes)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-11T05:26:35Z","receivedAt":"2011-11-11T05:26:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland writes:\n\n> Given that we need an alternative way to transfer annotations between\n> repos (using auto-follow to select the relevant set of annotations, and\n> then transferring only those annotations): Can we leverage existing\n> functionality in \"notes\" where useful (e.g. using existing notes merge\n> strategies to deal with colliding annotations), while at the same time\n> extending the current \"notes\" feature with this alternative transfer\n> mechanism? FWIW, I expect there are other \"notes\" use cases that\n> would also prefer the auto-follow only-relevant transfer behavior.\n>\n> So, how can we use \"notes\" to better support the transfer semantics you\n> suggest? The mapping from the object being annotated to the annotation\n> object is already contained in the notes tree, but the \"timestamp\" you\n> describe (needed to efficiently calculate the set of annotations to\n> auto-follow) is not [1].\n\nPlease do not take the \"timestamp\" part too seriously.\n\nI am starting to think that what we want in this context actually is very\nclose to annotated tags. I said we want a mapping from an annotated object\nto \"a set of other objects\" that annotate it, but it was an unnecessary\nand premature generalization. There is no reason that these annotations\nhave to be structured \"Git\" objects such as blobs and trees.\n\nA set of annotated tags that have the same value on their \"object\" field\nis a perfect match for \"a set of annotations attached to a given object\".\n\nWe already know that using the real tags has its own problems coming from\nhaving to give each and every one of them unique names somewhere in the\nrefs hierarchy (be it refs/tags/ or refs/audit/), but imagine if we\nsomehow had a way to:\n\n - keep these annotated tags in the object store;\n\n - keep them from getting pruned even if they are not referenced from\n anywhere in refs/ hierarchy;\n\n - given an object, efficiently enumerate such annotate tags that refer to\n the object.\n\nAnd then imagine that we are pushing history leading to a commit from one\nrepository to another. Both repositories store these \"anonymous\" (that is\nwhat they are---they do not have a name in the refs/ hierarchy) tags.\n\nThe two repositories can individually enumerate all these \"anonymous\" tags\nthat annotate commits in the history that is being exchanged, and run a\nset reconciliation algorithm (e.g. [*1*]) to find out the anonymous tags\nthat are missing from the recipient repository.\n\nSuch an approach does not require any timestamp.\n\nMy point is _not_ that the alternative in this message is superiour to the\nhandwaving in my other message, but is that I think it may not be the best\napproach to think what needs to be added to \"notes\" to make it applicable\nfor the problem we are solving.\n\nRather, I think we should design how the overall system should look like\n(i.e. what property the resulting system should have) and then find out\nwhat is necessary in each part of the resulting solution (i.e. the list of\n\"somehow had a way to...\" above, plus \"efficient set reconciliation\").\n\n\n[Footnote]\n\n*1* What's the Difference? Efficient Set Reconciliation without Prior\nContext http://cseweb.ucsd.edu/~fuyeda/papers/sigcomm2011.pdf\n"}]}