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.
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.
I’m not sure I understand the motivation here. Since we don’t ship a software project, what responsible disclosures could we possibly get?
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.
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...
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.
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?