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

[Willy Tarreau]

Hi Vegard,

first, thanks for doing this work.

On Sun, Mar 05, 2023 at 11:00:03PM +0100, Vegard Nossum wrote:
> Probably the easiest way to see the end result of this series is to view the
> rendered HTML which I've put here:
> https://vegard.github.io/security-v3/Documentation/output/process/security-bugs.html

I'm seeing a few points that could be improved but I don't have much to
propose right now, I'll just enumerate issues we've faced in the past or
that continue to pop up from time to time and that require extra effort
from the team:

  - 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".

  - we always need to be able to describe the nature of a bug in the
    commit message so that if the patch is found to cause a regression,
    its purpose can at least be understood and argumented. It happened
    at least once that we were requested not to explain the details
    because a paper was about to be issued, and that's not acceptable
    at all because it means that it becomes very complicated to have
    public discussions about possible forthcoming issues. I think that
    after the paragraph suggesting that the details of an issue or its
    exploit code might not always be published, it could be useful to
    mention something along the fact that the reporter shall not
    request the security team to withhold technical details about the
    issue as long as it doesn't represent an imminent danger.

  - 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.

  - 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.

Thanks,
Willy