On Tue, Mar 17, 2020 at 6:12 PM Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> wrote: > Hello, all: > > I'm reaching out to you because you're a security-oriented mailing list > and would likely be among the folks most interested in end-to-end > cryptographic patch attestation features -- or, at least, you're likely > to be least indifferent about it. :) > > In brief: > > - the mechanism I propose uses an external mailing list for attestation > data, so list subscribers will see no changes to the mailing list > traffic at all (no proliferation of pgp signatures, extra junky > messages, etc) > - attestation can be submitted after the fact for patches/series that > were already sent to the list, so a maintainer can ask for attestation > to be provided post-fact before they apply the series to their git > tree > - a single attestation document is generated per series (or, in fact, > any collection of patches) > > For technical details of the proposed scheme, please see the following > LWN article: > https://lwn.net/Articles/813646/ > > The proposal is still experimental and requires more real-life testing > before I feel comfortable inviting wider participation. This is why I am > approaching individual lists that are likely to show interest in this > idea. > > If you are interested in participating, all you need to do is to install > the "b4" tool and start submitting and checking patch attestation. > Please see the following post for details: > > https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation > > With any feedback, please email the tools@xxxxxxxxxxxxxxxx list in order > to minimize off-topic conversations on this list. Hi Konstantin, You might want to extend this test to the LSM list as well. I'm refraining from CC'ing them on this email because I don't want to spoil your beta test rollout, but I think it would be a good thing to do. Speaking as the person who merges patches for both the SELinux and audit kernel subsystems, I look at every patch I merge; I don't blindly merge patches (even from certain "trusted" individuals). Simply put, I've always considered that to be part of the job. While the patch attestation could provide some assurance about who created the patch (assuming a reasonable web-of-trust), and that it hadn't been tampered with, I feel it is more important to review correctness than it is to guarantee provenance. If you ever develop a tool which can help with the correctness part, I'll gladly jump to the front of the line to test that one! ;) Having said that, I'm happy to see work going into tools like this, and at some point I'll look into adding it into my workflow for an extra level of safety (although I'm on the fence about making it mandatory for submissions). Sorry to disappoint, but I'm probably not the best test monkey right now. -- paul moore www.paul-moore.com
