Responsible disclosure of bugs

Summary:

In a recent email thread on the Bitcoin development mailing list, a user asked for clarification on Bitcoin's policy around vulnerability disclosure. The current de facto policy seems to be that vulnerabilities should be reported via security at bitcoincore.org and critical issues will be dealt with by releasing a patch ASAP, notifying users to upgrade or disable affected systems, and disclosing minimal information about the problem to delay attacks. Non-critical vulnerabilities will be addressed through patch and review undertaken in the ordinary flow of development, with backporting a fix or workaround from master to the current released version. Devs will attempt to ensure that publication of the fix does not reveal the nature of the vulnerability by providing the proposed fix to experienced devs who have not been informed of the vulnerability. Prior to a vulnerability becoming public, devs will generally recommend friendly altcoin devs catch up with fixes after they are widely deployed in the Bitcoin network. However, Bitcoin devs won't disclose vulnerability details until >80% of Bitcoin nodes have deployed the fixes. Vulnerability discovers are encouraged and requested to follow the same policy. The policy is documented in various resources including issue templates on Github. The author suggests that documenting the security policy would be good, but argues that doing so may give attackers a better handle on where to find weak points. Additionally, public vulnerability disclosure has benefits such as better working relationships with researchers and understanding of what sort of bugs happen in practice, but if most of your security research is effectively in-house, those benefits aren't as great as the harm done by revealing even old vulnerabilities to attackers. At present, it appears that Bitcoin devs will never encourage public disclosure of vulnerabilities while affected code may still be in use.

Updated on: 2023-05-20T03:47:15.635646+00:00