[BlueZ, v2 2/2] doc: Remove obsolete security-bugs.rst

[Bastien Nocera <hadess@hadess.net>]

---
 doc/security-bugs.rst | 89 -------------------------------------------
 1 file changed, 89 deletions(-)
 delete mode 100644 doc/security-bugs.rst

diff --git a/doc/security-bugs.rst b/doc/security-bugs.rst
deleted file mode 100644
index 0dcacfbd9eac..000000000000
--- a/doc/security-bugs.rst
+++ /dev/null
@@ -1,89 +0,0 @@
-=============
-Security bugs
-=============
-
-BlueZ developers take security very seriously.  As such, we'd like to know
-when a security bug is found so that it can be fixed and disclosed as quickly
-as possible.  Please report security bugs to the BlueZ security team.
-
-
-Contact
--------
-
-The BlueZ security team can be contacted by email at <security@bluez.org>.
-This is a private list of security officers who will help verify the bug
-report and develop and release a fix.  If you already have a fix, please
-include it with your report, as that can speed up the process considerably.
-
-As it is with any bug, the more information provided the easier it will
-be to diagnose and fix.  Any exploit code is very helpful and will not
-be released without consent from the reporter unless it has already been
-made public.
-
-Please send plain text emails without attachments where possible.
-
-
-Disclosure and embargoed information
-------------------------------------
-
-The security list is not a disclosure channel.  For that, see Coordination
-below.
-
-Once a robust fix has been developed, the release process starts.  Fixes
-for publicly known bugs are released immediately.
-
-Although our preference is to release fixes for publicly undisclosed bugs
-as soon as they become available, this may be postponed at the request of
-the reporter or an affected party for up to 7 calendar days from the start
-of the release process, with an exceptional extension to 14 calendar days
-if it is agreed that the criticality of the bug requires more time.  The
-only valid reason for deferring the publication of a fix is to accommodate
-the logistics of QA and large scale rollouts which require release
-coordination.
-
-While embargoed information may be shared with trusted individuals in
-order to develop a fix, such information will not be published alongside
-the fix or on any other disclosure channel without the permission of the
-reporter.  This includes but is not limited to the original bug report
-and followup discussions (if any), exploits, CVE information or the
-identity of the reporter.
-
-In other words our only interest is in getting bugs fixed.  All other
-information submitted to the security list and any followup discussions
-of the report are treated confidentially even after the embargo has been
-lifted, in perpetuity.
-
-
-Coordination
-------------
-
-Fixes for sensitive bugs, such as those that might lead to privilege
-escalations, may need to be coordinated with the private
-<linux-distros@vs.openwall.org> mailing list so that distribution vendors
-are well prepared to issue a fixed package upon public disclosure of the
-upstream fix.  Distros will need some time to test the proposed patch and
-will generally request at least a few days of embargo, and vendor update
-publication prefers to happen Tuesday through Thursday. When appropriate,
-the security team can assist with this coordination, or the reporter can
-include linux-distros from the start.  In this case, remember to prefix
-the email Subject line with "[vs]" as described in the linux-distros wiki:
-<http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>
-
-
-CVE assignment
---------------
-
-The security team does not normally assign CVEs, nor do we require them
-for reports or fixes, as this can needlessly complicate the process and
-may delay the bug handling. If a reporter wishes to have a CVE identifier
-assigned ahead of public disclosure, they will need to contact the private
-linux-distros list, described above. When such a CVE identifier is known
-before a patch is provided, it is desirable to mention it in the commit
-message if the reporter agrees.
-
-
-Non-disclosure agreements
--------------------------
-
-The BlueZ security team is not a formal body and therefore unable to enter
-any non-disclosure agreements.
-- 
2.55.0