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]
Date:   Sat, 3 Oct 2020 09:27:10 +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 02/26] docs: reporting-bugs: Create a TLDR how to
 report issues

Randy, many thanks for looking through this, you feedback is much
appreciated! 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 02.10.20 um 04:32 schrieb Randy Dunlap:
> On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
> […]
>> +<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/MAINTAINERS>`_
>> +how developers of that particular area expect to be told about issues; note,
>    for how
> ?

Not sure myself, but I guess you're right and thus followed your advice :-D

> […]
>> +Make sure to use a vanilla kernel and avert any add-on kernel modules externally
>> +developed; also ensure the kernel is running in a healthy environment and does
>> +not 'taint' itself before the issue occurs. If you can reproduce it, write a
> 
> I don't care for "does not 'taint' itself". How about
>                                                                          and is not
>    already tainted before the issue occurs.

Hmmm, what I wanted to bring across: the kernel is not tainted when it
arrives, it taints itself after it was started. You suggestion removes
that intention, but now that I read my text again I notice it wasn't
really good at it either. Ohh well, I guess I go with your suggestion,
as it seems bringing that point over it asking for too much here.

> […]
>> +You can't reproduce an issue with mainline you want to see fixed in older
>> +version lines? Then make sure the line you care about still gets support.
>> +Install its latest release as vanilla kernel. If you can reproduce the issue
> 
> Is "vanilla" well understood?

I'd say for the TLDR using it without and explanation is fine. But the
main section didn't prominently mention it, that why I added the first
step slightly and added this:

This kernel must not be modified or enhanced in any way and thus be
'vanilla'.

Ciao, Thorsten

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ