RFE: use patchwork to submit a patch

[Theodore Y. Ts'o]

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.)

> 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