public inbox for kernel-hardening@lists.openwall.com
 help / color / mirror / Atom feed
From: "Tobin C. Harding" <me@tobin.cc>
To: Tycho Andersen <tycho@tycho.ws>
Cc: Kees Cook <keescook@chromium.org>,
	Solar Designer <solar@openwall.com>,
	kernel-hardening@lists.openwall.com,
	Mrinal Pandey <mrinalmni@gmail.com>,
	Tycho Andersen <tycho@tycho.pizza>
Subject: Re: [PATCH] scripts: Add intended executable mode and SPDX license
Date: Tue, 1 Sep 2020 14:24:50 +1000	[thread overview]
Message-ID: <20200901042450.GA780@ares> (raw)
In-Reply-To: <20200901001519.GA567924@cisco>

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@chromium.org>
> > > R:      Emese Revfy <re.emese@gmail.com>
> > > L:      kernel-hardening@lists.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@tobin.cc>
> > > M:      Tycho Andersen <tycho@tycho.ws>
> > > L:      kernel-hardening@lists.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@lists.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@tycho.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

  reply	other threads:[~2020-09-01  4:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-27  9:24 [PATCH] scripts: Add intended executable mode and SPDX license Mrinal Pandey
2020-08-27  9:34 ` Lukas Bulwahn
2020-08-27  9:43 ` Greg KH
2020-08-27  9:49   ` Lukas Bulwahn
2020-08-27 10:00     ` Greg KH
2020-08-27 13:06 ` Solar Designer
2020-08-27 18:02   ` Kees Cook
2020-09-01  0:15     ` Tycho Andersen
2020-09-01  4:24       ` Tobin C. Harding [this message]
2020-09-02 12:16         ` Solar Designer
2020-08-31  0:44 ` Andrew Morton
2020-08-31  5:45   ` Lukas Bulwahn
2020-08-31 19:20     ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200901042450.GA780@ares \
    --to=me@tobin.cc \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=mrinalmni@gmail.com \
    --cc=solar@openwall.com \
    --cc=tycho@tycho.pizza \
    --cc=tycho@tycho.ws \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox