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..
This seems a bit aggressive. Obviously, for the majority of users this likely will not be a problem. However, a small tail of users may sometimes need more time to upgrade, for a variety of reasons. Giving more time after the pre-announcement before disclosure (and after the last affected release is EOL) seems like a good way to reduce the risk for a small tail of users with no major downside? I know that "high" bugs are only announced after EOL, but a honest mistake by someone to forget to do an upgrade shouldn't put them in a sudden rush to complete it in two week, or be exposed to malicious actors or "lulz" actors.
A two week pre-announcement could easily not make it to the responsible person in time. For example, the person could be on holiday, work travel, or otherwise be temporarily occupied with work or non-work tasks.
Moreover, an upgrade process may be more involved occasionally and could very well take more than two weeks to complete. For example, one could set
-rpcdeprecated
in a release to avoid a breaking change an then forget about fixing their code before the release goes EOL in a honest mistake. They receive the pre-announcement, but they realize it is infeasible to fix their code (or external dependency) in two weeks, review it, and upgrade to it. Another reason could be that they are compiling from source on an old Linux distro, but a suitable compiler is lacking to compile the new release. So they may have to similarly upgrade their dependency tree within two weeks, which may or may not be a problem for them.I am not saying that such complications are common, but they seem plausible and the additional cost of waiting a bit longer should be minimal? That is, a policy of [medium bug -> pre-announcement + 1 month, and high bug -> pre-announcement + 6 months] or similar shouldn't cause any issues? I presume the announcement will be written at the same time as the fix is written (or latest when the pre-announcement is written), so the only difference for the disclosure people would be to set a different timer, which should not be an issue?