Workflows Archive on lore.kernel.org
 help / color / Atom feed
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

  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