[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <9479d640-2002-2462-9d81-2379d60d8f54@coreos.com>
Date: Tue, 18 Jul 2017 14:56:23 -0700
From: Euan Kemp <euan.kemp@...eos.com>
To: oss-security@...ts.openwall.com
Cc: keescook@...gle.com, Brandon Philips <brandon.philips@...eos.com>,
Alex Crawford <alex.crawford@...eos.com>
Subject: CoreOS membership to linux-distros (updated)
This is a followup to our previous thread
(http://seclists.org/oss-sec/2017/q2/619) since the criteria are now
explicit.
I’ve listed each criterion and why I think we, the Container Linux team
at CoreOS, qualify.
> 1. Be an actively maintained Unix-like operating system distro with
substantial use of Open Source components
We’ve been making regular releases for roughly the last 4 years.
All components of the distro are open source, as are all the tools used
to build it.
> 2. Have a userbase not limited to your own organization
Our distribution has a large userbase including companies and hobbyists.
It’s available as an option in quite a few clouds.
> 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)
Our release notes show a consistent history of fixing CVEs, a number of
which were discussed on the linux-distros list.
A few examples of CVEs which were discussed on linux-distros and that we
shipped patches for shortly after the embargo lifted:
CVE-2015-0235 (aka GHOST): https://coreos.com/releases/#522.6.0
CVE-2016-5195 (aka Dirty COW): https://coreos.com/releases/#1122.3.0
CVE-2016-8655 (af_packet race): https://coreos.com/releases/#1185.5.0
CVE-2017-6074 (DCCP): https://coreos.com/releases/#1235.12.0
> 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?)
Gentoo is the upstream for a subset of our packages, but we maintain a
number of packages separately from Gentoo and will fork from upstream to
update packages earlier in some cases.
The components we maintain largely independently include linux, bash,
and openssl, each of which has had embargoed CVEs in the past.
> 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)
We actively monitor oss-security and other channels for vulnerabilities.
We haven’t participated actively in the discussion since we’ve rarely
had anything to add.
> 6. Accept the list policy
Of course.
> 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
The Container Linux team is fairly small. Furthermore, since we package
relatively few pieces of software, a number of the CVEs won’t apply to
us and so we won’t be the best fit for covering some of the technical roles.
Based on your previous messages, it sounds like it’s expected for us to
inherit 'primary' for the administrative tasks of:
> 1. Promptly review new issue reports for meeting the list's requirements and confirm receipt of the report and, when necessary, inform the reporter of any issues with their report (e.g., obviously not actionable by the distros) and request and/or propose any required yet missing information (most notably, a tentative public disclosure date) - primary: CloudLinux, backup: vacant
> 2. If the proposed public disclosure date is not within list policy, insist on getting this corrected and propose a suitable earlier date - primary: CloudLinux, backup: vacant
I’ll also volunteer us for the administrative task of:
> 6. If multiple issues are reported at once, see if any of them can reasonably be made public sooner than the rest, and if so help untangle them and stay on top of their disclosure process
We’ll be happy to be on the lookout for possible conflation of issues
and kick off discussion if we think something can be broken up.
> 8. Be able and willing to handle PGP-encrypted e-mail
Yup.
We’ll provide relevant GPG keys separately if our membership is accepted.
> 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)
Kees Cook can vouch for Brandon Philips (both on cc).
I’m happy to answer any question or provide any additional information.
- Euan
Download attachment "signature.asc" of type "application/pgp-signature" (863 bytes)
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.
