On Mon, Oct 05, 2020 at 04:14:56PM +0200, Solar Designer wrote: > 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. My complaint about moderation is about the list needing to be moderated at all. (I would note that your own postings to kernel-hardening@ got moderated...) While vger is certainly not perfect in its spam control, it is usually fine, and behaves well enough for many other upstream kernel lists. > > 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. My expectation would be that "new topic" RFCs/patches would be CCed to both lists. Everything else would go to linux-hardening. > 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". These threads are all on topic, as far as I'm concerned, but they easily run the "risk" of turning into bike-shedding and nuance, etc. But those are exactly the kinds of threads I want to have on linux-hardening@ (as well as the "larger" topics). > I think topics more desirable on kernel-hardening would be deciding on > such replacements in general (not patches for individual instances), Right -- and this is impossible to separate "by default" without a second list. linux-hardening@ is the default now, as declared by MAINTAINERS and mailmap. For folks wanting a wider audience for new/big topics, kernel-hardening@ can be additionally CCed. I have clarified this in the KSPP wiki now: https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Get_Involved > 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. Agreed. -- Kees Cook
