docs: provide more details about security bug reporting

Hi Linus,

please consider applying the attached patch to improve the doc on the security reporting process.

Thanks,
Willy

From a587418b587915bcaa5657909f52dc3995f29dcd Mon Sep 17 00:00:00 2001
From: Willy Tarreau <[email protected]>
Date: Fri, 10 Aug 2018 16:36:04 +0200
Subject: [PATCH] docs: provide more details about security bug reporting

The analysis, disclosure and crediting parts were completed a bit to add clarification about what types of reports are expected, what the reporter may expect in terms of disclosure, and how reporters are credited for their discovery.

---
 Documentation/admin-guide/security-bugs.rst | 81 +++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

index 30491d9..91ecd48 100644
@@ -26,6 +26,51 @@ information is helpful.  Any exploit code is very helpful and will not
 be released without consent from the reporter unless it has already been
 made public.
 
+Analysis
+--------
+
+Sometimes a bug will be very well understood by some of the security
+officers who will propose you a patch to test.  Please get prepared to
+receiving extra questions and to provide answers on a timely basis.
+There is little chance a bug will get fixed if you send an incomplete
+report and disappear for two weeks.  It is also possible that some of
+the officers will conclude that the behaviour you observed is normal
+and expected, that it is bogus but doesn't present an imminent
+security risk and should rather be discussed on public lists, or that
+it does indeed represent a risk, but that the risk of breakage induced
+by fixing it outweights the risks of the bug being exploited.  In such
+situations, it is possible that you will be requested to post your
+report to another more suitable place.
+
+Analysing a report takes a lot of time, and while sometimes it's
+better to conclude to a wrong alert because there is nothing to fix,
+it also is annoying if it is discovered that the reporter should have
+found it by himself, because the time lost on this analysis was not
+spent on another one.  This can happen all the time to be wrong about
+a report, but please be careful not to do this too often or your
+reports may not be taken seriously in the end.
+
+As a rule of thumb, it is recommended not to post messages suggesting
+that a bug may exist somewhere.  Since the security team manages
+imminent and important risks, bugs reported there must be based on
+facts and not on beliefs.  It is fine to report a panic message saying
+"I just got this, I don't know how it happened but it scares me", it is
+not fine to say "I ran my new automated analysis tool which thinks a
+check is missing here, could someone knowledgeable in this area please
+double-check".  The security team's role is not to have opinions on
+your beliefs but to spot the right people to help fix a real problem.
+
+Very often, some maintainers will be brought to the discussion as the
+analysis progresses. Most of the time these people will not have received
+the initial e-mail, and they're discovering the issue late.  So please do
+not get upset if they ask questions that were already addressed or which
+were present in the initial report.
+
+Also, don't consider the bug fixed until the fix is merged.  It can
+happen that a fix proposed by one of the security officers doesn't suit
+a subsystem maintainer and that it has to be reworked differently,
+possibly after a public discussion.
+
 Disclosure
 ----------
 

@@ -44,6 +89,25 @@ timeframe varies from immediate (esp. if it's already publicly known bug)
 to a few weeks.  As a basic default policy, we expect report date to
 release date to be on the order of 7 days.
 
+There is no point threatening to make a report public after XX days
+without a response because usually what you will end up with is a fix
+that is merged much earlier than what you possibly expected, for example
+if you promised to someone not to publish it before a certain date.
+Please just understand that the security team's goal is for your bug to
+be fixed as fast as possible and not to sleep on it.
+
+If you report a particularly complex issue that you intend to discuss
+at a conference a few weeks or months later, you cannot really expect
+from the security team to find a solution in time and at the same time
+to refrain from disclosing the issue to a broader audience or
+releasing the fix.  So at the very least you will have to take your
+dispositions to deal with a disclosure which happens much earlier than
+your public talk about the issue.  Also if you only sent an early
+notification about a forthcoming problem that is not yet fully
+disclosed, you must not expect the security officers to ping you again
+later about the issue; you are responsible for reloading the
+discussion at the right moment once all elements are gathered.
+
 Coordination
 ------------
 

@@ -59,6 +123,23 @@ 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>
 
+Crediting the reporter
+----------------------
+
+The security team has a great respect for reporters' work and wants to
+encourage high-quality reports that help fix real issues.  As such, the
+reporter will usually be asked who must be credited for reporting the
+bug before writing the final patch.  It is often not well perceived to
+send a report and start by explaining whom to credit for the report, as
+experience shows that people who focus a bit too much on being properly
+credited when they don't know yet if what they found is a valid bug tend
+not to provide the highest quality reports nor to interact the best with
+the team.  So the best way to be properly credited is to provide a patch
+with an appropriate commit message along with the analysis.  The second
+best way is to stay humble and participate with the rest of the team to
+the bug fixing session.  It will bring you a lot of respect and will help
+your future reports get more attention.
+
 CVE assignment
 --------------
 

1.7.12.1

Hi,

I have a few corrections/comments below.
They can be addressed later if the patch is being merged immediately.

~~~

 Documentation/admin-guide/security-bugs.rst | 81 +++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

index 30491d9..91ecd48 100644
@@ -26,6 +26,51 @@ information is helpful.  Any exploit code is very helpful and will not
 be released without consent from the reporter unless it has already been
 made public.
 
+Analysis
+--------
+
+Sometimes a bug will be very well understood by some of the security
+officers who will propose you a patch to test.  Please get prepared to
 
              will propose to you a patch to test.  Please be prepared to
 
+receiving extra questions and to provide answers on a timely basis.

receive more questions and

+There is little chance a bug will get fixed if you send an incomplete +report and disappear for two weeks. It is also possible that some of +the officers will conclude that the behaviour you observed is normal +and expected, that it is bogus but doesn't present an imminent +security risk and should rather be discussed on public lists, or that +it does indeed represent a risk, but that the risk of breakage induced +by fixing it outweights the risks of the bug being exploited. In such

outweighs

+situations, it is possible that you will be requested to post your +report to another more suitable place.
+
+Analysing a report takes a lot of time, and while sometimes it's +better to conclude to a wrong alert because there is nothing to fix,

"to conclude to a wrong alert" needs some fixing, but I don't know what...

+it also is annoying if it is discovered that the reporter should have +found it by himself, because the time lost on this analysis was not +spent on another one. This can happen all the time to be wrong about +a report, but please be careful not to do this too often or your +reports may not be taken seriously in the end.
+
+As a rule of thumb, it is recommended not to post messages suggesting +that a bug may exist somewhere. Since the security team manages +imminent and important risks, bugs reported there must be based on +facts and not on beliefs. It is fine to report a panic message saying +"I just got this, I don't know how it happened but it scares me", it is +not fine to say "I ran my new automated analysis tool which thinks a +check is missing here, could someone knowledgeable in this area please +double-check". The security team's role is not to have opinions on +your beliefs but to spot the right people to help fix a real problem. +
+Very often, some maintainers will be brought to the discussion as the +analysis progresses. Most of the time these people will not have received +the initial e-mail, and they're discovering the issue late. So please do +not get upset if they ask questions that were already addressed or which +were present in the initial report.
+
+Also, don't consider the bug fixed until the fix is merged. It can +happen that a fix proposed by one of the security officers doesn't suit +a subsystem maintainer and that it has to be reworked differently, +possibly after a public discussion.
+
Disclosure
----------

@@ -44,6 +89,25 @@ timeframe varies from immediate (esp. if it's already publicly known bug)
to a few weeks. As a basic default policy, we expect report date to
release date to be on the order of 7 days.

+There is no point threatening to make a report public after XX days +without a response because usually what you will end up with is a fix +that is merged much earlier than what you possibly expected, for example +if you promised to someone not to publish it before a certain date. +Please just understand that the security team's goal is for your bug to +be fixed as fast as possible and not to sleep on it.
+
+If you report a particularly complex issue that you intend to discuss +at a conference a few weeks or months later, you cannot really expect +from the security team to find a solution in time and at the same time +to refrain from disclosing the issue to a broader audience or +releasing the fix. So at the very least you will have to take your +dispositions to deal with a disclosure which happens much earlier than +your public talk about the issue. Also if you only sent an early +notification about a forthcoming problem that is not yet fully +disclosed, you must not expect the security officers to ping you again +later about the issue; you are responsible for reloading the +discussion at the right moment once all elements are gathered. +
Coordination
------------

@@ -59,6 +123,23 @@ 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>

+Crediting the reporter
+----------------------
+
+The security team has a great respect for reporters' work and wants to +encourage high-quality reports that help fix real issues. As such, the +reporter will usually be asked who must be credited for reporting the +bug before writing the final patch. It is often not well perceived to +send a report and start by explaining whom to credit for the report, as +experience shows that people who focus a bit too much on being properly +credited when they don't know yet if what they found is a valid bug tend +not to provide the highest quality reports nor to interact the best with +the team. So the best way to be properly credited is to provide a patch +with an appropriate commit message along with the analysis. The second +best way is to stay humble and participate with the rest of the team to +the bug fixing session. It will bring you a lot of respect and will help +your future reports get more attention.
+
CVE assignment
--------------

-- 
~Randy

Hi Randy,

Thanks a lot, I've addressed them in the attached version. Linus, please take this one instead.

(...)

---
 Documentation/admin-guide/security-bugs.rst | 81 +++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

index 30491d9..98c4d0e 100644
@@ -26,6 +26,51 @@ information is helpful.  Any exploit code is very helpful and will not
 be released without consent from the reporter unless it has already been
 made public.
 
+Analysis
+--------
+
+Sometimes a bug will be very well understood by some of the security
+officers who will propose to you a patch to test.  Please be prepared
+to receive more questions and to provide answers on a timely basis.
+There is little chance a bug will get fixed if you send an incomplete
+report and disappear for two weeks.  It is also possible that some of
+the officers will conclude that the behaviour you observed is normal
+and expected, that it is bogus but doesn't present an imminent
+security risk and should rather be discussed on public lists, or that
+it does indeed represent a risk, but that the risk of breakage induced
+by fixing it outweighs the risks of the bug being exploited.  In such
+situations, it is possible that you will be requested to post your
+report to another more suitable place.
+
+Analysing a report takes a lot of time, and while sometimes it's better
+to conclude that a report was a false alarm because there is nothing to
+fix, it also is annoying if it is discovered that the reporter should
+have found it by himself, because the time lost on this analysis was not
+spent on another one.  This can happen all the time to be wrong about
+a report, but please be careful not to do this too often or your
+reports may not be taken seriously in the end.
+
+As a rule of thumb, it is recommended not to post messages suggesting
+that a bug may exist somewhere.  Since the security team manages
+imminent and important risks, bugs reported there must be based on
+facts and not on beliefs.  It is fine to report a panic message saying
+"I just got this, I don't know how it happened but it scares me", it is
+not fine to say "I ran my new automated analysis tool which thinks a
+check is missing here, could someone knowledgeable in this area please
+double-check".  The security team's role is not to have opinions on
+your beliefs but to spot the right people to help fix a real problem.
+
+Very often, some maintainers will be brought to the discussion as the
+analysis progresses. Most of the time these people will not have received
+the initial e-mail, and they're discovering the issue late.  So please do
+not get upset if they ask questions that were already addressed or which
+were present in the initial report.
+
+Also, don't consider the bug fixed until the fix is merged.  It can
+happen that a fix proposed by one of the security officers doesn't suit
+a subsystem maintainer and that it has to be reworked differently,
+possibly after a public discussion.
+
 Disclosure
 ----------
 

@@ -44,6 +89,25 @@ timeframe varies from immediate (esp. if it's already publicly known bug)
 to a few weeks.  As a basic default policy, we expect report date to
 release date to be on the order of 7 days.
 
+There is no point threatening to make a report public after XX days
+without a response because usually what you will end up with is a fix
+that is merged much earlier than what you possibly expected, for example
+if you promised to someone not to publish it before a certain date.
+Please just understand that the security team's goal is for your bug to
+be fixed as fast as possible and not to sleep on it.
+
+If you report a particularly complex issue that you intend to discuss
+at a conference a few weeks or months later, you cannot really expect
+from the security team to find a solution in time and at the same time
+to refrain from disclosing the issue to a broader audience or
+releasing the fix.  So at the very least you will have to take your
+dispositions to deal with a disclosure which happens much earlier than
+your public talk about the issue.  Also if you only sent an early
+notification about a forthcoming problem that is not yet fully
+disclosed, you must not expect the security officers to ping you again
+later about the issue; you are responsible for reloading the
+discussion at the right moment once all elements are gathered.
+
 Coordination
 ------------
 

@@ -59,6 +123,23 @@ 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>
 
+Crediting the reporter
+----------------------
+
+The security team has a great respect for reporters' work and wants to
+encourage high-quality reports that help fix real issues.  As such, the
+reporter will usually be asked who must be credited for reporting the
+bug before writing the final patch.  It is often not well perceived to
+send a report and start by explaining whom to credit for the report, as
+experience shows that people who focus a bit too much on being properly
+credited when they don't know yet if what they found is a valid bug tend
+not to provide the highest quality reports nor to interact the best with
+the team.  So the best way to be properly credited is to provide a patch
+with an appropriate commit message along with the analysis.  The second
+best way is to stay humble and participate with the rest of the team to
+the bug fixing session.  It will bring you a lot of respect and will help
+your future reports get more attention.
+
 CVE assignment
 --------------
 

1.7.12.1

LGTM. Thanks.

~Randy