Message-ID: <20241026175446.GA9630@1wt.eu>
Date: Sat, 26 Oct 2024 19:54:46 +0200
From: Willy Tarreau <w@....eu>
To: Jiaxun Yang <jiaxun.yang@...goat.com>
Cc: "Theodore Ts'o" <tytso@....edu>, linux-kernel@...r.kernel.org,
        conduct@...nel.org, security@...nel.org, cve@...nel.org,
        linux-doc@...r.kernel.org,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>, shuah@...nel.org,
        lee@...nel.org, sashal@...nel.org, Jonathan Corbet <corbet@....net>
Subject: Re: Concerns over transparency of informal kernel groups

On Sat, Oct 26, 2024 at 05:33:16PM +0100, Jiaxun Yang wrote:
> > There's quite a bit of information available in the Linux Kernel
> > documentation.  For example:
> >
> > * https://www.kernel.org/doc/html/latest/process/security-bugs.html
> > * https://www.kernel.org/doc/html/latest/process/code-of-conduct.html
> > * https://www.kernel.org/code-of-conduct.html
> 
> Thank you for the pointers. My concerns actually rooted from the first two
> documents, and I was directed to the third link off-list following my
> initial post.
> 
> In process/security-bugs, the term "security officers" is consistently mentioned,
> yet it's unclear who they are, what specific privileges they hold compared to
> regular developers,

The "security officers" is just a small group of trusted maintainers
(~20) who devote some of their spare time (and possibly some work time
as well) reviewing, triaging, and forwarding some security reports that
arrive there. I think the term "security officers" is used essentially
to remind that reporters are interacting with real people without the
heavy weight of processes or whatever some could possibly imagine.

I'm not aware of a public list of participants, though the list of
participants is shared between the members from time to time when one
arrives or leaves. I think discretion is key here because I'm not even
sure that every participant's employer knows that they're on that list,
and it's better this way, as some might try to exert pressure to try
to get some early notifications, which is absolutely forbidden.

Participants are quite responsible people. Some have already left the
list by lacking time to participate, some temporarily or definitely.
New participants are sometimes asked to join because they're involved
in many of the reports, and that way they can directly interact with
the reporter without anyone having to review and forward them the
messages first.

So if you wonder who's there, just ask yourself who can speed up the
process by participating when there are frequent reports in their area
of expertise, and you'll guess by yourself a few of them :-)

> and how security fixes are expected to reach Linus's tree
> during an embargo period.

There's no hard-rule there. Some fixes are written by some of the team
members because the bug is directly in the subsystem they maintain so
for them the easiest path is to take the patch and add it to their
pending queue. Most of the time the fixes are forwarded to maintainers
not part of the list and they deal with them the way they're used to
for other bugs reports. Most of the time bug reporters are told that
their report is not critical and should be handled the regular way (as
it's always better to have public discussions on fixes). It's super
rare that fixes are merged directly by Linus himself. It could happen
because there's a huge emergency, but history told us that bugs handled
in emergency do not always result in the best fixes. Also if one is
seeking discretion, the last thing to do is to merge the fix without
sharing it on a public list, as that's what attracts suspecting eyes :-)

Also, for the vast majority of bug reports there's no embargo period
requested by the reporter, as most of them just want bugs to be fixed.
I think it might be less than 1-2% for which an embargo is requested,
and that's fine because fixes don't wait. Most of the time once the
fix is agreed upon by the different parties and passes the reporter's
tests, it gets merged in the maintainer's tree.

I noticed many times that there are some fantasies around the security
list because it's not public, so people in quest of amazing stories may
imagine lots of stuff happening there. The reality is that it's exactly
like any other topic list where bugs are discussed between maintainers
and bug reporters, but the discussions are just not public since they
would directly put many users around the world in trouble without even
having a chance to protect themselves. Another benefit of not being
public is that it's easier for reporters to share traces, captures etc.
They don't need to waste their time anonymizing them (though most of the
time there's absolutely nothing confidential shared anyway, but an IP or
MAC address can remain without having to hide them as is often done on
public reports).

Really there's nothing special about that list, it simply helps to put
bug reporter in relation with the appropriate maintainers and save them
from trivial mistakes, because it's always frightening to report a
security issue to a project, you always fear you're sending to the wrong
people and will cause unexpected trouble. That list is there to address
this specific point, and to make sure the report is not forgotten.

I hope this clarifies its role a bit!
Willy

Powered by blists - more mailing lists