From: Willy Tarreau Date: Sun, 31 May 2026 20:42:53 +0000 (+0200) Subject: DOC: add security.txt describing how to report security issues X-Git-Tag: v3.4.0~40 X-Git-Url: http://git.ipfire.org/gitweb/index.cgi?a=commitdiff_plain;h=03b828b6488fb88b9734d0ab8df2ebabec83f01a;p=thirdparty%2Fhaproxy.git 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 ccf0c06d7..504e714f5 100644 --- 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 index 000000000..64be7499f --- /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