Re: RFE: use patchwork to submit a patch

From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: "Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Daniel Axtens" <dja@axtens.net>,
	"Stephen Hemminger" <stephen@networkplumber.org>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Dave Airlie" <airlied@gmail.com>,
	"David Miller" <davem@davemloft.net>,
	skhan@linuxfoundation.org,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	patchwork@lists.ozlabs.org, workflows@vger.kernel.org
Subject: Re: RFE: use patchwork to submit a patch
Date: Mon, 14 Oct 2019 10:41:32 -0300	[thread overview]
Message-ID: <20191014104132.76b19507@coco.lan> (raw)
In-Reply-To: <20191014122637.GB5564@mit.edu>

Em Mon, 14 Oct 2019 08:26:37 -0400
"Theodore Y. Ts'o" <tytso@mit.edu> escreveu:

> On Mon, Oct 14, 2019 at 12:42:36PM +0200, Toke Høiland-Jørgensen wrote:
> > It should be detectable, though, right?
> > 
> > Say you have two independently administered patchwork instances (or even
> > better, two different software packages entirely) that both subscribe to
> > the mailing lists, and compare patch content with each other. They
> > should at least be able to detect mismatches. Especially if you add a
> > sanity check before discarding duplicate message-ids.  
> 
> They don't even need to compare against each other; patchwork is about
> to add a feature where you can look up patches via message-id, right?
> That means it's easy enough to write a program which fetches patches
> from patchwork, and compares it to the patches found in
> lore.kernel.org.  If they don't match, then an alarm can be sounded.
> 
> Individuals who are reviewing patches can also compare the copy in
> their inbox with the copy from lore or some other public inbox.  And
> maintainers can compare copies from lore.kernel.org and patchwork
> before they apply a patch.  (99% of the time, I actually use the patch
> from my inbox, anyway.)

It can still have man-in-the-middle (MITM) attacks between the sender and
vger.kernel.org. Please notice that using https and adding the patch
via a web interface can also be subject to MITM, as companies and even some
Countries with strong policy enforcement may have some gateway on their
infra that will prevent end-to-end encryption[1], blocking direct
client-server https tunnels.

[1] They add an internal certificate to the browsers, so that the client
will see the connection as trustful, but the infra will actually do two
separate HTTPS encryption:

	client  ---> Gateway
	Gateway ---> Server

While unlikely, nothing prevents that the patch would be maliciously 
altered at the Gateway.

From security PoV, the only way to ensure that the patch was not
altered is to have it signed by the one who wrote it.

> 
> > This way you'd need to compromise multiple machines to achieve the kind
> > of compromise you're worried about. And you can add more independent
> > machines until you're satisfied that the risk is low enough :)  
> 
> Yep, exactly.  This is basically the theory behind Certificate
> Transparency[1], applied to patches.  For example, here's the
> certificate transparency report for kernel.org:
> 
>    https://transparencyreport.google.com/https/certificates?cert_search=domain:kernel.org
> 
> 					- Ted
> 
> [1] http://www.certificate-transparency.org/what-is-ct

That won't prevent companies/governments to require the manual
installation of the gateway's certificate on their browers, in order
to be able to navigate using https.

Thanks,
Mauro