[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 31 Aug 2020 18:15:19 -0600
From: Tycho Andersen <tycho@...ho.ws>
To: Kees Cook <keescook@...omium.org>, "Tobin C. Harding" <me@...in.cc>
Cc: 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 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.
Tycho
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.
