Hi all, Thank you (especially Willy) for your effort on this. Out of the 3 paragraphs, the first one looks good to me as-is, but for the last two I propose the slightly edited versions below. On Sat, Oct 07, 2023 at 04:04:54PM +0200, Willy Tarreau wrote: > +Please note that the respective policies and rules are different since > +the 3 lists pursue different goals. Coordinating between the kernel > +security team and other teams is difficult since occasional embargoes > +start from the availability of a fix for the kernel security team, while > +for other lists they generally start from the initial post to the list, > +regardless of the availability of a fix. --- Please note that the respective policies and rules are different since the 3 lists pursue different goals. Coordinating between the kernel security team and other teams is difficult since for the kernel security team occasional embargoes (as subject to a maximum allowed number of days) start from the availability of a fix, while for "linux-distros" they start from the initial post to the list regardless of the availability of a fix. --- I added the part in braces to explain why the difference in when embargoes start matters. I also moved part of that sentence for consistency. Finally, I replaced "other lists" with specific reference to "linux-distros" because this paragraph talks only about 3 specific lists and on "oss-security" there are no embargoes. On Sat, Oct 07, 2023 at 06:39:36PM +0200, Willy Tarreau wrote: > On Sat, Oct 07, 2023 at 06:30:11PM +0200, Vegard Nossum wrote: > > On 07/10/2023 16:04, Willy Tarreau wrote: > > > +As such, the kernel security team strongly recommends that reporters of > > > +potential security issues DO NOT contact the "linux-distros" mailing > > > +list BEFORE a fix is accepted by the affected code's maintainers and you > > > > is s/BEFORE/UNTIL/ clearer? > > Probably, yes. I agree. Also, the sentence jumps from "reporters" to "you" implying that "you" is a reporter, but maybe it's better to make that explicit. > > > +have read the linux-distros wiki page above and you fully understand the > > > +requirements that doing so will impose on you and the kernel community. > > > +This also means that in general it doesn't make sense to Cc: both lists > > > +at once, except for coordination if a fix remains under embargo. And in > > > +general, please do not Cc: the kernel security list about fixes that > > > +have already been merged. This implies that in general a fix does not remain under embargo. However, contacting "linux-distros" only makes sense when a fix does remain under embargo (either not yet pushed to a public list/repo, or under the Linux kernel exception for a public not-too-revealing fix) - otherwise, the issue should be brought to "oss-security" right away. Edited: --- As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the "linux-distros" mailing list UNTIL a fix is accepted by the affected code's maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting "linux-distros" will impose on you and the kernel community. This also means that in general it doesn't make sense to Cc: both lists at once, except maybe for coordination if and while an accepted fix has not yet been merged. In other words, until a fix is accepted do not Cc: "linux-distros", and after it's merged do not Cc: the kernel security team. --- This allows possible Cc'ing of both lists in the time window between "fix is accepted by the affected code's maintainers" and "merged". Makes sense? I worry this distinction between accepted and merged may be overly complicated for some, but I don't have better wording. > > I was thinking about this Cc: thing and would it make sense to: > > > > 1) have LKML and other public vger lists reject messages that include > > s@k.o or (linux-)distros@ on Cc? The idea being that this is probably a > > mistake -- I believe it has happened a few times recently by mistake. > > > > 2) have (linux-)distros@ reject NEW threads (i.e. no In-Reply-To:) that > > also include s@k.o on Cc? We could include a nice message explaining why > > and to please resend when a patch has been developed and/or a disclosure > > is planned in the next 7 days. > > I don't know, maybe it would add extra config burden, but on the other > hand it could avoid the mistake from newcomers who have not read the > docs first (which happened a few times already), but if l-d becomes a > bit more flexible and tolerant to reporters' mistakes, as now documented, > it should also be less of a problem. > > > I guess the problem with this would be if > > somebody on s@k.o does a reply-all which would add distros right back in > > the loop -OR- a patch has already been developed and included. > > Then this would be deliberate, there would an in-reply-to so that would > not be a problem. I really doubt anyone from s@k.o would Cc linux-distros > anyway since it would imply disclosing some details from a reporter, and > we do not do that, it's up to the reporter to do it if they want. I think we don't want to complicate the setup, which we'd then have to explain somewhere. With my concern/edit above, also the logic isn't that simple. Alexander
