From 2c405706e1f188752c2eff9eab278581d4b51406 Mon Sep 17 00:00:00 2001 From: Marcel Holtmann Date: Tue, 15 Jun 2021 22:12:16 +0200 Subject: doc: Add initial draft of security bugs handling document --- doc/security-bugs.txt | 88 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+) create mode 100644 doc/security-bugs.txt (limited to 'doc') diff --git a/doc/security-bugs.txt b/doc/security-bugs.txt new file mode 100644 index 000000000..bd4b0d68f --- /dev/null +++ b/doc/security-bugs.txt @@ -0,0 +1,88 @@ +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 . +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 + 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: + + + +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. -- cgit v1.2.1