Published on: 2017-09-22T19:53:46+00:00
The bitcoin-dev mailing list has been discussing the current policy for disclosing vulnerabilities in Bitcoin. The policy involves reporting vulnerabilities to security at bitcoincore.org, patching critical issues immediately, and releasing minimal details about the vulnerability to delay attacks. Non-critical vulnerabilities are dealt with through patching and reviewing in the ordinary flow of development.Some modifications to the policy have been suggested during the discussion. One suggestion is to disclose vulnerability details after 95% of nodes have upgraded and fixes have been released for at least 6 months, instead of the current threshold of >80% node deployment. It is also proposed that vulnerabilities should be tracked using standard CVE codes. Another proposed modification is early disclosure to zero or more altcoin developers, allowing for closer coordination to minimize economic damage. There is also discussion about using a global timeout for vulnerability disclosure.Concerns have been raised about documenting the security policy, as it may give attackers an advantage in finding weak points. However, many participants believe that the benefits of disclosing vulnerabilities outweigh the risks. In addition to the discussion on vulnerability disclosure, there are other related topics being discussed, including concerns about researchers' inability to report vulnerabilities in altcoins, the responsibility to defend all types of users and software from threats, and the need for a clarification of the current policy regarding publication of vulnerabilities in Bitcoin.The discussion highlights the importance of having a clear and well-defined policy for disclosing vulnerabilities in Bitcoin, while also considering the potential risks and benefits of such disclosures.Another topic of discussion on the mailing list is the challenges of disclosing vulnerabilities in altcoins that are running old, unpatched forks of Bitcoin Core. Concerns have been expressed about the difficulty of disclosing issues without putting people at risk. Suggestions have been made for reasonable approaches to address this issue, such as patching clients and altcoins derived from Bitcoin Core for known vulnerabilities. The decentralized nature of the network poses a challenge in ensuring everyone updates, and ideas like a timeout period for vulnerabilities have been proposed.A responsible disclosure timeline has also been suggested, where vulnerabilities are reported privately and details are shared with a small group of trusted users before releasing official fixes. This proposal takes into consideration the potential risks of sharing vulnerability information with altcoin developers who may not behave responsibly. It is emphasized that good security for Bitcoin is not defined by constant upgrading but by knowing that the definition of money has not changed. Not disclosing vulnerability information can create a false sense of security and discourage good security practices.The discussion also highlights the outdated list of Bitcoin Common Vulnerabilities and Exposures (CVEs), with no new CVEs posted for almost three years except for one without publicly available information. The mailing list encourages further discussion on the topic of Bitcoin and CVEs to find reasonable approaches to address the issue of altcoins running old, unpatched forks of Bitcoin Core and ensure responsible disclosure and patching for the benefit of end-users.
Updated on: 2023-08-01T21:51:45.406790+00:00