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
