linux-kernel - Re: [RFC PATCH v1 22/26] docs: reporting-bugs: explain what users should do once the report got out

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1e902d27-9e2a-8dab-7849-f45e22bc05ee@leemhuis.info>
Date:   Sun, 11 Oct 2020 15:29:18 +0200
From:   Thorsten Leemhuis <linux@...mhuis.info>
To:     Randy Dunlap <rdunlap@...radead.org>,
        Jonathan Corbet <corbet@....net>
Cc:     linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 22/26] docs: reporting-bugs: explain what users
 should do once the report got out

Many thx for you comments. Consider all the obvious spelling and 
grammatical mistakes you pointed out fixed, I won't mention all of them 
in this reply to keep things easier to follow.

Am 09.10.20 um 19:37 schrieb Randy Dunlap:
> On 10/1/20 1:50 AM, Thorsten Leemhuis wrote:

>> +wait a week at maximum (or just two days if it's something urgent) before
>> +sending a friendly reminder. If the maintainer is not responding in a timely
>> +manner or not handing it appropriately, mention that you are considering to
>> +escalate the issue to a higher authority and do so if there is in the end
> 
>                                              and do so if there seems to be
> no way around this.
> 
> although such a "threat" probably won't do much good.

Hmmm, yeah, I guess did not find the right tone here. But I think this 
situation needs to be mentioned in the text. And FWIW, something about 
it is even in the old text:

"""
If you suspect a maintainer is not responding to these types of bugs in 
a timely manner (especially during a merge window), escalate the bug to 
LKML and Linus Torvalds.
""""

So how about this:
```
The 'issues of high priority' (see above for an explanation) are an 
exception here: maintainers should address them as soon as possible; 
that's why you should wait a week at maximum (or just two days if it's 
something urgent) before sending a friendly reminder.

Sometimes the maintainer might not be responding in a timely manner; 
other times there might be disagreements, for example if an issue 
qualifies as regression or not. In such cases raise your concerns on the 
mailing list and ask others for public or private replies how to move 
on. If that fails, it might be appropriate to escalate the issue to a 
higher authority. In case of a WiFi driver that would be the wireless 
maintainers; if there are no higher level maintainers or all else fails, 
it might be one of those rare situations where it's okay to get Linus 
Torvalds involved.
```

Still not totally happy with it, but I better at least. Or what do other 
think about it?

Ciao, Thorsten