Message-ID: <202009291558.04F4D35@keescook>
Date: Tue, 29 Sep 2020 16:41:45 -0700
From: Kees Cook <keescook@...omium.org>
To: Solar Designer <solar@...nwall.com>
Cc: kernel-hardening@...ts.openwall.com, linux-hardening@...r.kernel.org
Subject: Re: Linux-specific kernel hardening

On Tue, Sep 29, 2020 at 09:25:17PM +0200, Solar Designer wrote:
> On Tue, Sep 29, 2020 at 10:14:03AM -0700, Kees Cook wrote:
> > New topics and on-going work will be discussed there, and I urge
> > anyone interested in Linux kernel hardening to join the new list. It's
> > my intention that all future upstream work can be CCed there, following
> > the standard conventions of the Linux development model, for better or
> > worse. ;)
> > 
> > For anyone discussing new topics or ideas, please continue to CC
> > kernel-hardening too, as there will likely be many people only subscribed
> > there. Hopefully this will get the desired split of topics between the
> > two lists.
> 
> I find this confusing.  Given that "new topics and on-going work will be
> discussed" on the new linux-hardening list, what's left for the old
> kernel-hardening list?  Just a legacy list to be CC'ed because people

My intention is to allow for linux-hardening@ to be the defacto place
for upstream Linux kernel hardening work. (And I include "upstream"
there again intentionally, and "work", which is larger than just
discussing new features.) Such a place must exist for the mechanical
and social processes inherent in the Linux kernel development model to
operate. Something needs to be listed in the MAINTAINERS file, and tools
direct email delivery much more commonly than individuals.

Since it is not part of the established Linux development processes to
_remove_ lists from CC when they're part of the maintainership chain or
git history, it's simply not possible for kernel-hardening@ to serve in
that role, given the constraints on topic applicability.

For stuff that IS a new topic, where people are explicitly choosing
what lists to send to, CCing both linux-hardening@ and kernel-hardening@
seems like the right thing to do to get that topic split.

> are still subscribed to it?  If so, it looks like basically because of
> my concern about a minor issue you chose to move the list from one place
> to another without actually addressing my concern in any way but causing
> lots of inconvenience.  That would be weird, so I hope I misunderstand.

I don't think the Linux kernel's (email) development model is compatible
with having a "strictly on-topic" mailing list as part of the standard
process. Your concerns are perfectly valid, but just not something that
I see a way to solving without significant effort (e.g. making the list
entirely moderated, etc). And moderation is actually another aspect of
the desire to move; emails are regularly auto-moderated which just
creates more manual work (for both of us).

> To me, "new topics" are certainly desirable on kernel-hardening.  Ditto
> for "on-going work" as long as it's work on kernel hardening per se
> (patch review, etc.) rather than e.g. documentation formatting fixes for
> former kernel hardening changes that are already accepted upstream and
> are only CC'ed here because of a formality (link from MAINTAINERS)
> rather than anyone's well-reasoned decision.

I don't want myself or anyone else to have to worry about where the line
is drawn. If kernel-hardening@ is on CC for new topics, we're all good.
With the MAINTAINERS file updated, and a .mailmap entry added to redirect
kernel-hardening@ to linux-hardening@, all the "mechanical" threads will
avoid kernel-hardening@, and we'll be close to what will work best for
the topic split.

> I suggested that a small minority of messages on kernel-hardening be
> removed from here.  You're effectively replacing one list with another,
> or if that's not what you're doing then you haven't described it well,
> and I wouldn't expect to "get the desired split of topics".

I understand what you mean, but I think the effort required to remove
those messages is too high. As an upstream Linux kernel maintainer, I
have different constraints on how I need a development discussion list
to operate. In the quoted thread[2] from earlier, I explained (perhaps
badly) those constraints, and you disagreed and additionally said
further discussion would hinder kernel-hardening@. It's your list and
list server, so I obviously can't make you agree to operate it the way
Linux kernel development lists are expected to work, so I didn't really
have any other choice but to start a new list. I recognize you've made a
lot of changes over the past several years (e.g. Subject prefixes, etc)
to adapt to those norms, but the list's acceptable "range of discussion"
seemed like a pretty fundamental difference that was unlikely to be
easily solved with a single list.

> Then there's also the lists' naming and the Subject on this message.
> Are you suggesting that the kernel-hardening list be used for kernel
> hardening that is not Linux specific?  That would be a reuse of an

The better distinction is between upstream and not. Another aspect driving
this change is the belief by people that the Linux Kernel Self-Protection
Project is somehow not upstream, which I think is somewhat reinforced
by the mailing list not living on vger.kernel.org. It's hardly a strong
enough reason to move (much like the auto-moderation hassles), but when
all are combined, I found the move sufficiently justified.

> abandoned list, if it would be, but I don't know whether there's demand
> for that and it's probably incompatible with continuing to CC the list
> on Linux-specific topics and it might not be well-received by all
> current subscribers who assumed it was a Linux list, which it was.

Agreed, I should have said "upstream-specific" in the Subject. That was
not clear there.

Hopefully this clears things up. I'm fundamentally seeking less
work/irritation for both of us, as well as for the folks doing upstream
work who find themselves CCing a development mailing list, and the folks
who want to just see the discussion of new features.

-Kees

> [2] https://lore.kernel.org/kernel-hardening/20200902121604.GA10684@openwall.com/

-- 
Kees Cook

Powered by blists - more mailing lists