[NOTE: fixed with the proper linux-audit address] On Tue, Mar 17, 2020 at 6:51 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > 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 -- paul moore www.paul-moore.com
