{"thread":{"id":"58653","subject":"git-send-email with GPG signed commits?","startedAt":"2022-10-20T04:34:49Z","lastAt":"2022-10-21T00:12:16Z","messageCount":13,"participants":["Matěj Cepl","Konstantin Ryabitsev","Jeff King","Junio C Hamano","rsbecker@nexbridge.com","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"465280","messageId":"4eb8707f-4686-e304-2aab-a6afee11abc9@cepl.eu","threadId":"58653","inReplyTo":null,"subject":"git-send-email with GPG signed commits?","fromName":"Matěj Cepl","fromEmail":"mcepl@cepl.eu","sentAt":"2022-10-20T04:26:49Z","receivedAt":"2022-10-20T04:34:49Z","isPatch":false,"sender":{"key":"mcepl@cepl.eu","avatar":"https://avatars.githubusercontent.com/u/198999?v=4"},"body":"Hello,\n\ndid anybody even think about %subj%? Is there some effort somewhere \nmaking git-send-email(1) supporting transfer of signed commits, where I \ncould join? I like hosting sites like sr.ht, which support \ngit-send-email(1), but unfortunately using that clears my submission off \nits GPG signatures. I guess, it would be necessary to make some \nmodifications to git-send-email(1) and git-am(1). Is there some effort \nsomewhere in that direction?\n\nBest,\n\nMatěj\n-- \nhttps://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz\nGPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8\n\nSomewhere at the edge of the Bell curve was the girl for me.\n     -- Based on http://xkcd.com/314/\n"},{"id":"465291","messageId":"20221020124612.xivhb4xk52yvy5nk@meerkat.local","threadId":"58653","inReplyTo":"4eb8707f-4686-e304-2aab-a6afee11abc9@cepl.eu","subject":"Re: git-send-email with GPG signed commits?","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2022-10-20T12:46:12Z","receivedAt":"2022-10-20T12:46:19Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Thu, Oct 20, 2022 at 06:26:49AM +0200, Matěj Cepl wrote:\n> Hello,\n> \n> did anybody even think about %subj%? Is there some effort somewhere making\n> git-send-email(1) supporting transfer of signed commits, where I could join?\n> I like hosting sites like sr.ht, which support git-send-email(1), but\n> unfortunately using that clears my submission off its GPG signatures. I\n> guess, it would be necessary to make some modifications to git-send-email(1)\n> and git-am(1). Is there some effort somewhere in that direction?\n\nLinux Kernel supports end-to-end attested patches (including using PGP), but\nthe implementation took a slightly different direction, because there are\nimportant downsides to PGP-signed messages when it comes to patch workflows.\n\nSee the following project:\nhttps://pypi.org/project/patatt/\n\nThere is a section on that page that describes why PGP-signed patches aren't\nthe preferred way to go for many people.\n\nBest regards,\nKonstantin\n"},{"id":"465307","messageId":"a2b0abfa-3533-b22b-1e8f-5be4c00163ce@cepl.eu","threadId":"58653","inReplyTo":"20221020124612.xivhb4xk52yvy5nk@meerkat.local","subject":"Re: git-send-email with GPG signed commits?","fromName":"Matěj Cepl","fromEmail":"mcepl@cepl.eu","sentAt":"2022-10-20T17:29:35Z","receivedAt":"2022-10-20T17:29:44Z","isPatch":false,"sender":{"key":"mcepl@cepl.eu","avatar":"https://avatars.githubusercontent.com/u/198999?v=4"},"body":"Dne 20. 10. 22 v 14:46 Konstantin Ryabitsev napsal(a):\n>> did anybody even think about %subj%? Is there some effort somewhere making\n>> git-send-email(1) supporting transfer of signed commits, where I could join?\n>> I like hosting sites like sr.ht, which support git-send-email(1), but\n>> unfortunately using that clears my submission off its GPG signatures. I\n>> guess, it would be necessary to make some modifications to git-send-email(1)\n>> and git-am(1). Is there some effort somewhere in that direction?\n> \n> Linux Kernel supports end-to-end attested patches (including using PGP), but\n> the implementation took a slightly different direction, because there are\n> important downsides to PGP-signed messages when it comes to patch workflows.\n> \n> See the following project:\n> https://pypi.org/project/patatt/\n\nHmm, that's very interesting and it seems that at least somehow sr.ht \nhas to work with (https://is.gd/qea0gF), but if I understand it \ncorrectly the GPG signature is on the email, not on the commit, so \ngit-am(1) (or even b4 shazam) sees just unsigned commit and when pushed \nto GitHub/GitLab or any other repository which knows about signing git \ncommits, it doesn’t get green check-mark, right? Although, the line “you \ncan use PGP keys to sign git tags/commits, not just mailed patches” in \nthe README makes me wonder.\n\nHmm, I should probably ask on the sr.ht list.\n\nThank you for the response,\n\nMatěj\n\n-- \nhttps://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz\nGPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8\n\nв чужой монастырь со своим уставом не ходят.\n     -- Russian proverb (this time actually checked by a native\n        Russian)\n\n"},{"id":"465309","messageId":"Y1GJAart+/yFc5MR@coredump.intra.peff.net","threadId":"58653","inReplyTo":"4eb8707f-4686-e304-2aab-a6afee11abc9@cepl.eu","subject":"Re: git-send-email with GPG signed commits?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2022-10-20T17:44:33Z","receivedAt":"2022-10-20T17:44:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 20, 2022 at 06:26:49AM +0200, Matěj Cepl wrote:\n\n> did anybody even think about %subj%? Is there some effort somewhere making\n> git-send-email(1) supporting transfer of signed commits, where I could join?\n> I like hosting sites like sr.ht, which support git-send-email(1), but\n> unfortunately using that clears my submission off its GPG signatures. I\n> guess, it would be necessary to make some modifications to git-send-email(1)\n> and git-am(1). Is there some effort somewhere in that direction?\n\nI think there's an inherent problem here. A commit signature is over the\nentire commit object. But when you send a patch, you don't know the\nexact bytes of the resulting commit object. In particular, the\n\"committer\" line will have the ident and timestamp from when the\nreceiver applies the patch and turns it into a commit.\n\nSo commit signatures are generally an attestation by the committer, not\nby the author. It's just that the two are usually the same when you are\ncommitting locally.\n\nI think you would need some kind of \"author-sig\" header that signs the\ncommit object bytes _without_ the commit header at all. And that assumes\nthe maintainer's workflow is to never modify a patch in transit, and to\napply it at the exact same spot that you wrote it (so that the parent\nand tree ids remain the same).\n\n-Peff\n"},{"id":"465310","messageId":"xmqqr0z2s7w4.fsf@gitster.g","threadId":"58653","inReplyTo":"Y1GJAart+/yFc5MR@coredump.intra.peff.net","subject":"Re: git-send-email with GPG signed commits?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-20T17:48:59Z","receivedAt":"2022-10-20T17:49:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> So commit signatures are generally an attestation by the committer, not\n> by the author. It's just that the two are usually the same when you are\n> committing locally.\n>\n> I think you would need some kind of \"author-sig\" header that signs the\n> commit object bytes _without_ the commit header at all. And that assumes\n> the maintainer's workflow is to never modify a patch in transit, and to\n> apply it at the exact same spot that you wrote it (so that the parent\n> and tree ids remain the same).\n\nDoesn't it immediately break down once you send a 2-patch series?\nYou may be able to get the bottom one right, but the top one needs\nto depend on the commit object name of the result of applying the\nbottom one.\n\nIt depends on what they are trying to achieve by transferrring with\nexisting signature intact.  If they truly want to preserve the\nvalidity of the signatures on commits, they are better off\nexchanging bundles over e-mail, as reviewers and integrators are not\neven allowed to touch anything.\n"},{"id":"465312","messageId":"xmqqk04us77b.fsf@gitster.g","threadId":"58653","inReplyTo":"xmqqr0z2s7w4.fsf@gitster.g","subject":"Re: git-send-email with GPG signed commits?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-20T18:03:52Z","receivedAt":"2022-10-20T18:05:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n>> I think you would need some kind of \"author-sig\" header that signs the\n>> commit object bytes _without_ the commit header at all. And that assumes\n>> the maintainer's workflow is to never modify a patch in transit, and to\n>> apply it at the exact same spot that you wrote it (so that the parent\n>> and tree ids remain the same).\n>\n> Doesn't it immediately break down once you send a 2-patch series?\n\nAh, if you did not mean \"without the committer header\", but \"without\nany of the header fields of the commit object\", then it would\nprobably work.  But then that loses the context to apply the patch\ncompletely, so I can apply a patch you author-signed to a place\nwhere it wouldn't work and end up with a broken commit.  \n\nStart from the original commit object, remove the committer, the\nauthor, the tree, and the parent headers, add a parent-tree header\nthat records the tree object of the first parent, and call that a\n\"modified commit object\".  Then compute the signature over it and\nthe patch text.  The e-mailed patch now needs to carry the value of\nthe parent-tree header and the signature.\n\nAt the receiving end, the reverse operation can be done and the\nresulting commit may have two new headers (author-sig and\nparent-tree).  In the resulting commit, parent-tree does not have to\nmatch the tree of its first parent, if the integrator chose to apply\nit on a different commit, and as long as the patch text matches,\nthings should verify.\n\nSo, some kind of \"author-sig\" is certainly possible, but is it\npractically useful?  I am not sure.  It still does not even allow\ntypofixes on the receiving end.\n\n"},{"id":"465323","messageId":"Y1GUDbtFIGZu0BKD@coredump.intra.peff.net","threadId":"58653","inReplyTo":"xmqqk04us77b.fsf@gitster.g","subject":"Re: git-send-email with GPG signed commits?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2022-10-20T18:31:41Z","receivedAt":"2022-10-20T18:31:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 20, 2022 at 11:03:52AM -0700, Junio C Hamano wrote:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n> \n> >> I think you would need some kind of \"author-sig\" header that signs the\n> >> commit object bytes _without_ the commit header at all. And that assumes\n> >> the maintainer's workflow is to never modify a patch in transit, and to\n> >> apply it at the exact same spot that you wrote it (so that the parent\n> >> and tree ids remain the same).\n> >\n> > Doesn't it immediately break down once you send a 2-patch series?\n\nOops, you're right. The parent pointer in subsequent ones is unknowable.\n\n> Ah, if you did not mean \"without the committer header\", but \"without\n> any of the header fields of the commit object\", then it would\n> probably work.  But then that loses the context to apply the patch\n> completely, so I can apply a patch you author-signed to a place\n> where it wouldn't work and end up with a broken commit.\n\nNo, I was not that clever. I just didn't think about the subsequent\ncommits. I agree that an author-sig that omits the parent pointer is\npractically useless. It does record the end tree state faithfully, but\nwhat most people consider interesting in a commit is the diff from the\nparent tree. So applied in the wrong spot, it makes it look like your\nsigned commit made changes you never intended.\n\n> Start from the original commit object, remove the committer, the\n> author, the tree, and the parent headers, add a parent-tree header\n> that records the tree object of the first parent, and call that a\n> \"modified commit object\".  Then compute the signature over it and\n> the patch text.  The e-mailed patch now needs to carry the value of\n> the parent-tree header and the signature.\n> \n> At the receiving end, the reverse operation can be done and the\n> resulting commit may have two new headers (author-sig and\n> parent-tree).  In the resulting commit, parent-tree does not have to\n> match the tree of its first parent, if the integrator chose to apply\n> it on a different commit, and as long as the patch text matches,\n> things should verify.\n\nI think it's a bit weird if parent-tree does not match the first parent.\nYour final tree must still match what was signed. And so if you applied\nit on a commit that didn't match the original parent-tree, then the\ncommit would be quietly reverting changes between the original\nparent-tree and the actual parent it was applied on.\n\nI do think it would work if you enforced that. But I tend to agree with\nyour other comment that people may be better off just sending bundles at\nthat point.\n\n> So, some kind of \"author-sig\" is certainly possible, but is it\n> practically useful?  I am not sure.  It still does not even allow\n> typofixes on the receiving end.\n\nYes, like bundles, it is losing some of the flexibility of an\nemailed-patch workflow. I haven't played with b4's attestation too much,\nbut I think it slots into a patch workflow better. You are signing the\npatch, not the commit, and commits which are made later can refer back\nto the emails, which people can then verify. That's not a signature on\nthe commit, but it is a paper trail that can be followed.\n\n-Peff\n"},{"id":"465325","messageId":"20221020185552.la6ewgjre7dlq6xx@meerkat.local","threadId":"58653","inReplyTo":"a2b0abfa-3533-b22b-1e8f-5be4c00163ce@cepl.eu","subject":"Re: git-send-email with GPG signed commits?","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2022-10-20T18:55:52Z","receivedAt":"2022-10-20T18:56:01Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Thu, Oct 20, 2022 at 07:29:35PM +0200, Matěj Cepl wrote:\n> > Linux Kernel supports end-to-end attested patches (including using PGP), but\n> > the implementation took a slightly different direction, because there are\n> > important downsides to PGP-signed messages when it comes to patch workflows.\n> > \n> > See the following project:\n> > https://pypi.org/project/patatt/\n> \n> Hmm, that's very interesting and it seems that at least somehow sr.ht has to\n> work with (https://is.gd/qea0gF), but if I understand it correctly the GPG\n> signature is on the email, not on the commit, so git-am(1) (or even b4\n> shazam) sees just unsigned commit and when pushed to GitHub/GitLab or any\n> other repository which knows about signing git commits, it doesn’t get green\n> check-mark, right? Although, the line “you can use PGP keys to sign git\n> tags/commits, not just mailed patches” in the README makes me wonder.\n\nNo, you are correct, these signatures are not carried into git commits,\nbecause the commit message is almost always modified to insert the\nSigned-off-by or other trailers, which invalidates the git commit signature.\n\nThe goal of patatt signatures is precisely to attest *patches* and operate\ncompletely independently from in-git signatures.\n\n> Hmm, I should probably ask on the sr.ht list.\n\nIn my previous interactions with Drew, he was not really interested in this\nwork. I know that sr.ht does check DKIM signatures on incoming patches, so it\ndoes have domain-level attestation.\n\nRegards,\nKonstantin\n"},{"id":"465328","messageId":"20221020190117.va67kbrmvg4xxit5@meerkat.local","threadId":"58653","inReplyTo":"Y1GUDbtFIGZu0BKD@coredump.intra.peff.net","subject":"Re: git-send-email with GPG signed commits?","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2022-10-20T19:01:17Z","receivedAt":"2022-10-20T19:01:28Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Thu, Oct 20, 2022 at 02:31:41PM -0400, Jeff King wrote:\n> Yes, like bundles, it is losing some of the flexibility of an\n> emailed-patch workflow. I haven't played with b4's attestation too much,\n> but I think it slots into a patch workflow better. You are signing the\n> patch, not the commit, and commits which are made later can refer back\n> to the emails, which people can then verify. That's not a signature on\n> the commit, but it is a paper trail that can be followed.\n\nThat is accurate -- I've looked into attempting to preserve git commit\nsignatures via sent patches, precisely so they could be applied back into the\ntree. However, the consensus among developers was that this is almost never\nuseful, and since we were already providing a robust paper-trail framework in\nthe form of public-inbox archives, it made sense to keep patch-level\nattestation and git-level attestation separate.\n\n-K\n"},{"id":"465329","messageId":"004901d8e4bb$c3338360$499a8a20$@nexbridge.com","threadId":"58653","inReplyTo":"20221020190117.va67kbrmvg4xxit5@meerkat.local","subject":"RE: git-send-email with GPG signed commits?","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-10-20T19:40:03Z","receivedAt":"2022-10-20T19:40:22Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On October 20, 2022 3:01 PM, Konstantin Ryabitsev wrote:\n>On Thu, Oct 20, 2022 at 02:31:41PM -0400, Jeff King wrote:\n>> Yes, like bundles, it is losing some of the flexibility of an\n>> emailed-patch workflow. I haven't played with b4's attestation too\n>> much, but I think it slots into a patch workflow better. You are\n>> signing the patch, not the commit, and commits which are made later\n>> can refer back to the emails, which people can then verify. That's not\n>> a signature on the commit, but it is a paper trail that can be followed.\n>\n>That is accurate -- I've looked into attempting to preserve git commit signatures via\n>sent patches, precisely so they could be applied back into the tree. However, the\n>consensus among developers was that this is almost never useful, and since we\n>were already providing a robust paper-trail framework in the form of public-inbox\n>archives, it made sense to keep patch-level attestation and git-level attestation\n>separate.\n\nAs I see it, if git commit signatures become a requirement (maybe resulting from supply chain discussions), then using existing capabilities may be the most practical alternative. This would involve submitting signed commits in pull request via GitHub instead of emailing patches. I know this is not a desirable position for the git team, but it is currently available technology. In a pinch, that could satisfy the requirement.\n-Randall\n\n"},{"id":"465348","messageId":"5c12bc9c-36b0-578b-2403-54a9bcf920b1@cepl.eu","threadId":"58653","inReplyTo":"004901d8e4bb$c3338360$499a8a20$@nexbridge.com","subject":"Re: git-send-email with GPG signed commits?","fromName":"Matěj Cepl","fromEmail":"mcepl@cepl.eu","sentAt":"2022-10-20T21:03:33Z","receivedAt":"2022-10-20T21:03:41Z","isPatch":false,"sender":{"key":"mcepl@cepl.eu","avatar":"https://avatars.githubusercontent.com/u/198999?v=4"},"body":"Dne 20. 10. 22 v 21:40 rsbecker@nexbridge.com napsal(a):\n> As I see it, if git commit signatures become a requirement (maybe\n> resulting from supply chain discussions), then using existing\n> capabilities may be the most practical alternative. This would\n> involve submitting signed commits in pull request via GitHub instead\n> of emailing patches. I know this is not a desirable position for the\n> git team, but it is currently available technology. In a pinch, that\n> could satisfy the requirement.\n\nI just think that this future is much closer than one would think. I\nthink that for example electronic signatures and hashes are one of\nreasons why even SUSE is probably now going to ditch osc as a versioning\nsystem and switch to git (yay! \\o/). Our partners just forced us to do\nso. And I really liked the true independence of git distributed development.\n\nBest,\n\nMatěj\n\n-- \nhttps://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz\nGPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8\n\nEvery true American would rather see this land face war than see\nher flag lowered in dishonor.\n  -- The Episcopal bishop of New York, William Manning, 1916\n"},{"id":"465351","messageId":"Y1G8FKzHF4GJCaan@tapette.crustytoothpaste.net","threadId":"58653","inReplyTo":"4eb8707f-4686-e304-2aab-a6afee11abc9@cepl.eu","subject":"Re: git-send-email with GPG signed commits?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-10-20T21:22:28Z","receivedAt":"2022-10-20T21:22:41Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2022-10-20 at 04:26:49, Matěj Cepl wrote:\n> Hello,\n> \n> did anybody even think about %subj%? Is there some effort somewhere making\n> git-send-email(1) supporting transfer of signed commits, where I could join?\n> I like hosting sites like sr.ht, which support git-send-email(1), but\n> unfortunately using that clears my submission off its GPG signatures. I\n> guess, it would be necessary to make some modifications to git-send-email(1)\n> and git-am(1). Is there some effort somewhere in that direction?\n\nThere's been discussion about this in the past on the list.  I am\npersonally in favour of a solution which allows us to preserve the\ncommitter and signature information in headers in the patch and apply\nthat to synthesize a complete commit.\n\nI know many people who work on a patch-based workflow _don't_ want to\nresynthesize the entire commit and would prefer to keep the current\napproach, which I also think is fine.  However, there are situations\nwhere end-to-end provenance is useful and so is email, and I think it's\nworth supporting.\n\nIt is on my ever growing backlog of projects I'd like to implement but I\ndon't have any immediate plans to do so.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"465391","messageId":"46fbe607-bb75-5818-657c-47d8b8144aba@cepl.eu","threadId":"58653","inReplyTo":"Y1G8FKzHF4GJCaan@tapette.crustytoothpaste.net","subject":"Re: git-send-email with GPG signed commits?","fromName":"Matěj Cepl","fromEmail":"mcepl@cepl.eu","sentAt":"2022-10-21T00:12:08Z","receivedAt":"2022-10-21T00:12:16Z","isPatch":false,"sender":{"key":"mcepl@cepl.eu","avatar":"https://avatars.githubusercontent.com/u/198999?v=4"},"body":"Dne 20. 10. 22 v 23:22 brian m. carlson napsal(a):\n> I know many people who work on a patch-based workflow _don't_ want to\n> resynthesize the entire commit and would prefer to keep the current\n> approach, which I also think is fine.  However, there are situations\n> where end-to-end provenance is useful and so is email, and I think it's\n> worth supporting.\n> \n> It is on my ever growing backlog of projects I'd like to implement but I\n> don't have any immediate plans to do so.\n\nUnfortunately, my Perl-foo is even weaker than my C-foo, so I am afraid\nI cannot be much help here. I am sorry.\n\nBest,\n\nMatěj\n\n-- \nhttps://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz\nGPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8\n\nThe American Republic will endure, until politicians realize they\ncan bribe the people with their own money.\n    -- based on a statement of Alexander Fraser Tytler\n"}]}