On Wed, Feb 26, 2020 at 03:42:31PM -0500, Konstantin Ryabitsev wrote: > On Wed, Feb 26, 2020 at 04:11:40PM -0400, Jason Gunthorpe wrote: > > > If you look at the contents of the patch attestation message > > > (https://lore.kernel.org/signatures/202002251425.E7847687B@keescook/), > > > you will notice a yaml-style formatted document with a series of > > > three hashes. Let's take the first one as example: > > > > > > 2a02abe0-215cf3f1-2acb5798: > > > i: 2a02abe02216f626105622aee2f26ab10c155b6442e23441d90fc5fe4071b86e > > > m: 215cf3f133478917ad147a6eda1010a9c4bba1846e7dd35295e9a0081559e9b0 > > > p: 2acb5798c366f97501f8feacb873327bac161951ce83e90f04bbcde32e993865 > > > > > > The source of these hashes is the following patch: > > > https://lore.kernel.org/kernel-hardening/20200225051307.6401-2-keescook@xxxxxxxxxxxx/ > > > > If you define an alternative message signature algorithm like this, > > then is there still value in detatching the PGP signature from the > > patch email? > > I believe that yes, because it offers better workflows around the > following scenarios: > > - developer does all their work on a remote VM that doesn't have access > to their PGP keys and submits actual attestation when they get back to > their workstation Unfortunately this is a challenging work flow for a lot of reasons. :( > - developer configures their smartcard to require a PIN during each > operation and disables the pgp-agent; sending a series of 40 patches > requires a single PIN entry instead of 40 This is certainly my situation, my PGP key lives in a yubikey token configured for physical presence to confirm. :\ > - developer submits a v1 of the patch that they don't expect to pass on > the first try and doesn't bother submitting attestation; shockingly, > the maintainer accepts it as-is and the developer can attest their > patches post-fact *without* needing to collect all the acked-by's > reviewed-by's etc from all others who have already responded to the v1 > submission But there won't be tags in this case, so how do we learn the original attestation-id to find the detatched signature? > For example, a maintainer will almost certainly edit the message content > to add their own Signed-off-by, and may edit the patch for minor > nitpicking. The i/p/m will always change once in git: - The commit message is always changed, at least to add sign off - The email Subject is always changed to strip [PATCH xxx] - The diff is almost always changed because the patch is applied to a different tree. The git blob IDs will be different at a minimum, at a maximum the context lines will be different If we know the expected ID then you could do some fuzzy scheme to cancel out, or at least check, the differences.. We have many patches now that have Link: trailer. I think it would be useful to run some analysis: - Fetch the original patch email from the Link and compute the detached signature hashes - Attempt to validate this sigature against the git commit - Is there a fuzzy algorithm that brings this rate higher? What is the pass/fail rate? It would say a lot about the strength of this scheme through to the final git commit and thus if post-fact is relevant or not. > Full i-m-p attestation will fail in this case, but we can > then query the signatures archive for each individual hash to identify > which part of the submission fails validation: > https://lore.kernel.org/signatures/?q=2a02abe02216f626105622aee2f26ab10c155b6442e23441d90fc5fe4071b86e > > This lets us present the maintainer with more useful info, like: "full > attestation failed, but the only changed part is actually the message > and not the patch content, so it's probably still okay to apply." How does the message body get changed in transit from the submitter to the maintainer? > I still think that one of the key benefits of this proposal is being > able to submit patch attestation data post-fact. For signatures included > with patches, I'd rather see this happen during the git-format-patch > step following Vagard Nossum's work of fully reconstructing commits from > patches -- see my email to the git list here: > https://lore.kernel.org/git/20200226200929.z4aej74ohbkgcdza@chatter.i7.local/T/#u It is too bad that the email flow for git cannot, at least optionally, reconstruct losslessly the original commit hashes. It would be very nice if this were possible. Jason
