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 [thread overview]
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 other threads:[~2020-02-26 17:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-26 17:25 Patch attestation RFC + proof of concept 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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).