Operating system distribution security contact lists

Two mailing lists were set up 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
  • OmniOS
  • Oracle Solaris

Linux distribution security contacts list

Currently on the linux-distros list are representatives from:

  • AlmaLinux OS Foundation
  • ALT Linux
  • Amazon Linux AMI
  • Arch Linux
  • Chrome OS
  • CIQ Rocky Linux Security Team
  • CloudLinux
  • Container-Optimized OS (COS)
  • Debian
  • Flatcar Container Linux
  • Gentoo
  • Microsoft Linux Systems Group
  • Openwall
  • Oracle Linux
  • Red Hat
  • Slackware
  • SUSE
  • Ubuntu
  • VMware Photon OS
  • Wind River

List usage statistics

List policy and instructions for reporters


Please consider notifying 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 readily have fixes for the distributions to apply and to ensure that these other parties are OK with the maximum embargo period that would apply (if not, you may delay your notification to the mailing list). For Linux kernel issues, you must notify the kernel security team first, wait for the fix, and only then notify linux-distros or oss-security (depending on whether the information is still private or already public, as well as on issue severity).

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. Reasonable minimum is 1 day, but in extreme special cases even a few hours of advance notice may help.

Only use these lists to report security issues that are not yet public (but that are to be made public very soon). 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.

In case the fix is already in a publicly accessible repository, we generally consider the issue public (and thus you should post to oss-security right away, not report the issue to (linux-)distros). There are occasional exceptions to this, such as if the publicly accessible fix doesn't look like it's for a security issue and not revealing this publicly right away is deemed desirable. We've granted such exceptions for (1) Linux kernel issues concurrently or very recently handled by the Linux kernel security team and (2) curl issues ranked as low or medium severity by the curl project. In all other cases, you'd have to have very sound reasoning to claim an exception like this and be prepared to lose your argument and if so to post to oss-security ASAP anyway.

Only use these lists to provide actionable information to multiple distribution vendors at once (before posting, ask yourself what reasonable action they may take within the embargo period). Usually you may at the same time request and obtain a CVE ID for the issue you report (except for most Linux kernel issues), but please don't abuse these lists solely for getting a CVE ID. 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 (choose one of these lists depending on who you want to inform), preferably PGP-encrypted to the key below. Be sure to include [vs] (four characters) in the Subject line, or your message will most likely be rejected by the mail server. 3) In your message, please propose a (tentative) public disclosure date/time for the issue. If you do not hear back within 48 hours, please send another message to inquire whether your initial message has in fact been received.

The supported message formats are: plain unencrypted messages (including with attachments), 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). The attachment filenames should be alphanumeric, except that dot, minus sign, and underscore characters are allowed within the filenames (not as the first character of a filename).

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 delay or withhold posting them to oss-security, and you're encouraged to post the exploits to oss-security in 1 to 30 days of making the mandatory posting above. The delay may reasonably match your estimate for independent development of such exploits. If you exercise this option, you have two 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.

If you'd like to post a follow-up to or otherwise continue discussing an issue that has already been made public, please post those messages only to oss-security instead. The (linux-)distros lists are for embargoed discussions only, and we mean it. If you do have a good reason to keep your follow-up(s) under a new embargo, it's OK to send them to (linux-)distros, but please be aware that this starts the whole process all over again - you need to propose a public disclosure date right away, etc., and then bring those follow-up(s) to oss-security once the new embargo is over.

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. 4)

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. 5)

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: Ubuntu, backup: Amazon
    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 - primary: Ubuntu, backup: VMware Photon OS
    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 - primary: Ubuntu, backup: Flatcar Container Linux
    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/time), then ensure the requested information is actually provided and send timely reminders if not - primary: Oracle, backup: Wind River
    2. If the proposed public disclosure date is not within list policy, insist on getting this corrected and propose a suitable earlier date - primary: Oracle, backup: CloudLinux
    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 - primary: CloudLinux, backup: Microsoft Linux Systems Group
    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) - primary: Microsoft Linux Systems Group, backup: vacant
    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 unnecessarily disclosing to the non-Linux distros) - primary: VMware Photon OS, backup: SUSE
    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 - primary: CloudLinux, backup: vacant
    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: SUSE
    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 the oss-security posting includes an announcement of planned later posting of the exploits, make sure that such 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 (linux-)distros and of public disclosure on oss-security), at regular intervals produce and share statistics (most notably, the average embargo duration) as well as the input data (except on issues that are still under embargo) by posting to oss-security - primary: Openwall, backup: vacant
  • 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 - primary: Container-Optimized OS, backup: vacant
    2. Develop tools to help with the above (crawl URLs in messages and produce draft follow-ups for manual editing+posting)
    3. Monitor for Open Source security issues/topics published elsewhere, identify which of these would fit, and bring them to oss-security - primary: Oracle Solaris, backup: vacant
    4. Develop tools to help with the above (automatically monitor Open Source projects' and other relevant third-party mailing lists, websites, social media, source code repositories, releases for likely Open Source security issues/topics)
    5. Directly encourage upstreams, researchers, umbrella organizations, packagers, distros, etc. to report to the lists
    6. Suggest and provide examples of quality improvements for such reports (beyond them containing the most essential information)
    7. Set up and maintain automated or manual oss-security digest Twitter/Mastodon feed(s) 6) - primary: Openwall, backup: vacant

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. (Examples: CloudLinux's and CoreOS' requests and the resulting threads.) 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 prefer that low severity security issues be reported to the public oss-security list right away.
3) This helps us filter out spam, and confirm that you indeed read this policy before successfully sending anything to us.
4) 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.
5) 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.
6) We had an automated Twitter feed, but it failed and per poll results was replaced with manual tweets in November 2023
mailing-lists/distros.txt · Last modified: 2024/03/31 20:33 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