Re: [PATCH v3 0/7] Documentation/security-bugs: overhaul

[Bagas Sanjaya]

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