oss-sec mailing list archives
Re: linux-distros list policy and Linux kernel
From: Greg KH <greg () kroah com>
Date: Mon, 16 May 2022 21:12:25 +0200
On Sun, May 15, 2022 at 06:27:40PM +0200, Solar Designer wrote:
Hi, This is a lengthy and belated message, yet I think is something we need to discuss in here.
Thank you for bringing it up, I appreciate it as the issues involved here have provided a lot of friction lately between the kernel security team and the linux-distros list. As I'm not a member of linux-distros, I can't dictate their requirements and rules, but I can state what I would like to see change based on my work on the kernel team. Some comments:
Options: Off the top of my head, we can do one of: 0. Do nothing specific - let things work or fail on their own.
While Jason votes for this one, I really don't like this as I feel there are problems today that I get stuck in the middle of many times (as someone who helps shepard a number of kernel security issues.) It would be great if linux-distros could change their rules a bit to help make projects like the kernel, and others, work together easier. But if no changes happen, I can still live with it, we have worse groups we deal with more often :)
1. Adjust linux-distros policy to allow "embargoes" on publicly fixed Linux kernel issues. (Only for Linux kernel, not for other projects.)
Note, the issue isn't always "fixed" issues, the issue is "we want to post a patch in public to get people to review it and to introduce it to the much wider range of CI testing systems out there. Right now if a patch is sent to the public, linux-distros treats this like an "embargo break" and will instantly post about it to oss-security, which helps no one. So if you all could just modify the rules to be something like, "embargos are not broken when changes are posted in public, or accepted into public trees, unless the changes or discussions around them turn out to disclose the security related issue." That would allow us to still get changes merged into Linus's tree, and the stable trees, and the distro trees before the oss-security announcement goes out to the world. If this happens, I will be much happier as I think it would remove all of the current friction we have today. Taking this a bit further, why is the kernel "special" for something like this? Why wouldn't this also apply to any other project with a reasonable number of developers where you want additional review and acceptance of changes before the world is notified that an issue was fixed? That allows issues to be fixed, and to be in place on users systems before the issue is made public. I would imagine that projects like Kubernetes, or Jenkins, or Docker or Mozilla or Chrome or other large systems would also fall into this category. Heck, smaller projects too, the size shouldn't matter, what matters is that users have the ability to upgrade before security issues are told to the world, ensuring that user's systems are safe. I think we can all agree that this is our overall goal anyway, to make software more secure and keep user's systems safe. Disclosing problems before the fixes even have the ability to make it to a user's systems goes directly against that goal.
2. Strictly enforce the policy as it is - and be in conflict with Linux kernel security team, and handle fewer issues via linux-distros.
That's the same as 0 today, right? Or do you mean "enforce it more strictly than we have so far today"?
3. Ask that Linux kernel issues not be reported to linux-distros at all. This is unnecessarily limiting compared to option 2 above, but maybe not so conflicting (just not using this specific medium for communication). However, I think it won't work consistently - it would be too unexpected by many (indeed, out of context it sounds plain ridiculous), and linux-distros is referenced in older Linux kernel release trees. More importantly, both teams actually want to communicate on issues somewhere, and there isn't a good alternative currently.
This one would not go very well as we don't control where reporters send their information.
4. Shut down the list. (What about the non-Linux distros list, then?) I need to migrate the setup soon and ideally also update it later, so shutting it down is as simple as not putting more effort into it. It's been around for 11 years.
I wouldn't like to see this happen as I think the distros get a lot of value out of the current situation. But it's your list, not mine, if you are tired of running it, I totally understand. thanks again for being willing to discuss this, greg k-h
Current thread:
- Re: linux-distros list policy and Linux kernel, (continued)
- Re: linux-distros list policy and Linux kernel Anthony Liguori (May 15)
- Re: linux-distros list policy and Linux kernel Jason A. Donenfeld (May 16)
- Re: linux-distros list policy and Linux kernel Thadeu Lima de Souza Cascardo (May 16)
- Re: linux-distros list policy and Linux kernel Greg KH (May 16)
- Re: linux-distros list policy and Linux kernel Seth Arnold (May 16)
- Re: linux-distros list policy and Linux kernel Greg KH (May 16)
- Re: linux-distros list policy and Linux kernel Jason A. Donenfeld (May 17)
- Re: linux-distros list policy and Linux kernel Greg KH (May 17)
- Re: linux-distros list policy and Linux kernel Jeremy Stanley (May 17)
- Re: linux-distros list policy and Linux kernel Thadeu Lima de Souza Cascardo (May 17)
- Re: linux-distros list policy and Linux kernel Thadeu Lima de Souza Cascardo (May 16)
- Re: linux-distros list policy and Linux kernel Vegard Nossum (May 20)
- Re: linux-distros list policy and Linux kernel Solar Designer (May 22)
- Re: linux-distros list policy and Linux kernel Sam James (May 22)
- Re: linux-distros list policy and Linux kernel Greg KH (May 22)
- Re: linux-distros list policy and Linux kernel eduardo vela (May 23)
- Re: linux-distros list policy and Linux kernel Mickaël Salaün (May 24)
- Re: linux-distros list policy and Linux kernel Greg KH (May 24)