Add SECURITY.md #2243

jonatack commented at 4:26 PM on August 8, 2026: member

This information is already in BIPs 2 and 3, but ISTM that an explicit SECURITY file would conform to current best practice.

I did not include a section about gpg keys to communicate sensitive information; if wanted, it could be added here or later.

murchandamus commented at 4:48 PM on August 8, 2026: member

I’m not sure I understand the motivation here. Since we don’t ship a software project, what responsible disclosures could we possibly get?

jonatack commented at 4:51 PM on August 8, 2026: member

No strong opinion but idea is, what if an issue is found in a specification (or its example implementation) here that could lead to a potential vulnerability/exploit in an implementation.

ajtowns commented at 12:18 AM on August 9, 2026: contributor

I would think that for a deployed standard, contacting the implementations directly initially would be wise, then adding a "this spec should not be implemented" warning until full disclosure is reasonable. I don't think adding the BIP editors as middlemen for contacting implementations is likely to help anyone out -- half the time it seems like BIP editors have a hard enough job getting into contact with BIP authors as it is even when there's not some looming disaster...

jonatack commented at 1:14 AM on August 9, 2026: member

for a deployed standard, contacting the implementations directly initially would be wise

Yes. It might be worthwhile to state this here.

then adding a "this spec should not be implemented" warning until full disclosure is reasonable

The red team or the implementation would need to contact us privately, so having the contact emails easily findable like here seems useful.

jonatack added the label Process on Aug 9, 2026

ajtowns commented at 5:42 AM on August 9, 2026: contributor

then adding a "this spec should not be implemented" warning until full disclosure is reasonable

The red team or the implementation would need to contact us privately, so having the contact emails easily findable like here seems useful.

If your goal is to publicly update a spec to recommend everyone stop using it, then I don't think there's anything that needs to be done in private. Probably having one of the (co-)authors open a PR with the extra text and merging it as soon as it's verified it's not an impersonator is the ideal outcome. If the authors aren't in the loop, I think marking a BIP as having security issues wouldn't actually comply with BIP 3 processes anyway?

edilmedeiros commented at 1:12 PM on August 11, 2026: contributor

I believe IETF has a reasonable advisor and process.

tldr:

While the preferred approach to reporting IETF protocol vulnerabilities is to contact the person or group responsible for the document, as a last resort, reports can always be sent by email to protocol-vulnerability@ietf.org. The IETF Security Area Directors will make their best effort to triage the report.

I believe having a single email for security reports is considered a best practice instead of many individual emails. Never understood it completely because that single email distributor can be compromised.

in SECURITY.md:10 in 2247cece98 outdated

   5 | +To report a security vulnerability, please send an email to one of the following
   6 | +addresses:
   7 | +
   8 | +* Bryan Bishop ([kanzure@gmail.com](mailto:kanzure@gmail.com))
   9 | +* Jon Atack ([jon@atack.com](mailto:jon@atack.com))
  10 | +* Luke Dashjr ([luke_bipeditor@dashjr.org](mailto:luke_bipeditor@dashjr.org))

murchandamus commented at 10:11 PM on August 11, 2026:

jonatack commented at 4:21 PM on August 13, 2026:

Done

in SECURITY.md:6 in 2247cece98 outdated

   0 | @@ -0,0 +1,15 @@
   1 | +# Security Policy
   2 | +
   3 | +## Reporting a Vulnerability
   4 | +
   5 | +To report a security vulnerability, please send an email to one of the following
   6 | +addresses:

murchandamus commented at 10:17 PM on August 11, 2026:

Inspired by @edilmedeiros’s comment, maybe something along these lines?

The preferred approach to report a security vulnerability is to directly contact the respective BIP owners and affected projects that implement a BIP. Should attempts to contact the affected parties fail, as a last resort, reports can be sent by email to one or more of the BIP Editors listed below. The contacted BIP Editors will then make their best effort to triage the report and get in touch with the respective parties.

jonatack commented at 4:21 PM on August 13, 2026:

Updated with a version of this (thanks!)

jonatack force-pushed on Aug 13, 2026

jonatack commented at 4:33 PM on August 13, 2026: member

Updated with your feedback @ajtowns @edilmedeiros @murchandamus (thanks!) @edilmedeiros I wanted to add you as co-author but I don't have your git-related email yet.

murchandamus commented at 5:13 PM on August 13, 2026: member

I think it’s jose.edil@gmail.com per a recent commit of his. Maybe you can put it in already and @edilmedeiros can confirm.

(Did you know that you can look at a commit directly by adding .patch to the URL of a commit?)

jonatack force-pushed on Aug 13, 2026

Add SECURITY.md

Co-authored-by: Murch <murch@murch.one>
Co-authored-by: Anthony Towns <aj@erisian.com.au>
Co-authored-by: Edil Medeiros <jose.edil@gmail.com>

d8cb214773

jonatack force-pushed on Aug 13, 2026

jonatack commented at 6:05 PM on August 13, 2026: member

Updated, thanks! TIL.

murchandamus commented at 11:19 PM on August 14, 2026: member

Maybe this should include our GPG keys, so emails can be encrypted?

edilmedeiros commented at 11:58 PM on August 14, 2026: contributor

I think it’s jose.edil@gmail.com per a recent commit of his.

Yes, this email. Thanks.

murchandamus approved

murchandamus merged this on Aug 17, 2026

murchandamus closed this on Aug 17, 2026

jonatack deleted the branch on Aug 17, 2026