Workflows Archive on lore.kernel.org
 help / color / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: workflows@vger.kernel.org
Subject: Re: Patch attestation RFC + proof of concept
Date: Wed, 26 Feb 2020 17:04:42 -0400
Message-ID: <20200226210442.GE31668@ziepe.ca> (raw)
In-Reply-To: <20200226204231.x5jbqgmkedtgpkmn@chatter.i7.local>

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@chromium.org/
> > 
> > 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

  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
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 [this message]
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=20200226210442.GE31668@ziepe.ca \
    --to=jgg@ziepe.ca \
    --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