Date: Mon, 16 May 2022 10:43:33 -0300 From: Thadeu Lima de Souza Cascardo <cascardo@...onical.com> To: oss-security@...ts.openwall.com Cc: Solar Designer <solar@...nwall.com> Subject: Re: linux-distros list policy and Linux kernel On Mon, May 16, 2022 at 03:12:20PM +0200, Jason A. Donenfeld wrote: > Hi Alexander, > > I think a lot of this depends on what you feel the primary value in > distros@ is. > > I always thought its primary purpose was to centralize embargoed > vulnerability reports, using its presence as *the* de facto forum for > that, in order to receive nearly all embargoed bugs. Then, those bugs > become subject to the distros@ 14-day disclosure policies. Seen this > way, distros@ is a mechanism for ensuring that bugs eventually *do* > become disclosed, rather than languishing in embarrassed vendor > purgatory forever. > > Maybe I'm far off, though, so it'd be interesting to learn if you have a > different idea of its value. > [...] > And anyway, practically speaking, security@...nel.org's disclosure > deadline is usually something like 7 days, which is pretty short, so for > people who misread the documentation, at most they'll only be miffed > about a few days, rather than a few months. > Though I want to add a little more to this discussion, I think this needs clarification and is really one of the main pain points here, in my opinion. "Although our preference is to release fixes for publicly undisclosed bugs as soon as they become available, this may be postponed at the request of the reporter or an affected party for up to 7 calendar days from the start of the release process" This is about the fixes, not the security report. As I read it, once a fix is developed/reviewed/accepted, kernel maintainers/developers may hold the *fix* release up to 7 days. Right in the next paragraph, though: "While embargoed information may be shared with trusted individuals in order to develop a fix, such information will not be published alongside the fix or on any other disclosure channel without the permission of the reporter. This includes but is not limited to the original bug report and followup discussions (if any), exploits, CVE information or the identity of the reporter." This means that it's now up to the reporter to disclose any information if they want to. They may never disclose it. They may wait for someone else to disclose it. Or decide to disclose it immediately. Now, as you said earlier in your message (which is why I kept that excerpt), linux-distros ends up having such a role where reports sent to it should be made public in no more than 14 days. But there is no such mechanism on security@...nel.org rules as documented at Documentation/admin-guide/security-bugs.rst, as I understand it. Cascardo. > So I think maybe your option (0) makes sense? Enforce the policy, which > has worked well enough for a long while now. > > Jason > >  https://git.kernel.org/torvalds/c/d114b9fe78c8d >  https://lists.immunityinc.com/pipermail/dailydave/2015-August/000976.html >  https://git.kernel.org/torvalds/c/e3c1c4fd9e6d1
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.