Date: Fri, 22 Sep 2023 19:27:55 +0200 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: illumos (or at least danmcd) membership in the distros list On Mon, Sep 18, 2023 at 05:36:13PM +0000, Dan McDonald wrote: > On Sep 15, 2023, at 5:09 PM, Solar Designer <solar@...nwall.com> wrote: > > Can you show illumos fixing non-illumos-only security issues within days > > after public disclosure, so that a few days of advance notice would have > > made those fixes even quicker? > > It's a per-illumos-distro property. OmniOS has Stable & LTS releases. Here's the current-stable > release notes, dynamically updated every time they update: > > https://github.com/omniosorg/omnios-build/blob/r151046/doc/ReleaseNotes.md > > So I'm not sure if a few days of advance notice would make those quicker, > but I do know that other distros have biweekly scheduled releases, and advance > notice there would keep those wheels spinning faster. Esp. since "patch tuesday" > is a mere one-day before the release branch is forked off on release weeks. This looks pretty good for OmniOS, e.g. for OpenSSL CVE-2023-3817 it appears to be 4 days from OpenSSL advisory on "31st July 2023" to OmniOS "r151046n (2023-08-03)", and even something like 1 day for OpenSSH update to "9.3p2, fixing CVE-2023-38408" and for "AMD CPU microcode updated to 20230719, mitigating CVE-2023-20593 on some Zen2 processors" in "r151046m (2023-07-25)" (it was brought to oss-security on July 24). That page above goes back to May 2023. Were there separate ones for older releases? For "a publicly verifiable track record, dating back at least 1 year and continuing to present day". > Our security coordination in illumos is to warn distro-runners, and they make their own > decisions based on that data. None have ever violated embargos. This sounds very different from how the existing distros list members operate. In fact, it may be inconsistent with our current policy for list members, which says: https://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-members "Aside from your participation in discussions with the reporter and on the (linux-)distros lists (including possibly continuing to CC other prior recipients of the information), the information you receive through the (linux-)distros lists must not be made public, shared, nor even hinted at anywhere beyond the need-to-know within your distro's team except with the reporter's explicit approval, until the agreed upon public disclosure date/time or substantially complete publication by others. Neither you nor others you inform may use the information for anything other than getting the issue fixed for your distro's users and, only in rare extreme cases, for deployment of maximally non-revealing changes to maintain security of your distro's infrastructure most essential to the distro users' security in face of the security issue being dealt with. The need-to-know condition is met only if the person needs to participate in one of these two activities." Note the words "within your distro's team". However, now you say you'll "warn distro-runners", and in your first message you wrote: > Like Linux, we have downstream distros. Unlike Linux, illumos is more > than what Linux would call, "kernel". So you'd be joining as upstream for multiple other distros, who you'd be sharing the info with. I'd say that per the current criteria and policy for members, those individual distros would need to qualify and join (or not) one by one. I actually doubt all of them would meet our current criteria, so your warning all of them would be a bypass. Now, given good enough reasons, the criteria could be changed or an exception could be made. I think illumos is a great project, it's great that you have a distro ecosystem, and several people I recognize have spoken in favor (including off-list). However, I am not convinced we have a case here where we'd want to accept indirect sharing of info with distros some of which might not qualify on their own. If we were to do that, then why would we be subjecting other distros (non-illumos) applying on their own to these same criteria, or would we relax for all? Please correct me if I misunderstood something, or/and suggest a way forward (either fully consistent with the constraints above or with specific changes you'd propose and the community would find reasonable). Thanks, 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.