Looking for help testing patch attestation

[Paul Moore]

[NOTE: fixed with the proper linux-audit address]

On Tue, Mar 17, 2020 at 6:51 PM Paul Moore <paul at paul-moore.com> wrote:
> On Tue, Mar 17, 2020 at 6:12 PM Konstantin Ryabitsev
> <konstantin at linuxfoundation.org> 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 at linux.kernel.org 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