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.
This commit is contained in:
Willy Tarreau 2026-05-31 22:42:53 +02:00
parent 8badf5d2fa
commit 03b828b648
2 changed files with 43 additions and 12 deletions

View file

@ -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.

36
doc/security.txt Normal file
View file

@ -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