mirror of
https://github.com/haproxy/haproxy.git
synced 2026-06-09 00:32:33 -04:00
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:
parent
8badf5d2fa
commit
03b828b648
2 changed files with 43 additions and 12 deletions
|
|
@ -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
36
doc/security.txt
Normal 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
|
||||
Loading…
Reference in a new issue