From: Kees Cook <keescook@chromium.org> To: workflows@vger.kernel.org Subject: Re: Patch attestation RFC + proof of concept Date: Wed, 26 Feb 2020 09:50:50 -0800 Message-ID: <202002260938.BFA7FA03@keescook> (raw) In-Reply-To: <20200226172502.q3fl67ealxsonfgp@chatter.i7.local> 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@kernel.org > (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@kernel.org> (pgp:8972F4DFDC6DC026) > Attestation-verified: Konstantin Ryabitsev <konstantin@linuxfoundation.org> We'll probably need to have a stable way to deal with key aliases. Even in this example my email addresses are keescook@chromium.org (patches and attestation sender), kees@outflux.net (comment in gpg sig), and kees@kernel.org (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
next prev parent reply index Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-26 17:25 Konstantin Ryabitsev 2020-02-26 17:50 ` Kees Cook [this message] 2020-02-26 18:47 ` Konstantin Ryabitsev 2020-02-26 20:11 ` Jason Gunthorpe 2020-02-26 20:42 ` Konstantin Ryabitsev 2020-02-26 21:04 ` Jason Gunthorpe 2020-02-26 21:18 ` Konstantin Ryabitsev 2020-02-27 1:23 ` Jason Gunthorpe 2020-02-27 4:11 ` Jason A. Donenfeld 2020-02-27 10:05 ` Geert Uytterhoeven 2020-02-27 13:30 ` Jason A. Donenfeld 2020-02-27 14:29 ` Konstantin Ryabitsev 2020-02-28 1:57 ` Jason A. Donenfeld 2020-02-28 2:30 ` Jason A. Donenfeld 2020-02-28 18:33 ` Konstantin Ryabitsev 2020-02-28 17:54 ` Konstantin Ryabitsev 2020-03-06 16:53 ` Geert Uytterhoeven
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=202002260938.BFA7FA03@keescook \ --to=keescook@chromium.org \ --cc=workflows@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Workflows Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/workflows/0 workflows/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 workflows workflows/ https://lore.kernel.org/workflows \ workflows@vger.kernel.org public-inbox-index workflows Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.workflows AGPL code for this site: git clone https://public-inbox.org/public-inbox.git