Delivery-date: Mon, 08 Jul 2024 18:16:22 -0700
Sender: bitcoindev@googlegroups.com
Date: Wed, 3 Jul 2024 10:20:06 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <2414b7a9-3f38-4641-a2c5-58aa37691fe5n@googlegroups.com>
In-Reply-To: <rALfxJ5b5hyubGwdVW3F4jtugxnXRvc-tjD_qwW7z73rd5j7lXGNdEHWikmSdmNG3vkSOIwEryZzOZr_DgmVDDmt9qsX0gpRAcpY9CfwSk4=@protonmail.com>
References: <rALfxJ5b5hyubGwdVW3F4jtugxnXRvc-tjD_qwW7z73rd5j7lXGNdEHWikmSdmNG3vkSOIwEryZzOZr_DgmVDDmt9qsX0gpRAcpY9CfwSk4=@protonmail.com>
Subject: [bitcoindev] Re: Bitcoin Core Security Disclosure Policy
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_198517_162868746.1720027206566"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_198517_162868746.1720027206566
Content-Type: multipart/alternative; 
	boundary="----=_Part_198518_521066554.1720027206566"

------=_Part_198518_521066554.1720027206566
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Antoine,

For information the lifecycle of each bitcoin core release has been updated=
=20
with EOL dates for each version:
https://bitcoincore.org/en/lifecycle/

That way it's great if you plan to throw bitcoin core or some of its=20
components on secure hardware env, where lifecycles can be harder to manage=
.

True thanks the six of you for all the work done on putting in place a=20
better disclosure policy.

Best,
Antoine (the other one)
Le mercredi 3 juillet 2024 =C3=A0 14:10:10 UTC+1, Antoine Poinsot a =C3=A9c=
rit :

> Hi everyone,
>
> We are writing to announce the policy Bitcoin Core will be using for=20
> disclosing security vulnerabilities.
>
> The project has historically done a poor job at publicly disclosing=20
> security-critical bugs, whether externally reported or found by=20
> contributors. This has led to a situation where a lot of users perceive=
=20
> Bitcoin Core as never having bugs. This perception is dangerous and,=20
> unfortunately, not accurate.
>
> Besides a better communication of the risk of running outdated versions, =
a=20
> consistent tracking and standardized disclosure process would set clear=
=20
> expectations for security researchers, providing them with an incentive t=
o=20
> try finding vulnerabilities *and* to responsibly disclose them. Making th=
e=20
> security bugs available to the wider group of contributors can help preve=
nt=20
> future ones.
>
> Over the past months, we've worked on setting this up. Here is the=20
> disclosure policy we came up with.
>
> When reported, a vulnerability will be assigned a severity category. We=
=20
> differentiate between 4 classes of vulnerabilities:
> - **Low**: bugs which are hard to exploit or have a low impact. For=20
> instance a wallet bug which requires access to the victim's machine.
> - **Medium**: bugs with limited impact. For instance a local network=20
> remote crash.
> - **High**: bugs with significant impact. For instance a remote crash, or=
=20
> a local network RCE.=20
> - **Critical**: bugs which threaten the whole network's integrity. For=20
> instance an inflation or coin theft bug.
>
> **Low** severity bugs will be disclosed 2 weeks after a fixed version is=
=20
> released. A pre-announcement will be made at the same time as the release=
.
>
> **Medium** and **high** severity bugs will be disclosed 2 weeks after the=
=20
> last affected release goes EOL. This is a year after a fixed version was=
=20
> first released. A pre-announcement will be made 2 weeks prior to disclosu=
re.
>
> **Critical** bugs are not considered in the standard policy, as they woul=
d=20
> most likely require an ad-hoc procedure.
>
> Also, a bug may not be considered a vulnerability at all. A reported issu=
e=20
> may be considered serious yet not require an embargo.
>
> This policy will be gradually adopted in the coming months. Today we will=
=20
> disclose all vulnerabilities fixed in Bitcoin Core versions 0.21.0 and=20
> earlier. Later in july we will disclose all vulnerabilities fixed in=20
> Bitcoin Core version 22.0. In august, all vulnerabilities fixed in Bitcoi=
n=20
> Core version 23.0. And so on until we run out of EOL versions to disclose=
=20
> vulnerabilities for.
>
> Please let us know if this policy may have a significant negative impact=
=20
> for you.
>
> Anthony, Antoine, Ava, Michael, Niklas and Pieter.
>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/2414b7a9-3f38-4641-a2c5-58aa37691fe5n%40googlegroups.com.

------=_Part_198518_521066554.1720027206566
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Antoine,<div><br /></div><div>For information the lifecycle of each b=
itcoin core release has been updated with EOL dates for each version:</div>=
<div>https://bitcoincore.org/en/lifecycle/<br /></div><div><br /></div><div=
>That way it's great if you plan to throw bitcoin core or some of its compo=
nents on secure hardware env, where lifecycles can be harder to manage.</di=
v><div><br /></div><div>True thanks the six of you for all the work done on=
 putting in place a better disclosure policy.</div><div><br /></div><div>Be=
st,</div><div>Antoine (the other one)</div><div class=3D"gmail_quote"><div =
dir=3D"auto" class=3D"gmail_attr">Le mercredi 3 juillet 2024 =C3=A0 14:10:1=
0 UTC+1, Antoine Poinsot a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204,=
 204, 204); padding-left: 1ex;">Hi everyone,
<br>
<br>We are writing to announce the policy Bitcoin Core will be using for  d=
isclosing security vulnerabilities.
<br>
<br>The project has historically done a poor job at publicly disclosing sec=
urity-critical bugs, whether externally reported or found by contributors. =
This has led to a situation where a lot of users perceive Bitcoin Core as n=
ever having bugs. This perception is dangerous and, unfortunately, not accu=
rate.
<br>
<br>Besides a better communication of the risk of running outdated versions=
, a consistent tracking and standardized disclosure process would set clear=
 expectations for security researchers, providing them with an incentive to=
 try finding vulnerabilities *and* to responsibly disclose them. Making the=
 security bugs available to the wider group of contributors can help preven=
t future ones.
<br>
<br>Over the past months, we&#39;ve worked on setting this up. Here is the =
disclosure policy we came up with.
<br>
<br>When reported, a vulnerability will be assigned a severity category. We=
 differentiate between 4 classes of vulnerabilities:
<br>- **Low**: bugs which are hard to exploit or have a low impact. For ins=
tance a wallet bug which requires access to the victim&#39;s machine.
<br>- **Medium**: bugs with limited impact. For instance a local network re=
mote crash.
<br>- **High**: bugs with significant impact. For instance a remote crash, =
or a local network RCE.=20
<br>- **Critical**: bugs which threaten the whole network&#39;s integrity. =
For instance an inflation or coin theft bug.
<br>
<br>**Low** severity bugs will be disclosed 2 weeks after a fixed version i=
s released. A pre-announcement will be made at the same time as the release=
.
<br>
<br>**Medium** and **high** severity bugs will be disclosed 2 weeks after t=
he last affected release goes EOL. This is a year after a fixed version was=
 first released. A pre-announcement will be made 2 weeks prior to disclosur=
e.
<br>
<br>**Critical** bugs are not considered in the standard policy, as they wo=
uld most likely require an ad-hoc procedure.
<br>
<br>Also, a bug may not be considered a vulnerability at all. A reported is=
sue may be considered serious yet not require an embargo.
<br>
<br>This policy will be gradually adopted in the coming months. Today we wi=
ll disclose all vulnerabilities fixed in Bitcoin Core versions 0.21.0 and e=
arlier. Later in july we will disclose all vulnerabilities fixed in Bitcoin=
 Core version 22.0. In august, all vulnerabilities fixed in Bitcoin Core ve=
rsion 23.0. And so on until we run out of EOL versions to disclose vulnerab=
ilities for.
<br>
<br>Please let us know if this policy may have a significant negative impac=
t for you.
<br>
<br>Anthony, Antoine, Ava, Michael, Niklas and Pieter.
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/2414b7a9-3f38-4641-a2c5-58aa37691fe5n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/2414b7a9-3f38-4641-a2c5-58aa37691fe5n%40googlegroups.com</a>.=
<br />

------=_Part_198518_521066554.1720027206566--

------=_Part_198517_162868746.1720027206566--