Re: Lyon meeting notes

[Eric Wong <e@80x24.org>]

"Theodore Y. Ts'o" <tytso@mit.edu> wrote:
> On Fri, Nov 01, 2019 at 04:07:55PM -0400, Konstantin Ryabitsev wrote:
> > The argument was that attempts to sneak in malicious code while
> > pretending to be someone else would be quickly discovered, because any
> > significant code contribution requires back-and-forth and if the "From"
> > address is spoofed, then the real developer would quickly point out that
> > they are not the actual author of the code.
> > 
> > My counter-argument is that history proves that we can't trust humans to
> > recognize maliciously misspelled domains. If you receive a submission
> > like this:
> > 
> > From: Konstantin Ryabitsev <konstantin@linuxfoudnation.org>
> > 
> > you will need to pay very close attention to that "d" and "n" to realize
> > that it didn't actually come from me.
> 
> The other caution I'd raise here about why signing individual commits
> might not be the panacea we might hope it would be is that the vast
> majority of kernel developers don't today have cryptographic
> identities, and we are constantly welcoming new developers to kernel
> development.
> 
> Even if we did have a way to get new ED25519 keys signed for all of
> these new developers, knowing their identity says nothing about how
> much they are (or should be) trusted.
> 
> Consider that any sufficiently well-resourced actor who really wants
> to sneak in malicious code, especially when we consider how much
> zero-day exploits are worth on the open market, will be quite willing
> to establish a "legend" for a developer.  The "developer" might submit
> a dozen cleanup patches, all of which are good, and genuninely improve
> the kernel --- and it will be the 13th or the 31st submit that will
> have the malicious change hidden in it.  The fact that it is signed by
> a key that had previously signed 30 patches says nothing about how
> good the 31st patch will be.

Agreed.  A well-resourced adversary could also coerce a
well-meaning developer into signing a malicious change.  Perhaps
I'm paranoid, but that's a really scary thing if people rely on
identities and reputation too much.  I've always cautioned users
against trusting me for that reason (that and I'm error-prone :x)

> For bonus style points, the patch might have something which claims to
> be the application of a Coccinelle semantic patch --- and maybe in the
> V1 and V2 version of the patch series, it was in in fact a Coccinelle
> patch, but in the v3 patch, that's where malicious code was slipped
> in, and since V2 had received a Reviewed-by, and it was supposedly an
> automatically generated Coccinelle patch, no one took a close look and
> noticed that the v3 version of the patch was different from the v2
> version....
> 
> There are certainly ways we could try to make this sort of thing
> harder; we can have tools that verify that the Coccinelle script
> mentioned in the commit description actually matches with what the
> commit changes.  And we could also have tools which flags deltas
> between the Vn and Vn+1 version of a patch, especially after the Vn
> version of the patch has gotten a reviewed-by.  It's just that none of
> these fixes have anything to do with digital signed commits.

Some of that could be automated, yes, but maintainers must still
remain vigilant.

A lot of it could be a culture prioritizing feature development
over long-term maintenance and review; so improving the
eyes-to-code ratio is needed.  That's a deeper issue which
affects every project, unfortunately.