[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 5 Oct 2020 12:02:55 -0400
From: "Theodore Y. Ts'o" <tytso@....edu>
To: Solar Designer <solar@...nwall.com>
Cc: Kees Cook <keescook@...omium.org>, kernel-hardening@...ts.openwall.com,
linux-hardening@...r.kernel.org
Subject: Re: Linux-specific kernel hardening
On Mon, Oct 05, 2020 at 04:14:56PM +0200, Solar Designer wrote:
> > So your suggested use of kernel-hardening@ is for discussions of Linux
> > kernel hardening projects or work-in-progress that isn't to be submitted
> > upstream or isn't yet submitted upstream. If, and as soon as, a patch
> > series is sent upstream, that should go on the new linux-hardening@
> > list? And only in there or also CC'ed to kernel-hardening@? I'm just
> > trying to understand.
>
> We need you to comment on the above. I hope you did have some idea of
> how the topics would be split between the two lists, but you haven't
> really specified that yet. I tried to make guesses in the paragrapht
> above, so at least you need to confirm whether my guesses are correct,
> or correct me if they are not.
Perhaps this would be a helpful way of framing the issue. The list
specified in the MAINTAINERS list is the one that is going to be
automatically returned by the scripts/get_maintainer_pl script. This
gets used by kernel newbies who send things like white space fixes and
spelling corrections to said developer's list. For most
vger.kernel.org lists, we mix high-level architectural discussions
with things like trivial patches. It sounds like you don't want these
sorts of administrivia messages sent to the openwall list. Is that
correct?
If that is true, it's not something that moderation will fix by
somewhere, but it that traffic needs to go *somewhere*.
> I see there are already a few threads on linux-hardening, and those are
> not CC'ed to kernel-hardening. I am pleasantly surprised that those
> threads are about rather minor changes, which while acceptable to have
> on kernel-hardening as well IMO do not add much value to discussions
> desirable on kernel-hardening: "Replace one-element array with
> flexible-array member", "Use flex_array_size() helper", "Use
> array_size() helper", "Replace one-element array and save heap space",
> "Use fallthrough pseudo-keyword".
Exactly, that's the sort of thing that needs its own mailing list, and
moderation won't fix.
The challenge is whether we can get people to subscribe to two lists,
and redirect messages to the right list when the topic changes.
Sometimes what starts off as a seemingly trivial patch fix turns intot
an arhitectural discussion. Expecting people to change the mailing
list name when the scope of the discussion changes is probably not
realistic --- not to mention that when such a change *does* happen,
there may be missing context that will be lost since the original
message started out on "administrivia" list. (Which is why we
generally don't separate out those two buckets on the standard kernel
subsystem lists on vger.)
Cheers,
- Ted
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.
