[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] linux-distros list policy and Linux kernel, again
From:       Solar Designer <solar () openwall ! com>
Date:       2023-09-21 21:11:42
Message-ID: 20230921211142.GA14441 () openwall ! com
[Download RAW message or body]

A clarification/correction:

On Sat, Aug 26, 2023 at 12:23:59AM +0200, Solar Designer wrote:
> I recognize that 14 days might not always be enough to get a fix ready,
> especially not for many of the CPU microarchitectural issues being
> handled since mid-2017 and affecting many proprietary OSes as well (who
> may be used to much longer disclosure timelines and would object to
> Linux's earlier fix and disclosure).  I am glad that almost none of such
> issues were brought to (linux-)distros, and never when it was still more
> than 14 days until public disclosure.  We had a lot of luck there.
> Linux kernel security team has its own mailing list (encrypted, so more
> secure than s@k.o) for handling of those, which is great:
> 
> https://www.kernel.org/doc/html/latest/process/embargoed-hardware-issues.html
> 
> I mean, this is "great" within the constraints of the rest of the
> industry.  Of course, I'd very much like disclosure timelines for that
> kind of issues to also become much shorter.  This is just not the case.
> 
> In terms of (linux-)distros list policy, what can we do here?  Accept up
> to 7 days since fix is ready and thus accept arbitrarily long embargoes
> and more likely have issues "requiring" such embargoes brought to the
> list?  BTW, for CPU microarchitectural issues, that would probably need
> to be for the full distros list, not limited to Linux, and from what I
> know disclosure timelines for such issues may be 3 to 12+ months.

A linux-distros member pointed out to me off-list that the above sounded
like I'm against CPU microarchitectural issues being reported to distros
at all.  This is not the case.  There is in fact a way to report such
issues to the distros list now and stay within the current policies -
simply bring them to there when a coordinated disclosure date is already
finalized and it's in e.g. just 7 days.  In such cases, also microcode
fixes and/or proposed OS-level workarounds are likely to already exist.

For example, Tavis brought Zenbleed to the distros list 2 days before
its public disclosure here:

https://www.openwall.com/lists/oss-security/2023/07/24/1

and this little heads-up, even if over a weekend, was appreciated.

I think e.g. 7 days (anything up to 14, if the CRD is certain and final)
will work even better.

Alexander
[prev in list] [next in list] [prev in thread] [next in thread]