Re: Patch attestation RFC + proof of concept

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Wed, Feb 26, 2020 at 04:18:05PM -0500, Konstantin Ryabitsev wrote:
> On Wed, Feb 26, 2020 at 05:04:42PM -0400, Jason Gunthorpe wrote:
> > > - 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. :(
> Can you describe why? I would expect that this is done fairly routinely 
> due to having more compute power on a remote VM to run various tests.

I've seen enough situations where people have a Linux server and a
Windows laptop. They don't have a Linux desktop, so mixing a local
'secure' PGP key in a windows environment with the remote Linux server
environment is challenging.

If you have a secure 'Linux desktop environment' then I'd imagine
always sending signed emails from there, and just using the server for

Certainly, exposing my email password (aka my cloud account password)
is of even greater risk to me (and my company!) than exposing my PGP
key. I want to keep it on my secure server, encrypted, etc. Actually
I'm trying hard to move all my email access to OAUTH to minimize risks
to my cloud accounts :\

> > > - 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?
> The attestation would be performed before all the follow-up tags are 
> applied, so the attestation-id would be the same. After the patch is 
> applied to a git repository, we can still use the "i" hash to look it up 
> (see more below).

I'm not sure, if the '[PATCH xx v5]' is stripped then 'i' is not
unique any more?
> > > 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]
> This is already done by "git mailinfo" so I would expect that the i:
> hash almost never changes, actually, unless the maintainer actually 
> edits the subject. Subject + Author + Email are sufficiently unique to 
> be able to locate the attestation data of the exact patch.

Ah, using git mailinfos is not how you described 'i':

$ egrep '^(Author|Email|Subject)' i | sha256sum
2a02abe02216f626105622aee2f26ab10c155b6442e23441d90fc5fe4071b86e  -

(also I do edit subjects a fair amount, again it would be interesting
 to see stats on how well this works)

> So, the goal is not really to perform attestation once the patches made 
> it into the git tree. I am specifically trying to address the following 
> cases:
> - Someone poses as a trusted developer and submits a malicious patch
> - Someone bribes me to edit a patch on to introduce a 
>   backdoor

Okay, but then post-apply-attestation doesn't help this threat
model. post-apply-attestation is surely only useful if you can check
the signature from the git data?

Like I said it would be very interesting to see data on how well these
signatures could survive, if we could get, what, 80% coverage of git
commits this way then that seems like a powerful argument for this
approach, right?


[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux