Operating system distribution security contact lists

Two mailing lists were setup with operating system distribution security contacts.

Operating system distribution security contacts list

Currently on the distros list are representatives from:

  • All who are also on the linux-distros list below
  • FreeBSD
  • NetBSD/pkgsrc

Linux distribution security contacts list

Currently on the linux-distros list are representatives from:

  • ALT Linux
  • Amazon Linux AMI
  • Arch Linux
  • Chrome OS
  • CloudLinux
  • Debian
  • Gentoo
  • Openwall
  • Oracle
  • Red Hat
  • Slackware
  • SUSE
  • Ubuntu
  • Wind River

and independent volunteers.

List policy and instructions for reporters

Please only use these lists to report and discuss security issues that are not yet public (but that are to be made public very soon - please see below). For security issues that are already public or that are to be made public right away, please post to oss-security instead (and it's literally “instead”, not “as well”, since all of the distros in here are supposed to monitor oss-security closely as well). In either case, we're only interested in issues affecting Open Source software.

It is intended that these lists be used primarily to provide actionable information to multiple distribution vendors at once. While you may at the same time request and obtain a CVE ID (to be assigned by one of the CNAs present on these lists) for the issue you report, and that's great, please avoid using these lists if your sole purpose of their use is to obtain a CVE ID (e.g., when the affected software isn't something any of the distributions currently ship, or when they are unlikely to benefit from the advance notice). 1)

To report a non-public medium or high severity 2) security issue to one of these lists, send e-mail to distros [at] vs [dot] openwall [dot] org or linux [dash] distros [at] vs [dot] openwall [dot] org (just one of these lists depending on who you want to inform), preferably PGP-encrypted to the key below (yes, same key for both lists). Be sure to include [vs] (four characters) in the Subject line, or your message will most likely 3) be rejected by the mail server. (This helps us filter out spam, and confirm that you indeed read this policy before successfully sending anything to us.) In your message, please propose a (tentative) public disclosure date/time for the issue. 4) If you do not hear back within 48 hours, please send another message to inquire whether your initial message has in fact been received.

Speaking of encryption, the supported message formats are: plain unencrypted messages, PGP/MIME (including with attachments), or inline PGP. (In all of these cases, messages are distributed to list members (re-)encrypted to their own keys - except that headers, including From and Subject, are not encrypted, so you may want to avoid including security sensitive information in the Subject.) However, manual PGP-encrypted attachments are not supported (so if you want to attach file(s) to your encrypted message, use PGP/MIME).

Please note that the maximum acceptable embargo period for issues disclosed to these lists is 14 days. Please do not ask for a longer embargo. In fact, embargo periods shorter than 7 days are preferable. Please notify upstream projects/developers of the affected software, other affected distro vendors, and/or affected Open Source projects before notifying one of these mailing lists in order to ensure that these other parties are OK with the maximum embargo period that would apply (and if not, then you may have to delay your notification to the mailing list), unless you're confident you'd choose to ignore their preference anyway and disclose the issue publicly soon as per the policy stated here.

When the security issue is finally to be made public, it is your (the original reporter's) responsibility to post about it to oss-security (indeed, you and others may also post to any other mailing lists, etc.) In your mandatory oss-security posting, you must include sufficient detail for non-members of these private lists to also fix the issue.

If you shared exploit(s) that are not an essential part of the issue description, then at your option you may slightly delay posting them to oss-security but you must post the exploits to oss-security within at most 7 days of making the mandatory posting above. If you exercise this option, you have two mandatory postings to make: first with a sufficiently detailed issue description (as requested above) and with an announcement of your intent to post the exploits separately (please mention exactly when), and second with the exploits - or indeed you could have included the exploits right away, in your first and only mandatory posting.

Please note that any/all list postings may be made public once the corresponding security issue is publicly disclosed, so please do not post information that you want to stay private forever. For now, we've manually setup public headers-only archives of the lists for period until June 19, 2017. 5)

Version: GnuPG v1.4.10 (GNU/Linux)


List policy and instructions for members

In this section, “you” and “your” refer to you as the individual (linux-)distros list subscriber and/or member organization.

Handling of embargoed information

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.

Before you share the information with others within your distro's team based on their need-to-know, you need to get these people to agree to these same terms, optionally (and preferably) with the additional limitation that they may not share the information further (not even with others on the team, not even based on need-to-know) without explicit approval by you or another individual directly subscribed to the (linux-)distros list for your distro. (Example: Gentoo's internal policy.)

In the unfortunate event that you happen to share or/and use the information beyond what's allowed by this policy (thus, creating a leak), you must urgently (right after you became aware of the leak) inform the reporter and the (linux-)distros (sub-)list you had received the information from of the leak and of its extent (if readily known). You must also conduct an internal investigation of the leak, and inform the reporter and the list of the exact extent of the leak (to the best of your knowledge) and of measures (intended to be) taken to prevent such leaks going forward.

In case you prefer the Traffic Light Protocol (also explained by FIRST and US-CERT), in its terms this is TLP:AMBER with the need-to-know condition as specified above and with the following additional limitation on sharing: you must not share the information with anyone outside of your distro's team, including not within the rest of your organization nor with your clients or customers, including not in any derived form (not even through delivering or deploying undocumented fixes). Once the embargo is over, this is TLP:WHITE. 6)

Contributing back

Running these lists is a team effort. As a member, you're expected to contribute back, such as with some of the following:

  • Technical (in arbitrary order)
    1. Propose (other) ways to fix, work around, or mitigate the reported issues - primary: Red Hat, backup: vacant
    2. Develop and share fixes, workarounds, or mitigations - primary: Red Hat, backup: vacant
    3. Review and/or test the proposed patches and point out potential issues with them (such as incomplete fixes for the originally reported issues, additional issues you might notice, and newly introduced bugs), and inform the list of the work done even if no issues were encountered - primary: Amazon, backup: vacant
    4. Check if related issues exist in the same piece of software (e.g., same bug class common across the software, or other kinds of bugs exist in its problematic component), and inform the list either way
    5. Check if related issues exist in implementations of similar functionality in other software (e.g., forked code including the same bug, or the same error made independently), and inform the list either way
    6. Produce and share well-reasoned estimates for the time required to handle the issues under embargo (such as to (re)negotiate the public disclosure date and/or to choose between the different ways to handle an issue)
  • Administrative (roughly in chronological order, although many of these activities overlap)
    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
    3. Evaluate if the issue (or one of the issues) is effectively already public (e.g., a fix is committed upstream with a descriptive message) or/and is low severity and thus the report (or its portion pertaining to the issue) should be made public right away for one or both of these reasons, get a few other list members to confirm this understanding, and if there are no objections then communicate this strong preference to the reporter
    4. Evaluate relevance to other parties such as the upstream, other affected distros (not present on the (sub-)list), and other Open Source projects, see if the report mentions notifying any of these, communicate your findings and possible concerns to the reporter and the list, and stay on top of the resulting discussion until a decision is made on who else to possibly notify (or not) and any such notifications are in fact made (with the reporter's approval)
    5. Determine if the reported issues are Linux-specific, and if so help ensure that (further) private discussion goes on the linux-distros sub-list only (thus, not spamming and unnecessary disclosing to the non-Linux distros)
    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
    7. If CVE IDs are requested, the report is valid, and you're a CNA, assign those (requesting any required information from the reporter first) - primary: Red Hat, backup: Debian
    8. If the report does not mention CVE IDs (neither requests nor provides them, and doesn't mention the reporter having requested them elsewhere), yet the report is valid and it looks like distros will need CVE IDs, and you're a CNA, ask the reporter whether they have already requested CVE IDs elsewhere, then assign those if they haven't been requested elsewhere - primary: Red Hat, backup: Debian
    9. Stay on top of issues to ensure progress is being made, remind others when there's no apparent progress, as well as when the public disclosure date for an issue is approaching and when it's finally reached (unless the reporter beats you to it by making their mandatory posting to oss-security first) - primary: Gentoo, backup: Amazon
    10. Monitor relevant public channels (mailing lists, code repositories, etc.) and inform the reporter and the list in case an issue is made public prematurely (that is, leaks or is independently rediscovered) - primary: Amazon, backup: vacant
    11. Make sure the mandatory oss-security posting is made promptly and is sufficiently detailed, and remind the reporter if not - primary: Gentoo, backup: Amazon
    12. If exploit(s) were shared on the list, make sure that either they're included in the oss-security posting along with the issue detail or the posting includes an announcement of planned later posting of the exploits (with the delay being within list policy), and in the latter case also make sure that the later posting is in fact made as planned, and remind the reporter if not - primary: Gentoo, backup: Amazon
    13. Keep track of per-report and per-issue handling and disclosure timelines (at least times of notification of the private list and of actual public disclosure), at regular intervals produce and share statistics (most notably, the average embargo duration) as well as the raw data (except on issues that are still under embargo) by posting to oss-security - primary: Gentoo, backup: Amazon
  • Administrative tasks not strictly requiring (linux-)distros list membership (thus, open for contributions by the wider community)
    1. Help evaluate new (linux-)distros list membership requests per the criteria given below (participating in the corresponding oss-security threads)
    2. Vouch for people wanting to join in on behalf of a new distro member as long as you are confident of their trustworthiness, expected proper use of the list, and contributions
  • Administrative tasks mostly unrelated to (linux-)distros lists (but relevant to the wider community)
    1. 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

Most of your communication on (linux-)distros should be to the reporter and the list at once, usually keeping the original CC list that might have been set previously in the discussion.

Ideally, encrypt all of your messages to their (possibly multiple) recipients. This means that you need not only the list's public key, but also keys for the reporter and for anyone else CC'ed. You may exercise your best effort to obtain such keys (from keyservers, by asking in the thread in plaintext without quoting any sensitive content, etc.), or failing that you may fallback to plaintext, in which case you should refrain from quoting (and adding) non-essential sensitive content. For example, if you merely want the reporter to agree to or specify a public disclosure date, then you may send a plaintext message back to them with this request and nothing else (most importantly, do not quote their original report).

Membership criteria

To be eligible for (linux-)distros list membership, your distro should:

  1. Be an actively maintained Unix-like operating system distro with substantial use of Open Source components
  2. Have a userbase not limited to your own organization
  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)
  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?)
  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)
  6. Accept the list policy (see above)
  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
  8. Be able and willing to handle PGP-encrypted e-mail
  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)

New membership requests are discussed in public on oss-security. (Example: CloudLinux's request and the resulting thread.) Although membership is for distros rather than individuals, for each distro we're only subscribing individuals with their PGP keys (messages are re-encrypted to individual recipients), not exploders.

1) In those “CVE only” cases, please start by posting about the (to be made) public issue to oss-security (without a CVE ID), request a CVE ID from MITRE directly, and finally “reply” to your own posting when you also have the CVE ID to add. With the described approach you would only approach MITRE after the issue is already public, but if you choose to do things differently and contact MITRE about an issue that is not yet public, then please do not disclose to them more than the absolute minimum needed for them to assign a CVE ID.
2) Overall severity as estimated by risk probability and risk impact product. We require that low severity security issues be reported to the public oss-security list right away.
3) We're using a whitelist approach.
4) And if it is “right now” or “already public”, then don't post to these lists, but post to oss-security only instead.
5) There was/is intent to be making all list postings public with a delay, which is currently not yet implemented for technical reasons, but it may be implemented and applied retroactively - that is, including to past postings.
6) The definitions by FIRST and US-CERT mention “risks to privacy, reputation, or operations”. This wording does not reflect our concerns and priorities here (our priority should be security of the users' systems), but since this wording exists in the definitions anyway, in our context it is to be construed as referring to risks to users of the member distros (yours and others), not to risks to your own organization.
mailing-lists/distros.txt · Last modified: 2017/07/14 13:47 by solar
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate to DokuWiki Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki Powered by OpenVZ Powered by Openwall GNU/*/Linux Bookmark and Share