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.