DOC: add security.txt describing how to report security issues

Move the security contact out of intro.txt into a dedicated, easily
searchable doc/security.txt that points reporters at the threat model
first, and reference it from intro.txt's contacts section and the
documentation index.

diff --git a/doc/intro.txt b/doc/intro.txt
index ccf0c06d71063315a35df139549a1a6c43ea7e0c..504e714f509bf21faff351fe132b2325f7819cd9 100644 (file)
--- a/doc/intro.txt
+++ b/doc/intro.txt
@@ -97,6 +97,9 @@ to the mailing list whose responses are present in these documents.
     protocol which is implemented by HAProxy and a number of third party
     products.
 
+  - security.txt : how to report a security issue, and what does and does not
+    qualify as a vulnerability.
+
   - README : how to build HAProxy from sources
 
 
@@ -1686,15 +1689,7 @@ information you might later regret. Since the issue tracker presents itself as
 a very long thread, please avoid pasting very long dumps (a few hundreds lines
 or more) and attach them instead.
 
-If you've found what you're absolutely certain can be considered a critical
-security issue that would put many users in serious trouble if discussed in a
-public place, then you can send it with the reproducer to security@haproxy.org.
-A small team of trusted developers will receive it and will be able to propose
-a fix. We usually don't use embargoes and once a fix is available it gets
-merged. In some rare circumstances it can happen that a release is coordinated
-with software vendors. Please note that this process usually messes up with
-everyone's work, and that rushed up releases can sometimes introduce new bugs,
-so it's best avoided unless strictly necessary; as such, there is often little
-consideration for reports that needlessly cause such extra burden, and the best
-way to see your work credited usually is to provide a working fix, which will
-appear in changelogs.
+If you believe you may have found a security issue, please refer to the file
+doc/security.txt. It explains what does and does not qualify as a vulnerability
+in HAProxy, and how to report a genuine one privately. Most suspected issues
+turn out to be ordinary bugs that are better reported as described above.

diff --git a/doc/security.txt b/doc/security.txt
new file mode 100644 (file)
index 0000000..64be749
--- /dev/null
+++ b/doc/security.txt
@@ -0,0 +1,36 @@
+Reporting security issues in HAProxy
+------------------------------------
+
+Before reporting anything, please read doc/internals/threat-model.txt. It
+defines precisely what is and is not considered a security vulnerability in
+HAProxy. A fair number of suspected issues (and most automated or LLM-assisted
+findings) fall outside that boundary: they are ordinary bugs, and are best
+reported and fixed in public through the usual channels described in the
+"Contacts" section of doc/intro.txt.
+
+If, after reading the threat model, you are confident you have found a genuine
+security issue that would put many users at risk if discussed in the open, the
+security team can be reached at security@haproxy.org, a private list read by a
+handful of security officers; anything shared there remains private. Please
+include a reproducer, and ideally a proposed and tested patch, as well as a
+valid name under which the report can be credited.
+
+We usually don't use embargoes: once a fix is available it simply gets merged.
+In rare circumstances a release may be coordinated with software vendors, but
+this disrupts everyone's work and rushed releases can introduce new bugs, so it
+is avoided unless strictly necessary. As a result, reports that needlessly cause
+such extra burden get little consideration, and the most effective and best
+credited way to report an issue is to provide a working fix, which will appear
+in the changelogs.
+
+Findings produced with the help of AI MUST be accompanied by a working, tested
+patch. Such tools routinely report issues that
+are out of scope (see the threat model above) or simply not real, and reviewing
+them by hand wastes the very time and trust this process depends on. A
+model-generated report that arrives without a verified reproducer and a fix will
+generally not be processed.
+
+See also:
+  - doc/internals/threat-model.txt    : what qualifies as a vulnerability
+  - doc/internals/core-principles.txt : the project's design principles
+  - doc/intro.txt                     : general contacts and bug reporting