Back in september 2023, during the Coredev in the Azores, we (the group of Bitcoin Core contributors present) discussed we (as a project) should do a better job of tracking and disclosing security-critical bugs. A bunch of us volunteered to dig up old reports (disclosed or not), set up some private infra to track vulnerabilities and come up with a disclosure policy. The group is comprised of Ava Chow, Michael Ford (fanquake), Niklas Gögge, Antoine Poinsot, Anthony Towns and Pieter Wuille.
In march 2024, during the Coredev in Berlin, this group had another discussion regarding the disclosure policy involving other long-time contributors. It was decided to go through all the past reports which were dug up to inform our disclosure policy. "If bug X was reported today, how should we treat it?". Following this the group had a couple of calls to decide on a disclosure policy.
When reported, a vulnerability would be assigned a severity category. We differentiate 4 classes of vulnerabilities:
- Low: bugs which are hard to exploit or have a low impact. For instance a wallet bug which requires access to the victim's machine.
- Medium: bugs with limited impact. For instance a local network remote crash.
- High: bugs with significant impact. For instance a remote crash, or a local network RCE.
- Critical: bugs which threaten the whole network's integrity. For instance an inflation or coin theft bug.
Critial bugs would most likely require an ad-hoc procedure. As they are very rare and it's hard to come up with a standard policy for those in advance, we do not consider them here. Instead we focus on a standard policy for the large majority of the reports, which range from low to high severity.
A bug may also not get into any category at all. A reported issue may be considered seriously yet not be classified as a vulnerability because it does not require secrecy.
Low severity bugs will be disclosed 2 weeks after a fix is released. A pre-announcement would be made at the same time as the release.
Medium and high severity bugs will be disclosed 2 weeks after the last affected release goes EOL. This is approximately a year and a half after it was first released. A per-announcement would be made 2 weeks earlier.
- Share with the wider groupe of Bitcoin Core contributors.
- Announce the policy to the wider Bitcoin developer community through the
bitcoin-dev
mailing list. Request feedback. We are not asking people to tell us how they think we should handle this, we are asking if this would be harmful to anybody for objective reasons we may have overlooked.
- Example of valid feedback: "I'm in charge of mining infrastructure. We are occasionally running a couple versions of Bitcoin Core behind for reason X. Given our past experience i believe it's possible for a business like ours to not be capable of upgrading within 2 weeks of the version we are running going EOL for reasons Y and Z. This is unlikely, still i think a pre-announcement period of 1 month instead would make sure to err on the safe side."
- Example of invalid feedback: "I just Google'd 'CVE best practices' and here is how you should do things instead or else it's an attack on Bitcoin" (except passed through ChatGPT to get to 10k words).
- Try to communicate it to a wider audience. Ping the Optech guys, etc..
We want to publish historical reports. We also want to gradually start enforcing the policy, to let the chance to everyone who didn't to upgrade. To this effect we are going to incrementally disclose security bugs which were fixed in past releases, up to the point where the bugs for all EOL releases will have been disclosed.
We'll start this month (june) with historical bugs: all which were fixed in 0.21.x and below (we have undisclosed bugs for as old as 0.11). Barring any good reason to change course (through the feedback received from users) we would continue in July for bugs fixed in 22.x. In August for bugs fixed in 23.x. Etc..
Any vulnerability which requires a consensus rule change to fix should receive the critical handling described here, due to the coordination difficulties of deploying 'fixes', which will almost certainly be highly issue specific, and also more vulnerable to impact misestimation. Alternatively, "a fix is released" might be changed to "fix is activated on the network" for issues fixed via consensus changes.
The specific concern I had there is that there can be (and have been) consensus issues that by impact might be low or medium, consider for example "I can create a tree fragment that allows a false SPV proof with 2^96 work due to a lack of interior node vs leaf", perhaps the difficult of exploiting means its low... but after a month of analysis it turns out that its actually possible to do it in 2^48 work, which would be immediately exploitable, and any consensus change will take much longer to activate than weeks from release.
Relatedly, resource wasting attacks in consensus rules might be low/medium from impact (just making slow to process blocks) but the long term impact of the fix is greatly reduced if the blockchain contains no examples of triggers ... as the codebase won't need to contain a conditional "this rules before this point, those rules after". So, again, it's extremely valuable to not have disclosed them until after they won't get mined.
I see I'm mentioned above. I think it's important to also recognize that policy itself is potentially a source of vulnerability, because it's an invitation to bad actors to demand the project behave against its best judgement in order to act predictably in the attackers interest. This realization favors a conservative approach which provides ample opportunity to do the right thing and to ignore outside actors which are potentially acting maliciously. It's always fine to have norms and traditions that go above and beyond the rules set by a policy but aren't precluded from it, the policy is essentially the minimum which you can expect that malicious actors are permitted to demand from your process. In other words "the project will do at least this, but may also do other things". Because of this the policy doesn't need to and shouldn't encompass every consideration.
When it comes to alternatives, the comment of "laying out strong ethical rules" made me laugh out loud. In some cases we're just talking about outright criminal fraudsters who have no issue with threatening to murder bitcoin developers and the families or whom will drag bitcoin developers through court for years and cause millions of dollars in costs because they hope to harass them and gum up bitcoin. No amount of "strong ethical rules" is going to help in those cases.
Historically, the position of the project has been that the the project and the effort of its contributors exist for the benefit of the bitcoin system. If someone wants to go create a competing system using the code the licensing permits that, but the good of bitcoin ought not be meaningfully compromised for their benefit. Because of this they're generally not informed of issues before fixes are deployed in Bitcoin except to the extent that the general public is informed. That said, it's kind and professional to not gratuitously screw them over (even when they wouldn't act the same). Unfortunately third parties can't all be trusted to not attack each other too, so it's difficult to have a formalized practice of disclosing to them prior to making issues public. Many also just don't apply fixes even if informed (as its not on the critical path of separating fools and their money or just because they're inactive or under-resourced). In the past this conflict was often addressed by just not disclosing things (or by waiting until other things had managed to pick up fixes accidentally) but this also has resulted in former issues just being forgotten and is clearly also not in the best interest of Bitcoin.
In light of that, I think the best you could say is that sometimes notice will be provided to other projects if its reasonable to do so... but that's always going to be a judgement call specific to the nature of the issue and the other projects.