On October 20, 2022 3:01 PM, Konstantin Ryabitsev wrote: >On Thu, Oct 20, 2022 at 02:31:41PM -0400, Jeff King wrote: >> Yes, like bundles, it is losing some of the flexibility of an >> emailed-patch workflow. I haven't played with b4's attestation too >> much, but I think it slots into a patch workflow better. You are >> signing the patch, not the commit, and commits which are made later >> can refer back to the emails, which people can then verify. That's not >> a signature on the commit, but it is a paper trail that can be followed. > >That is accurate -- I've looked into attempting to preserve git commit signatures via >sent patches, precisely so they could be applied back into the tree. However, the >consensus among developers was that this is almost never useful, and since we >were already providing a robust paper-trail framework in the form of public-inbox >archives, it made sense to keep patch-level attestation and git-level attestation >separate. As 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. -Randall
