Differences

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

Link to this comparison view

mailing-lists:distros [2020/07/25 13:48]
solar [Contributing back] added Flatcar Container Linux as backup for "Check if related issues exist in implementations of similar functionality in other software" per https://www.openwall.com/lists/oss-security/2020/07/23/5
mailing-lists:distros [2024/02/24 15:54] (current)
solar [List policy and instructions for reporters] note that CVEs may not always be assigned
Line 1: Line 1:
 ====== Operating system distribution security contact lists ====== ====== Operating system distribution security contact lists ======
  
-Two mailing lists were setup with operating system distribution security contacts.+Two mailing lists were set up with operating system distribution security contacts.
  
 ===== Operating system distribution security contacts list ===== ===== Operating system distribution security contacts list =====
Line 10: Line 10:
   * FreeBSD   * FreeBSD
   * NetBSD/​pkgsrc   * NetBSD/​pkgsrc
 +  * OmniOS 
 +  * Oracle Solaris
 ===== Linux distribution security contacts list ===== ===== Linux distribution security contacts list =====
  
 Currently on the ''​linux-distros''​ list are representatives from: Currently on the ''​linux-distros''​ list are representatives from:
  
 +  * AlmaLinux OS Foundation
   * ALT Linux   * ALT Linux
   * Amazon Linux AMI   * Amazon Linux AMI
   * Arch Linux   * Arch Linux
   * Chrome OS   * Chrome OS
 +  * CIQ Rocky Linux Security Team
   * CloudLinux   * CloudLinux
 +  * Container-Optimized OS (COS)
   * Debian   * Debian
   * Flatcar Container Linux   * Flatcar Container Linux
Line 25: Line 29:
   * Microsoft Linux Systems Group   * Microsoft Linux Systems Group
   * Openwall   * Openwall
-  * Oracle+  * Oracle ​Linux
   * Red Hat   * Red Hat
   * Slackware   * Slackware
Line 35: Line 39:
 ===== List usage statistics ===== ===== List usage statistics =====
  
-  * [[./​distros/​stats|Per-report statistics]] kindly maintained by Gentoo ​since June 2017 +  * [[./​distros/​stats|Per-report statistics]] kindly maintained by Gentoo ​in 2017-2019, partially generated by Amazon for 2022, and maintained by Openwall since 2023 
-  * [[http://​www.openwall.com/​lists/​oss-security/​2017/06/24/13|Public headers-only archives of the lists]] until November 192017+  * [[https://​www.openwall.com/​lists/​oss-security/​2023/10/15/3|Public headers-only archives of the lists]] until December 312023
  
 ===== List policy and instructions for reporters ===== ===== 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 **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 **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 [[https://cve.mitre.org/cve/cna.html|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). ​ ((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 [[http://​www.openwall.com/​lists/​oss-security/​2015/​04/​14/​3|the absolute minimum]] needed for them to assign a CVE ID.))+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. 
 + 
 +It is intended that these lists be used primarily to **provide actionable information to multiple distribution vendors at once**. ​ While usually ​you may at the same time request and obtain a CVE ID (with [[https://www.openwall.com/lists/oss-security/​2024/​02/​23/​1|some exceptions]]) 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). ​ ((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.))
  
 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>​ (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 ((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. 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>​ (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 ((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.
Line 50: Line 58:
 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. 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.
  
-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.+When the security issue is finally ​(to be madepublic, **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.+**//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**. 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**.
Line 127: Line 135:
     - 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)     - 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)   * Administrative (roughly in chronological order, although many of these activities overlap)
-    - 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) //- primary: Oracle, backup: Wind River//+    - 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//
     - 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//​     - 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//​
     - 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//     - 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//
Line 138: Line 146:
     - 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//     - 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//
     - Make sure the mandatory oss-security posting is made promptly and is sufficiently detailed, and remind the reporter if not //- primary: Gentoo, backup: Amazon//     - Make sure the mandatory oss-security posting is made promptly and is sufficiently detailed, and remind the reporter if not //- primary: Gentoo, backup: Amazon//
-    - 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// +    - 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// 
-    - 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//+    - 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)   * Administrative tasks not strictly requiring (linux-)distros list membership (thus, open for contributions by the wider community)
     - Help evaluate new (linux-)distros list membership requests per the criteria given below (participating in the corresponding oss-security threads)     - Help evaluate new (linux-)distros list membership requests per the criteria given below (participating in the corresponding oss-security threads)
     - 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     - 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)   * Administrative tasks mostly unrelated to (linux-)distros lists (but relevant to the wider community)
-    - 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+    - 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// 
 +    - Develop tools to help with the above (crawl URLs in messages and produce draft follow-ups for manual editing+posting) 
 +    - 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// 
 +    - 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) 
 +    - Directly encourage upstreams, researchers,​ umbrella organizations,​ packagers, distros, etc. to report to the lists 
 +    - Suggest and provide examples of quality improvements for such reports (beyond them containing the most essential information) 
 +    - Set up and maintain automated or manual oss-security digest Twitter/​Mastodon feed(s) ((We had an automated Twitter feed, but it failed and per poll results was replaced with manual tweets in November 2023)) //- 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. 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.
Line 164: Line 178:
   - 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)   - 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: [[http://​www.openwall.com/​lists/​oss-security/​2017/​07/​02/​2|CloudLinux'​s]] and [[http://​www.openwall.com/​lists/​oss-security/​2017/​07/​18/​5|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.+New membership requests are discussed in public on [[oss-security]]. ​ (Examples: [[https://​www.openwall.com/​lists/​oss-security/​2017/​07/​02/​2|CloudLinux'​s]] and [[https://​www.openwall.com/​lists/​oss-security/​2017/​07/​18/​5|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.
mailing-lists/distros.1595677711.txt · Last modified: 2020/07/25 13:48 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