On Wed, Feb 26, 2020 at 12:25:02PM -0500, Konstantin Ryabitsev wrote: > ## The submitter workflow > > As I envision it, the submitter workflow would look as follows: > > - the developer runs "git-format-patch" > - the developer reviews the changes and makes any last-minute edits they > deem necessary before submitting their work to the list/maintainer > - the developer executes "git-send-email" > - the developer runs "attest-patches -a *.patches" > - the developer sends attestation.eml to signatures@xxxxxxxxxx > (or the tool auto-POSTs it to the submission URL, as mentioned) > > There can even be a fairly simple wrapper around git-send-email that > would perform attestation as part of the "sending patches" stage. FWIW, I would find this utterly trivial to add to my workflow. (The only minor difference that doesn't really matter is that in addition to series-style patches, I also regularly send one-offs, but that would just be a short attestation email.) > ## The reviewer workflow > > The reviewer does not need to concern themselves with attestation until > they are ready to apply the patches to their git tree. When that moment > comes: > > - the maintainer runs get-lore-mbox -aA (-A is not implemented yet) > - get-lore-mbox performs attestation before generating the am-ready mbox > - if attestation passes, get-lore-mbox adds two trailers to each patch: > "Attestation-by:" and "Attestation-verified:". In our example case > those are: > Attestation-by: Kees Cook <kees@xxxxxxxxxx> (pgp:8972F4DFDC6DC026) > Attestation-verified: Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> We'll probably need to have a stable way to deal with key aliases. Even in this example my email addresses are keescook@xxxxxxxxxxxx (patches and attestation sender), kees@xxxxxxxxxxx (comment in gpg sig), and kees@xxxxxxxxxx (since that's what Konstantin used to fetch my key). And perhaps I lack imagination, but what is the overall purpose of these proposed tags? If it's just a hint to whether the patch has attestation, the '-verified:' isn't needed. Anyone wanting to check attestation would always need to do the full heavy lifting anyway. > # Thoughts? > > Okay, what do you all think? I believe this scheme has the following > merits: > > - it is opt-in and can be adopted by individual subsystem maintainers > - it builds on top of the PGP trust framework already used extensively > by the kernel developers > - it doesn't litter mailing lists with non-human-readable attestation > junk > - it doesn't require that attestation data is created at the time when > patches are submitted for review; the maintainer can request that it > is provided at a later time when they are ready to apply the series to > their git tree and want attestation data for the final sanity check > and record-keeping > - all attestations are recorded in the public-inbox "signatures" feed > that can be mirrored along all other public-inbox repositories on > lore.kernel.org Moar blockchains! ;) But, yes, it provides a signed path from author to committer without interfering with existing workflows. I like it! > Downsides: > > - we aren't solving the problem of delegated trust, which will continue > to be the hardest part behind any distributed development effort This was immediately my first question. How does a committer choose the correct GPG key? /me waits for the kernel.org key server to appear... Thanks for working on this! It was fun being the alpha guinea pig. ;) -- Kees Cook
