Differences

This shows you the differences between two versions of the page.

--- mailing-lists:distros [2024/03/29 16:43]
solar [List policy and instructions for reporters] Some wording and emphasis edits, no change in policy
+++ mailing-lists:distros [2025/07/02 23:18] (current)
solar [Linux distribution security contacts list] remove Chrome OS
@@ Line 20: / Line 20: @@
   * Amazon Linux AMI
   * Arch Linux
-  * Chrome OS
+  * CentOS Project's Hyperscale SIG
   * CIQ Rocky Linux Security Team
   * CloudLinux
@@ Line 46: / Line 46: @@
 PLEASE NOTE THAT **BY POSTING TO THESE LISTS YOU ACCEPT CERTAIN RESPONSIBILITIES**.  PLEASE **READ** THIS SECTION CAREFULLY **BEFORE YOU POST**.
-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.
+Please consider **notifying upstream projects/developers of the affected software**, other affected [[:vendors|distro vendors]], and/or affected [[:software|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 [[https://docs.kernel.org/process/security-bugs.html|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).
-Please note that **in case a fix for an issue is already in a publicly accessible source code repository, we generally consider the issue public** (and thus you should post to oss-security right away, not report the issue to (linux-)distros as we'd merely redirect you to oss-security anyway and insist that you make the required posting ASAP).  There can be 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 somehow deemed desirable.  In particular, we grant 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.
+**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.
-Please 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 ([[https://www.openwall.com/lists/oss-security/2024/02/23/1|except for most Linux kernel issues]]), but please **don't abuse these lists solely for getting a CVE ID**.  ((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 [[https://cveform.mitre.org|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 [[https://www.openwall.com/lists/oss-security/2015/04/14/3|the absolute minimum]] needed for them to assign a CVE ID.))
+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.
-To report a non-public medium or high severity ((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.)) security issue to one of these lists, send e-mail to <distros@vs.openwall.org> **or** <linux-distros@vs.openwall.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 ((We're using a whitelist approach.)) 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. ((And if it is "right now" or "already public", then don't post to these lists, but post to oss-security only instead.)) If you do not hear back within 48 hours, please send another message to inquire whether your initial message has in fact been received.
+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.
-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).
+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 ([[https://www.openwall.com/lists/oss-security/2024/02/23/1|except for most Linux kernel issues]]), but please **don't abuse these lists solely for getting a CVE ID**.  ((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 [[https://cveform.mitre.org|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 [[https://www.openwall.com/lists/oss-security/2015/04/14/3|the absolute minimum]] needed for them to assign a CVE ID.))
-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 [[:vendors|distro vendors]], and/or affected [[:software|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.
+To report a non-public medium or high severity ((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.)) security issue to one of these lists, send e-mail to <distros@vs.openwall.org> **or** <linux-distros@vs.openwall.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.  ((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.  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.