Add SECURITY.md #2243

pull jonatack wants to merge 1 commits into bitcoin:master from jonatack:2026-08-add-security_md-document changing 1 files +15 −0
  1. 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.

  2. Add SECURITY.md 2247cece98
  3. 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?

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

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

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

  7. jonatack added the label Process on Aug 9, 2026
  8. 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?


github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-08-11 12:10 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me