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 _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork