[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 21 Sep 2023 23:11:42 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Vegard Nossum <vegard.nossum@...cle.com>, Jiri Kosina <jkosina@...e.cz>,
Donald Buczek <buczek@...gen.mpg.de>,
Greg KH <gregkh@...uxfoundation.org>
Subject: Re: linux-distros list policy and Linux kernel, again
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
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.
