Table of Contents

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:

Linux distribution security contacts list

Currently on the linux-distros list are representatives from:

List usage statistics

List policy and instructions for reporters

PLEASE NOTE THAT BY POSTING TO THESE LISTS YOU ACCEPT CERTAIN RESPONSIBILITIES. PLEASE READ THIS SECTION CAREFULLY BEFORE YOU POST.

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)

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.10 (GNU/Linux)

mQENBE2YijgBCADJ7gsXv583bcxm7D4gGCjqUuNv+qLj6fgB+/QNFOM0z3OB2YNj
3oaBRSR5DKhDRvHmNRbXTvNO7OjzPojMmkDlq2UgcmGHIrYraw9q/e1Hpom4dF+O
1dIMwyOZ1WARtlR5znd3hwkGrGiFnkLqDJDLKXUn/rSbRTFhay1zv1dAknR4/+zJ
74YBhZo95zVYA7piF0VmDvXDK+9R3bQM0SgoThyfdiQQMpoFd48y0jFtcbrQlVgU
7M5l/6JKTqANqxG3Qeilavqg9jG1AQyrGJCoCI6ItgDk1AyHB8hLHN6QVQl9XPpC
Uo5oXYpzPcMpdKzhnMD6/AzF+z6UEHmcmArtABEBAAG0PkxpbnV4IGRpc3RybyBz
ZWN1cml0eSBjb250YWN0cyA8bGludXgtZGlzdHJvc0B2cy5vcGVud2FsbC5vcmc+
iQE4BBMBAgAiBQJNmIo4AhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDW
zkyuR+r385KNB/0RyvjAjy6Zz2+UDq4JzR8aAt0DAScycD/1jWMBzwncBrkoXG0v
yJ+m5AFtXcHRKGYgfZ8Aothpe5vi/fnQnuAzz2RyGDw15/7wyXWsA3rbWELCxx13
iLfFrFAXboM7FlGCCdALosEaJBM2gAuCNouxraFWXVOKXUPyJ1Kpry9AIffQJWD3
2Zzn2xsPbd02Fa6nLUWf+g3608RzqUv0TZmaFu4cFjGZkrx+RejUaSchPaf9Mqal
PlIQSMBsYgZlKYVcIXGXlSA3iXhFzcLgzlwcL6MMtK+iK7UJBXMCmw1GjrTsUcY0
qeJFZzJ43wf/AoamAHKmOQIqxxIfebJX/98riEYEEBECAAYFAk2YuO4ACgkQovwC
fFs0HxW8yQCfTFiGhEsDJyPRAXmBXMWEDxYq4gwAoICEzh0+CHUWazrIcHh4D7wl
zYwltENPcGVyYXRpbmcgc3lzdGVtIGRpc3RybyBzZWN1cml0eSBjb250YWN0cyA8
ZGlzdHJvc0B2cy5vcGVud2FsbC5vcmc+iQE4BBMBAgAiBQJO4YbYAhsDBgsJCAcD
AgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDWzkyuR+r38xHJB/9paDZv6RWnGFcCv7bO
dvvBborWfyEjDW0kHHnevN1BLNaVq9RPRhSIbvVd3JGEkYi+C0HIUZAK0NNs8Yjh
CPQKKE2FIVLsO7wTt+FWOpKvQZWuNbPW3vvJ8x82NkmUGjMPP0JDRV+N/SB37JDc
ndjz+19SI228lxqlazS8OqbrZOeSeawKafcGVFv3CTbR2lj+1mHo6DyUbZeXf7Cq
K5wfZYhxlNtrh8gAS3vCizoIhuRzxdCF6nxobcjCYoXbtJpx30J7bUHAp6Rc5vr1
hdZDS+LxJ704x9cmEof9DgWQ4QbVb54R8xAbRpU3RFZ0veZcPu4P6mpI2ba6bP9f
6mSsuQENBE2YijgBCACkA8GQr4IYbrPU5qDsTLvlL3YU8Bekg1HlhKOC+gr8/PqI
09fQMaWBM9n79/ss4ZaS3IAX/S0HZtfpmfNc36FMTlpJRnbY1tF3NqjeIHJUGaf+
0jXTInRdOxq0U0jHqW/GLr6rNjxLFhhtFI7Y622vPf03cvZYd/pBjyYlZCHAxeRC
0OqfXLUiNLr2L0LptUO8RsWUhZJtEW65fjn0heka/eh/P+IINQrA5ranVohv6tST
ucL8blHr91AfiNw9oI0VYI8jvkVQx+cjgJeTYlOegqzZ3Vq+une21nkLd9nbuauJ
Q7lodfhzH6yUrTQjwUpxi/udXNFFIJFuM6IAAGkfABEBAAGJAR8EGAECAAkFAk2Y
ijgCGwwACgkQ1s5Mrkfq9/O7fgf/WYnIqcEQivO9SB90O1jplJP55HZoIUwf4Rrp
Y9Nbz3nG2qXo1b68kw/O/zggU90K3oJ+yzsyETLAOH5+nrOPBxjrGIYbVsEMt+Vf
W+7WahYvh30IJWLMy3Xv3v7uzHzP5T81FnwJyja85Y56rLyaYhk9E3KYcJ1phaYW
oFDQuioFUFDi6TV5WK13B5d/InTy/4uQDzOWPE0Ev8RTZex7hDx+SxwASszQnghn
ovWWEa96Gh5fpdoyWpBE9Na/9Hz2y8RO+Okctct4xdZZFYcEg4wpnFigCBFIq+jx
K4LI8Y1o8SiVLMztF+knDaZxohs+7BWYGzsWvsYOGqTMkBM5IQ==
=E3Xb
-----END PGP PUBLIC KEY BLOCK-----

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:

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