[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9b3e0209-5792-d614-6258-92a54cd2e3c2@oracle.com>
Date: Tue, 14 Sep 2021 15:36:21 -0700
From: Alan Coopersmith <alan.coopersmith@...cle.com>
To: oss-security@...ts.openwall.com, Solar Designer <solar@...nwall.com>
Subject: Re: Oracle Solaris membership in the distros list
On 9/6/21 11:35 AM, Solar Designer wrote:
> Hi Alan,
>
> I'm sorry for the delayed response.
No worries - I figured it was that time of year, and this isn't something
that has to be resolved immediately.
> I'm happy to vouch for you and Casper, and you can then vouch for Pavel.
Thanks.
>> So should we just expand the existing Oracle membership to cover both teams
>> or do we need to apply separately as the Oracle Solaris team?
>
> I think it's best to separately add Oracle Solaris to the distros list.
Okay - a more typical application form follows.
>> If we need to apply separately, how is the "giving back" criteria handled
>> for orgs who are only on distros and not linux-distros, and thus can't
>> perform most of the tasks given? (I don't see the BSD's listed for any
>> of the tasks there.)
>
> There has been no such precedent so far (the two *BSDs were subscribed
> before the "contributing back" tasks were introduced). The below task
> looks suitable (and I'd appreciate help on it):
>
> Administrative tasks mostly unrelated to (linux-)distros lists (but
> relevant to the wider community)
>
> Help ensure that each message posted to oss-security contains the
> most essential information (e.g., vulnerability detail and/or exploit)
> directly in the message itself (and in plain text) rather than only by
> reference to an external resource, and add the missing information
> (e.g., in your own words, by quoting with proper attribution, and/or by
> creating and attaching a properly attributed text/plain export of a
> previously referenced web page) and remind the original sender of this
> requirement (for further occasions) in a "reply" posting when necessary
That seems like something we could help with. I also note that there are
many vulnerabilities we discover in the FOSS packages we ship that never
make it to this list - when the researchers or project maintainers don't
send notices to oss-security, should folks like us at least give a heads
up here?
One obvious one in the last week was the highly publicized Ghostscript
"0 day" - aka CVE-2021-3781, for which the upstream bug report is at
https://bugs.ghostscript.com/show_bug.cgi?id=704342 and media report at
https://therecord.media/ghostscript-zero-day-allows-full-server-compromises
(and yes, as noted in the above quote, an actual report to the list
needs more details than just these url's).
Of course, we ship a smaller subset of FOSS than most Linux distros do,
so we won't spot everything, but can help contribute to a larger effort.
-Alan Coopersmith- alan.coopersmith@...cle.com
Oracle Solaris Engineering - https://blogs.oracle.com/alanc
For the eligibility criteria:
> 1. Be an actively maintained Unix-like operating system distro with
> substantial use of Open Source components
Oracle Solaris 11.4 is the latest version of an unbroken chain going back
over 35 years through Oracle & Sun Solaris releases, and SunOS before that.
Updates are posted monthly to our support repositories, as reported in our
public blog at https://blogs.oracle.com/solaris/ and interim relief is
provided to support customers between those releases.
While our kernel and many core OS components are closed source, the majority
of packages in our package repository are external Open Source. A list of
the over 1000 open source components shipped in the Solaris 11.4 release in
August 2018 is at:
https://docs.oracle.com/cd/E37838_01/html/E61065/osplg-tparty.html
Current build recipes for most of the FOSS packages we ship in current updates
can be found at https://github.com/oracle/solaris-userland/ or in the FOSS
source release archives at:
https://objectstorage.us-phoenix-1.oraclecloud.com/n/solarisx86/b/opensource/o/sol-11_4_37_101_1-opensource_1.zip
https://objectstorage.us-phoenix-1.oraclecloud.com/n/solarisx86/b/opensource/o/sol-11_4_37_101_1-opensource_2.zip
https://objectstorage.us-phoenix-1.oraclecloud.com/n/solarisx86/b/opensource/o/sol-11_4_37_101_1-opensource_3.zip
https://objectstorage.us-phoenix-1.oraclecloud.com/n/solarisx86/b/opensource/o/sol-11_4_37_101_1-opensource_4.zip
https://objectstorage.us-phoenix-1.oraclecloud.com/n/solarisx86/b/opensource/o/sol-11_4_37_101_1-opensource.digest.txt
(Those zip files primarily bundle in the external source archives that are
just referenced in the github repo, providing a permanent copy of the code
should the upstream download URL's stop working at some point.)
> 2. Have a userbase not limited to your own organization
Oracle Solaris is used by over 10,000 organizations worldwide.
> 3. Have a publicly verifiable track record, dating back at least 1 year and
> continuing to present day, of fixing security issues (including some that
> had been handled on (linux-)distros, meaning that membership would have
> been relevant to you) and releasing the fixes within 10 days (and
> preferably much less than that) of the issues being made public (if it
> takes you ages to fix an issue, your users wouldn't substantially benefit
> from the additional time, often around 7 days and sometimes up to 14 days,
> that list membership could give you)
The Solaris organization has a track record going back decades for fixing
security issues, as seen on:
https://www.oracle.com/security-alerts/sunalertslisting.html
https://www.oracle.com/security-alerts/#SolarisThirdPartyBulletin
As for timeliness:
We learned about CVE-2021-3156 in sudo from the oss-security posting on
January 26, 2021 and made interim relief available to customers on January 28.
We learned about CVE-2020-1971 in OpenSSL from the public disclosure on
December 8, 2020, and made interim relief available to customers on December 16.
We learned about CVE-2019-14287 in sudo from the oss-security posting on
October 14, 2019, and made interim relief available to customers on October 22.
> 4. Not be (only) downstream or a rebuild of another distro (or else we need
> convincing additional justification of how the list membership would
> enable you to release fixes sooner, presumably not relying on the upstream
> distro having released their fixes first?)
Solaris is different enough that we can't rely on another distro and must
maintain our own package sets. There are Oracle products downstream of us
who would be releasing fixes for their product using our work - these include
the ZFS Storage Appliance, SPARC SuperCluster, and MiniCluster.
> 5. Be a participant and preferably an active contributor in relevant public
> communities (most notably, if you're not watching for issues being made
> public on oss-security, which are a superset of those that had been
> handled on (linux-)distros, then there's no valid reason for you to be on
> (linux-)distros)
I have been a member of oss-security since at least 2013, acting as both a
distro maintainer and as a representative of the X.Org upstream security team:
https://marc.info/?l=oss-security&w=4&r=1&s=Coopersmith&q=b
Casper has similarly been participating in oss-security for years, and earlier
lists such as bugtraq for decades, while Pavel has been monitoring oss-security
for issues we need to address in our packages.
> 6. Accept the list policy (see above)
We accept the policies as currently stated on
https://oss-security.openwall.org/wiki/mailing-lists/distros .
> 7. Be able and willing to contribute back (see above), preferably in
> specific ways announced in advance (so that you're responsible for a
> specific area and so that we know what to expect from which member),
> and demonstrate actual contributions once you've been a member for a while
See previous discussion.
> 8. Be able and willing to handle PGP-encrypted e-mail
We are, and will provide PGP keys.
> 9. Have someone already on the private list, or at least someone else who
> has been active on oss-security for years but is not affiliated with your
> distro nor your organization, vouch for at least one of the people
> requesting membership on behalf of your distro (then that one vouched-for
> person will be able to vouch for others on your team, in case you'd like
> multiple people subscribed)
See previous discussion. As well, in preparing this, John Haxby agreed to
vouch for Casper & I, and Ritwik Ghoshal agreed to vouch for all three of us.
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.
