From e5600ab9c62f2cdc86bcdc6a5be68f36f73a6d87 Mon Sep 17 00:00:00 2001 From: Robin Schneider Date: Sun, 10 Jul 2016 14:22:43 +0200 Subject: [PATCH] Wrote initial security policy. Related to: https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/doc/criteria.md#vulnerability_report_process Related to: https://github.com/debops/debops/issues/154 When this repo is included in the docs build, a redirect from `debops.org/security` should point to the security policy. Additionally I propose to create "DebOps security mailing list " or "" --- CHANGES.rst | 2 + docs/index.rst | 1 + docs/security-policy.rst | 91 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 94 insertions(+) create mode 100644 docs/security-policy.rst diff --git a/CHANGES.rst b/CHANGES.rst index 1566efb..4224542 100644 --- a/CHANGES.rst +++ b/CHANGES.rst @@ -26,3 +26,5 @@ Added - Added a draft of the organizational structure and explanation of distributed development model, as well a draft of the code signing policy used by the project. [drybjed, ypid] + +- Wrote initial security policy. [ypid] diff --git a/docs/index.rst b/docs/index.rst index c1bb6dc..fdb39b4 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -10,6 +10,7 @@ DebOps Policy and Guidelines organizational-structure distributed-development code-signing + security-policy references copyright changelog diff --git a/docs/security-policy.rst b/docs/security-policy.rst new file mode 100644 index 0000000..87287ac --- /dev/null +++ b/docs/security-policy.rst @@ -0,0 +1,91 @@ +Security policy +=============== + +.. Based on: https://www.openssl.org/docs/faq.html#BUILD19 + Based on: http://rubyonrails.org/security/ + A: Only legacy HTTP? + See also: https://security.stackexchange.com/q/34871 + + Big parts of the policy have been copied from http://rubyonrails.org/security/. + Thus, this file is licensed under MIT. + + Copyright (c) 2016 http://rubyonrails.org + Copyright (C) 2016 Robin Schneider + Copyright (C) 2016 DebOps Project http://debops.org/ + + Permission is hereby granted, free of charge, to any person obtaining a copy + of this software and associated documentation files (the "Software"), to + deal in the Software without restriction, including without limitation the + rights to use, copy, modify, merge, publish, distribute, sublicense, and/or + sell copies of the Software, and to permit persons to whom the Software is + furnished to do so, subject to the following conditions: + + The above copyright notice and this permission notice shall be included in + all copies or substantial portions of the Software. + + THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + IN THE SOFTWARE. + +Reporting a vulnerability +------------------------- + +If you think your bug has security implications then please send it to the +Project Leader (Maciej Delmanowski ) and additionally to +the maintainers of the affected part of the project. +If you can fix the vulnerability (or have already done so) please consider +attaching a patch. +If you wish to use PGP to send +in a report please use one or more of the keys of the team members listed at +`debops-keyring `_. + +Disclosure process +------------------ + +#. Security report received and is assigned a primary handler. This person will + coordinate the fix and release process. Problem is confirmed and a list of + all affected versions is determined. Code is audited to find any potential + similar problems. + +#. Fixes are prepared for all releases which are still supported. These fixes + are not committed to the public repository but rather held locally pending + the announcement. +#. A suggested embargo date for this vulnerability is chosen and potential + downstream projects of DebOps are notified. This notification will include + patches for all versions still under support and a contact address for + packagers who need advice backporting patches to older versions. +#. On the embargo date, the debops-security list is sent a copy of the + announcement. The changes are pushed to the public repository and affected + parts of the project are released. Additionally, an GitHub issue is opened + against the affected repository on GitHub with the intend to inform people + watching the repository. + +This process can take some time, especially when coordination is required with +maintainers of other projects. Every effort will be made to handle the bug in +as timely a manner as possible, however it’s important that we follow the +release process above to ensure that the disclosure is handled in a consistent +manner. + +Receiving disclosures +--------------------- + +The best way to receive all the security announcements is to subscribe to the +`DebOps security mailing list +`_. The mailing list +is very low traffic, and it receives the public notifications the moment the +embargo is lifted. If you produce packages of DebOps and require prior +notification of vulnerabilities, you should get in touch with the DebOps Project. + +No one outside the core team, the initial reporter or downstream projects will be +notified prior to the lifting of the embargo. We regret that we cannot make +exceptions to this policy for high traffic or important sites, as any +disclosure beyond the minimum required to coordinate a fix could cause an early +leak of the vulnerability. + +If you have any suggestions to improve this policy, please get in touch for +example via +the `debops-policy repository on GitHub `_.