[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201005164818.GA6878@openwall.com>
Date: Mon, 5 Oct 2020 18:48:18 +0200
From: Solar Designer <solar@...nwall.com>
To: "Theodore Y. Ts'o" <tytso@....edu>
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 12:02:55PM -0400, Theodore Y. Ts'o wrote:
> 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?
I don't care much whether it's "to the Openwall list" or not, but I do
feel that actual kernel hardening discussions are hampered by the
administrivia, no matter where they occur. I suggested an easy way to
remove a small portion of the administrivia (by far not all of it, but
a portion that's the easiest to remove): drop the list from MAINTAINERS.
Unfortunately, this contributed to the split of the list in two, which
I'm concerned might not work well. If I knew where this would lead, I
wouldn't have suggested that.
> If that is true, it's not something that moderation will fix by
> somewhere,
Sure. I never suggested we could fix that with moderation.
> but it that traffic needs to go *somewhere*.
I thought it wasn't an absolute requirement to have a mailing list
specified for every entry in MAINTAINERS, but if it is then I'm fine
with replacing the two mentions of kernel-hardening in MAINTAINERS with
another list, and I'm also fine with keeping kernel-hardening in there
if the alternative is even worse.
> > 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.
Right, but like you say this is challenging. It's a surprise to me it
worked OK for a few days, and I doubt that will always be the case.
> The challenge is whether we can get people to subscribe to two lists,
If 100% of the topics on linux-hardening are supposed to be a subset of
what was on kernel-hardening, I think it'd be OK for me to provide the
subscriber list to a vger admin, who would subscribe those people to
linux-hardening. However, after that point the subscriber lists will
start to differ, and that's actually what we should want if we want a
split of topics at all. If the same sets of people were on both lists
at all times, then there's obviously no point in the split.
> 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.
This also happens the other way around - an architectural discussion can
result in many administrivia sub-threads resulting from patch review.
> 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.)
Right, and this is also why I wouldn't have suggested splitting the
kernel-hardening list, and found this so problematic. I just felt the
two mentions in MAINTAINERS were unlikely to result in such problems (if
removed or re-pointed to elsewhere), based on what I saw directed to
kernel-hardening via those so far (although I admit I have no reliable
way to determine why exactly a thread was CC'ed to kernel-hardening).
Alexander
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.
