[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
