On Mon, Mar 06, 2023 at 08:11:38AM +0100, Willy Tarreau wrote: > - I'm not seeing anywhere that the security list is *exclusively* > for kernel issues. That might explain why about once a week or so > we receive messages like "there's a bug in that userland tool" or > "we've found an XSS issue on your website". It's written that kernel > bugs should be reported to the security list but I think we should > strengthen that by adding "This list is exclusively used for Linux > kernel security reports, please do not report issues affecting any > other component there". I think the wording would be "Please report security bugs against Linux kernel to security@xxxxxxxxxx list. Security bugs against userspace applications should be reported to appropriate channels for affected applications instead." > - it's quite frequent that reporters post from dummy addresses, > looking like randomly generated ones (we even had one looking > like a smiley). It doesn't help to communicate with them at all. > I can understand how some working as consultants for a customer > would want to avoid disclosing a particular relation between their > finding and their customer, but at least they should indicate how > they should be called. I.e. "call me Margarett" is not difficult > and simplifies exchanges when the address is "69236836@xxxxxxxxxxx". > And often we see at the end that they're willing to provide a real > name to be credited for the finding, so most likely starting with > this real name could be easier. > Something like temporary addresses (à la maildrop or mail.gw)? > - it's more a discussion for the list itself, but the wording continues > to make one think that the reporter should expect the list members to > develop a patch, while in practise the first thing that's asked is > "since you've studied the problem well, do you happen to have a patch?". > And it happened a few times that in response we got "oops sorry, I > analysed it wrong, there's no issue there". I think the text should > emphasize more on encouraging submitters to complete their work with > a patch proposal (that's also helpful to confirm an analysis). And > conversely I think that reports for non-immediately exploitable issues > that are found by code analyzers (and almost always come without a > patch) should not be sent to this list and should be discussed and > addressed publicly instead. It's more efficient and allows more > knowledgeable participants to have their say on the root cause of > the problem and its possible solutions. That's of course not always > the case, but common sense should prevail here. I think the wording would be "It is preferrable to have a proposed patch for the bug you report. See Documentation/process/submitting-patches.rst for details on how to submit patches." Thanks. -- An old man doll... just what I always wanted! - Clara
Attachment:
signature.asc
Description: PGP signature
