On Thu, Oct 20, 2022 at 11:03:52AM -0700, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > >> I think you would need some kind of "author-sig" header that signs the > >> commit object bytes _without_ the commit header at all. And that assumes > >> the maintainer's workflow is to never modify a patch in transit, and to > >> apply it at the exact same spot that you wrote it (so that the parent > >> and tree ids remain the same). > > > > Doesn't it immediately break down once you send a 2-patch series? Oops, you're right. The parent pointer in subsequent ones is unknowable. > Ah, if you did not mean "without the committer header", but "without > any of the header fields of the commit object", then it would > probably work. But then that loses the context to apply the patch > completely, so I can apply a patch you author-signed to a place > where it wouldn't work and end up with a broken commit. No, I was not that clever. I just didn't think about the subsequent commits. I agree that an author-sig that omits the parent pointer is practically useless. It does record the end tree state faithfully, but what most people consider interesting in a commit is the diff from the parent tree. So applied in the wrong spot, it makes it look like your signed commit made changes you never intended. > Start from the original commit object, remove the committer, the > author, the tree, and the parent headers, add a parent-tree header > that records the tree object of the first parent, and call that a > "modified commit object". Then compute the signature over it and > the patch text. The e-mailed patch now needs to carry the value of > the parent-tree header and the signature. > > At the receiving end, the reverse operation can be done and the > resulting commit may have two new headers (author-sig and > parent-tree). In the resulting commit, parent-tree does not have to > match the tree of its first parent, if the integrator chose to apply > it on a different commit, and as long as the patch text matches, > things should verify. I think it's a bit weird if parent-tree does not match the first parent. Your final tree must still match what was signed. And so if you applied it on a commit that didn't match the original parent-tree, then the commit would be quietly reverting changes between the original parent-tree and the actual parent it was applied on. I do think it would work if you enforced that. But I tend to agree with your other comment that people may be better off just sending bundles at that point. > So, some kind of "author-sig" is certainly possible, but is it > practically useful? I am not sure. It still does not even allow > typofixes on the receiving end. 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. -Peff
