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  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:   Mon, 11 Jan 2021 15:42:28 -0800
From:   Randy Dunlap <>
To:     Thorsten Leemhuis <>,
        Jonathan Corbet <>
Subject: Re: [PATCH v1 (RFC)] docs: discourage users from using

On 1/11/21 10:55 AM, Thorsten Leemhuis wrote:
> Am 11.01.21 um 19:14 schrieb Randy Dunlap:
>> On 1/10/21 4:10 AM, Thorsten Leemhuis wrote:
>>> * About 66 of those ~200 components will assign bugs to email addresses
>>>   that look valid, but 125 of them end with or
>>> Those domains do not exist anymore, mails
>>>   sent there bounce ('Unrouteable address'). It's possible that the
>>>   server might be rewriting those domain names and nevertheless
>>>   delivers new reports and comments by mails to some human; but it
>>>   seems more like they never get mailed to anyone and thus just linger
>>>   in the database; no wonder quite a few of bugs filed against such
>>>   components never get a single reply (see below).
>> Those @kernel-bugs email addresses should not be a problem:
> Ahh, interesting, many many thx. Stupid me also forgot to put Konstantin
> on the CC list (I had planned to do that, but forgot when I actually
> sent the patch :-/ ), which likely would have pointed be there as well.

Yes, since I got that from him. :)

>> AFAIK, USB bugs go to,
> Those seem to use the approach the link above describes.
>> SCSI bugs go to
> That's one of the email address that are in the database for real, which
> were mentioned in my patch description as 'looking valid':
>> netdev didn't want bugs sent there automatically IIRC, so a
>> human takes care of doing that if warranted.
> Ahh, good to know, it's really not obvious there are some humans working
> there to that take care of this. That and all those bugs that never get
> a reply look really like things are not working well.
>> Andrew Morton takes MM bugs and Cc:s them to linux-mm mailing list
>> and then asks for discussion to continue on the mailing list.
> Then what use it bugzilla here? Wouldn't it be better for people to go
> straight to the list?

Might as well, yes.

>> We
> Who is "we"? We as in "the kernel community"? Or is there actually a

Anyone who is up for it -- yes, mostly "community."

> smaller group of people you are referring to which is actively
> maintaining the list of products and components on


> Just trying to understand things better here, as there are other things
> that look strange to me and were mentioned in the patch description. For
> example: Why are there only 200 products and components on
> (some of them for historic things like the
> ac-kernels) while the MAINTAINERS file has more than 2200 entries?

I wouldn't want a separate entry for each  SPI/GPIO/regulator/USB etc.
device. That's just IMO...

>> could/should probably see if we can add more project-specific
>> mailing lists to the automatic reporting 
> Guess that would mean taking to a lot of maintainers/mailing list admins
> if they are okay with that. Who would do that?

whoever is motivated to do so.

>> -- but probably not LKML.
>> Otherwise some bug reports might never be heard about.
> Yeah, agreed.
> FWIW: I don't care too much about this whole thing, the whole idea for
> the approach I'm currently driving forward started when I did regression
> tracking in 2017. Back then I noticed quite a lot of bug reports on
> never got a single reply, even if they were good and
> looked valid. That's why I brought this forward on the maintainers
> summit ( ) and there it was discussed to
> basically go the route I'm taking currently. But I'm totally find to
> adjust that route if there are good reasons, especially as that
> discussion happened some time ago.


Powered by blists - more mailing lists