[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201005141456.GA6528@openwall.com>
Date: Mon, 5 Oct 2020 16:14:56 +0200
From: Solar Designer <solar@...nwall.com>
To: Kees Cook <keescook@...omium.org>
Cc: kernel-hardening@...ts.openwall.com, linux-hardening@...r.kernel.org
Subject: Re: Linux-specific kernel hardening
Hi Kees,
On Wed, Sep 30, 2020 at 11:02:32AM +0200, Solar Designer wrote:
> Messages that are auto-approved don't create any work for either of us,
> and that's the majority of them. Messages that are held for moderation
> (until I add the sender to moderation bypass) do involve some work, but
> that's the only way to avoid spam on the list. I think that amount of
> work is small compared to all subscribers' time wasted on occasional
> spam on the list. If it's unacceptable for you, I can remove you from
> list moderators and maybe add someone else as a co-moderator. I think
> it wouldn't be hard for us to find a volunteer. Please let me know.
Someone has already volunteered. I'd also like to hear from someone
possibly not as over-qualified and as busy as that person is. ;-)
Kees, if you'd like to step down as a co-moderator for kernel-hardening,
please let me know. We'll add someone else (so that this doesn't depend
solely on me being around).
To avoid misinterpretation: I am not suggesting that you need to step
down, totally not. I merely feel that you need to have the option since
you expressed unhappiness with having to spend effort on that.
> That's a major misunderstanding. I cared primarily about the well-being
> of KSPP, and not so much about hosting/administering a list with a
> policy I disagree with in a minor way, which I accepted. I didn't want
> to continue that discussion "for very long" as it "hurts actual work",
> not because I disagreed with you (although I did) and insisted on that
> deciding list policy (I did not, and it did not). BTW, now we're having
> another such discussion that hurts actual work, so I am also not going
> to continue it for very long.
It is weird that I now feel I have to spell it out explicitly, but I do,
so: Kees, please don't use my saying that I don't want to continue this
bikeshed discussion "for very long" as an excuse for lack of
coordination on your part, again. That's not a valid excuse, nor do you
need one. You can always coordinate with me off-list if you prefer, but
I don't mind this thread continuing on the list for a little while.
> 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 paragraph
above, so at least you need to confirm whether my guesses are correct,
or correct me if they are not.
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".
I think topics more desirable on kernel-hardening would be deciding on
such replacements in general (not patches for individual instances),
introduction of such helpers, etc. Also summaries of work done (e.g.,
"this-many instances of that-thing were updated to new conventions in
the kernel over the last month as discussed in those threads seen in
that list archive"). I use examples from the past because that's what
we have, but I use them to illustrate roughly what kinds of things we
could possibly have on one list vs. the other in the future.
Thanks,
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.
