Since we're talking about email-based patch workflows, can I possibly get your opinion on https://git.kernel.org/pub/scm/linux/kernel/git/mricon/patch-attestation-poc.git/plain/README.rst ?
@monsieuricon generally speaking for all of the problems enumerated in the problem statement, I feel the blame lies somewhere else and it's better to e.g. fix the broken mailing lists than e.g. invent a new standard to accommodate them
Also, one issue you didn't address is that PGP signatures do not translate to git commit signatures, so the attestation is lost once the patch is incorporated. To me this may be the bigger issue to address
In any case, you'll ultimately be disappointed by my answer, which is that I don't think this is interesting or important right now
@sir well, it may not be quite important from your or my perspective, but there is quite a bit of interest to have attestation in place from large companies participating in open-source development. Red Hat wants to be able to prove that a patch didn't come from Red Hat (e.g. if it includes legally questionable code). Similarly, others are interested in having a verifiable trail that a patch *did* come from Red Hat.
@sir Even if it's not an important problem for maintainers and the project itself, verifiable attestation is seen as an important missing piece in the open-source legal framework.
Kernel.org after-party social