[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 1 Sep 2020 14:24:50 +1000
From: "Tobin C. Harding" <me@...in.cc>
To: Tycho Andersen <tycho@...ho.ws>
Cc: Kees Cook <keescook@...omium.org>, Solar Designer <solar@...nwall.com>,
kernel-hardening@...ts.openwall.com,
Mrinal Pandey <mrinalmni@...il.com>,
Tycho Andersen <tycho@...ho.pizza>
Subject: Re: [PATCH] scripts: Add intended executable mode and SPDX license
On Mon, Aug 31, 2020 at 06:15:19PM -0600, Tycho Andersen wrote:
> On Thu, Aug 27, 2020 at 11:02:00AM -0700, Kees Cook wrote:
> > On Thu, Aug 27, 2020 at 03:06:53PM +0200, Solar Designer wrote:
> > > On Thu, Aug 27, 2020 at 02:54:05PM +0530, Mrinal Pandey wrote:
> > > > mode change 100644 => 100755 scripts/gcc-plugins/gen-random-seed.sh
> > >
> > > This is basically the only change relevant to the contribution initially
> > > made via kernel-hardening, and in my opinion (and I am list admin) isn't
> > > worth bringing to the list. Now we have this bikeshed thread in here
> > > (and I'm guilty for adding to it), and would have more (which I hope
> > > this message of mine will prevent) if changes to something else in the
> > > patch(es) are requested (which Greg KH sort of already did).
> > >
> > > I recall we previously had lots of "similar" bikeshedding in here when
> > > someone was converting the documentation to rST. The more bikeshedding
> > > we have, the less actual kernel-hardening work is going to happen,
> > > because the list gets the reputation of yet another kernel maintenance
> > > list rather than the place where actual/potential new contributions to
> > > improve the kernel's security are discussed, and because bikeshedding
> > > makes the most capable people unsubscribe or stop paying attention.
> > >
> > > How about we remove kernel-hardening from the MAINTAINERS entries it's
> > > currently in? -
> > >
> > > GCC PLUGINS
> > > M: Kees Cook <keescook@...omium.org>
> > > R: Emese Revfy <re.emese@...il.com>
> > > L: kernel-hardening@...ts.openwall.com
> > > S: Maintained
> > > F: Documentation/kbuild/gcc-plugins.rst
> > > F: scripts/Makefile.gcc-plugins
> > > F: scripts/gcc-plugin.sh
> > > F: scripts/gcc-plugins/
> > >
> > > LEAKING_ADDRESSES
> > > M: Tobin C. Harding <me@...in.cc>
> > > M: Tycho Andersen <tycho@...ho.ws>
> > > L: kernel-hardening@...ts.openwall.com
> > > S: Maintained
> > > T: git git://git.kernel.org/pub/scm/linux/kernel/git/tobin/leaks.git
> > > F: scripts/leaking_addresses.pl
> > >
> > > Alternatively, would this be acceptable? -
> > >
> > > L: kernel-hardening@...ts.openwall.com (only for messages focused on core functionality, not for maintenance detail)
> > >
> > > I think the latter would be best, if allowed.
> > >
> > > Kees, please comment (so that we'd hopefully not need that next time),
> > > and if you agree please make a change to MAINTAINERS.
> >
> > A comment isn't going to really help fix this (much of the CCing is done
> > by scripts, etc).
> >
> > I've tended to prefer more emails than missing discussions, and I think
> > it's not unreasonable to have the list mentioned in MAINTAINERS for
> > those things. It does, of course, mean that "maintenance" patches get
> > directed there too, as you say.
> >
> > If it's really something you'd like to avoid, I can drop those
> > references. My instinct is to leave it as-is, but the strength of my
> > opinion is pretty small. Let me know what you prefer...
>
> One thing about leaking_addresses.pl is that I'm not sure anyone is
> actively using it at this point. I told Tobin I'd help review stuff,
> but I don't even have a GPG key with enough signatures to send PRs.
> I'm slowly working on figuring that out, but in the meantime I wonder
> if we couldn't move it into some self test somehow, so that at least
> nobody adds new leaks? Does that seem worth doing?
>
> It would then probably go away as a separate perl script and live
> under selftests, which could mean we could drop the reference to the
> list. But that's me making it someone else's problem then, kind of :)
>
> Also, I'm switching my e-mail address to tycho@...ho.pizza, so future
> replies will be from there.
I don't mind if the reference to kernel-hardening is removed, if in
the event that someone sends a patch that needs input from the kernel
hardening community we can always mail the list.
Thanks,
Tobin
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
