path: root/bd/644d1b21b5867c76467b2230a1832ba9d6311f

Return-Path: <morcos@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6BA0BBD6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 11 Sep 2017 11:34:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f176.google.com (mail-io0-f176.google.com
	[209.85.223.176])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6E5E03F5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 11 Sep 2017 11:34:35 +0000 (UTC)
Received: by mail-io0-f176.google.com with SMTP id g32so6463593ioj.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 11 Sep 2017 04:34:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=2hDcABF2gxI5aYtoNkpcZelndbmVcJJwwDCirdCM3/w=;
	b=AQZmo46PgkXg9oUjAWuWXkV0h0j/GYR7/982ZUOlO1lv95JuAW0mxoonGIlqHtTmdF
	MjqviCTiQCKxEp40CEkHxL3zQ3JUfuaHMzMGv2u3ROhdmqPLMSYHum4zp8GNC7wMrQ0O
	QyKB0DhHa6rlIpMf/i9kTqUVBjjne3OHqrn1Wevsmn+pqamhkVC3KLbVD7E7wd5Yp9hh
	qPo6xgIkGs5XE+edU77X0e2azEsefCeKQILs6kOSHMIFXtmhvoazOMHhAkhkNemix82k
	fyX6gNAvmXP46sP6isiFSmc4zhlADly5NBgLwPgFVynl0voh0hUvJynsB4UIoeAI5wai
	MXeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=2hDcABF2gxI5aYtoNkpcZelndbmVcJJwwDCirdCM3/w=;
	b=oHKVuxY2dLo95TrHgc31CCRb/kHkJ9heV5z1cWaUPSB6wVE5WuweGgCs5OAj1YYSuW
	Cs/B4atUSV5kAphTWUXM8xrHg5PNKuVle5vovV2b4jSGKoZZtqFgGasJ80NDfO24hVdw
	iqR+hZCejKMjo7AtHFiRrCV4RK36eKgiEFilCDbgAMkVk04UMToy28Za39Xnfk+Yoz6P
	SJ/fLEK9DM6kFpG0L85j3m2TZ+uWVnoAYwfiYKDSZ16qC7WImtRR4x3kLn+5wYbmZOn+
	kiFgt4dvRRp+wn0vv48lG4LCXl4XnHWT5e19DbB7Yz6JJLMfSFWQSRXEonc39NJmeLBK
	+bJg==
X-Gm-Message-State: AHPjjUhkLpCW5ZBDvEhWygLdLw2bMrp4Ex4NIUrFf2hIrNx1v0QBaBfi
	sPzsKg0+xN8GH1ubEWkTqEPTyhP30Ats
X-Google-Smtp-Source: AOwi7QCtl/0uMRWsM0eJ2SjK/HuT5NKx5iaPU13vvNKkAiXDumM0cYs4PKpY1rZsVa1Q0vw/w8C5D2lcQlgqCwvRwbU=
X-Received: by 10.107.78.13 with SMTP id c13mr17679206iob.76.1505129674603;
	Mon, 11 Sep 2017 04:34:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.2.69.24 with HTTP; Mon, 11 Sep 2017 04:34:33 -0700 (PDT)
In-Reply-To: <20170911021506.GA19080@erisian.com.au>
References: <3e4541f3-f65c-5199-5e85-9a65ea5142e7@bitcartel.com>
	<cb968a34-f8d2-ab61-dd15-9bd282afd18c@mattcorallo.com>
	<20170911021506.GA19080@erisian.com.au>
From: Alex Morcos <morcos@gmail.com>
Date: Mon, 11 Sep 2017 07:34:33 -0400
Message-ID: <CAPWm=eVCh2FYp=SpOcZFLqz1ZCq3=Z_F9Sj+EAXFvqU-8aMuTg@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="f403043cc3b09882f10558e84fb9"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Responsible disclosure of bugs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Sep 2017 11:34:36 -0000

--f403043cc3b09882f10558e84fb9
Content-Type: text/plain; charset="UTF-8"

I don't think I know the right answer here, but I will point out two things
that make this a little more complicated.

1 - There are lots of altcoin developers and while I'm sure the majority
would greatly appreciate the disclosure and would behave responsibly with
the information, I don't know where you draw the line on who you tell and
who you don't.

2- Unlike other software, I'm not sure good security for bitcoin is defined
by constant upgrading.  Obviously upgrading has an important benefit, but
one of the security considerations for Bitcoin is knowing that your
definition of the money hasn't changed.  Much harder to know that if you
change software.



On Sun, Sep 10, 2017 at 10:15 PM, Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sun, Sep 10, 2017 at 07:02:36PM -0400, Matt Corallo via bitcoin-dev
> wrote:
> > I believe there continues to be concern over a number of altcoins which
> > are running old, unpatched forks of Bitcoin Core, making it rather
> > difficult to disclose issues without putting people at risk (see, eg,
> > some of the dos issues which are preventing release of the alert key).
> > I'd encourage the list to have a discussion about what reasonable
> > approaches could be taken there.
>
> That seems like it just says bitcoin core has two classes of users:
> people who use it directly following mainnet or testnet, and people who
> make derived works based on it to run altcoins.
>
> Having a "responsible disclosure" timeline something like:
>
>  * day -N: vulnerability reported privately
>  * day -N+1: details shared amongst private trusted bitcoin core group
>  * day 0: patch/workaround/mitigation determined, CVE reserved
>  * day 1: basic information shared with small group of trusted users
>       (eg, altcoin maintainers, exchanges, maybe wallet devs)
>  * day ~7: patches can be included in git repo
>       (without references to vulnerability)
>  * day 90: release candidate with fix available
>  * day 120: official release including fix
>  * day 134: CVE published with details and acknowledgements
>
> could make sense. 90 days / 3 months is hopefully a fair strict upper
> bound for how long it should take to get a fix into a rc; but that's still
> a lot longer than many responsible disclosure timeframes, like CERT's at
> 45 days, but also shorter than some bitcoin core minor update cycles...
> Obviously, those timelines could be varied down if something is more
> urgent (or just easy).
>
> As it is, not publishing vulnerability info just seems like it gives
> everyone a false sense of security, and encourages ignoring good security
> practices, either not upgrading bitcoind nodes, or not ensuring altcoin
> implementations keep up to date...
>
> I suppose both "trusted bitcoin core group" and "small group of trusted
> users" isn't 100% cypherpunk, but it sure seems better than not both not
> disclosing vulnerability details, and not disclosing vulnerabilities
> at all... (And maybe it could be made more cypherpunk by, say, having
> the disclosures to trusted groups have the description/patches get
> automatically fuzzed to perhaps allow identification of leakers?)
>
> Cheers,
> aj
>
> > On 09/10/17 18:03, Simon Liu via bitcoin-dev wrote:
> > > Hi,
> > >
> > > Given today's presentation by Chris Jeffrey at the Breaking Bitcoin
> > > conference, and the subsequent discussion around responsible disclosure
> > > and industry practice, perhaps now would be a good time to discuss
> > > "Bitcoin and CVEs" which has gone unanswered for 6 months.
> > >
> > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-March/013751.html
> > >
> > > To quote:
> > >
> > > "Are there are any vulnerabilities in Bitcoin which have been fixed but
> > > not yet publicly disclosed?  Is the following list of Bitcoin CVEs
> > > up-to-date?
> > >
> > > https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
> > >
> > > There have been no new CVEs posted for almost three years, except for
> > > CVE-2015-3641, but there appears to be no information publicly
> available
> > > for that issue:
> > >
> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3641
> > >
> > > It would be of great benefit to end users if the community of clients
> > > and altcoins derived from Bitcoin Core could be patched for any known
> > > vulnerabilities.
> > >
> > > Does anyone keep track of security related bugs and patches, where the
> > > defect severity is similar to those found on the CVE list above?  If
> > > yes, can that list be shared with other developers?"
> > >
> > > Best Regards,
> > > Simon
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">I don&#39;t think I know the right answer here, but I will=
 point out two things that make this a little more complicated.<div><br></d=
iv><div>1 - There are lots of altcoin developers and while I&#39;m sure the=
 majority would greatly appreciate the disclosure and would behave responsi=
bly with the information, I don&#39;t know where you draw the line on who y=
ou tell and who you don&#39;t.</div><div><br></div><div>2- Unlike other sof=
tware, I&#39;m not sure good security for bitcoin is defined by constant up=
grading.=C2=A0 Obviously upgrading has an important benefit, but one of the=
 security considerations for Bitcoin is knowing that your definition of the=
 money hasn&#39;t changed.=C2=A0 Much harder to know that if you change sof=
tware.</div><div><br></div><div><br></div></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Sun, Sep 10, 2017 at 10:15 PM, Anthony To=
wns via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D=
"">On Sun, Sep 10, 2017 at 07:02:36PM -0400, Matt Corallo via bitcoin-dev w=
rote:<br>
&gt; I believe there continues to be concern over a number of altcoins whic=
h<br>
&gt; are running old, unpatched forks of Bitcoin Core, making it rather<br>
&gt; difficult to disclose issues without putting people at risk (see, eg,<=
br>
&gt; some of the dos issues which are preventing release of the alert key).=
<br>
&gt; I&#39;d encourage the list to have a discussion about what reasonable<=
br>
&gt; approaches could be taken there.<br>
<br>
</span>That seems like it just says bitcoin core has two classes of users:<=
br>
people who use it directly following mainnet or testnet, and people who<br>
make derived works based on it to run altcoins.<br>
<br>
Having a &quot;responsible disclosure&quot; timeline something like:<br>
<br>
=C2=A0* day -N: vulnerability reported privately<br>
=C2=A0* day -N+1: details shared amongst private trusted bitcoin core group=
<br>
=C2=A0* day 0: patch/workaround/mitigation determined, CVE reserved<br>
=C2=A0* day 1: basic information shared with small group of trusted users<b=
r>
=C2=A0 =C2=A0 =C2=A0 (eg, altcoin maintainers, exchanges, maybe wallet devs=
)<br>
=C2=A0* day ~7: patches can be included in git repo<br>
=C2=A0 =C2=A0 =C2=A0 (without references to vulnerability)<br>
=C2=A0* day 90: release candidate with fix available<br>
=C2=A0* day 120: official release including fix<br>
=C2=A0* day 134: CVE published with details and acknowledgements<br>
<br>
could make sense. 90 days / 3 months is hopefully a fair strict upper<br>
bound for how long it should take to get a fix into a rc; but that&#39;s st=
ill<br>
a lot longer than many responsible disclosure timeframes, like CERT&#39;s a=
t<br>
45 days, but also shorter than some bitcoin core minor update cycles...<br>
Obviously, those timelines could be varied down if something is more<br>
urgent (or just easy).<br>
<br>
As it is, not publishing vulnerability info just seems like it gives<br>
everyone a false sense of security, and encourages ignoring good security<b=
r>
practices, either not upgrading bitcoind nodes, or not ensuring altcoin<br>
implementations keep up to date...<br>
<br>
I suppose both &quot;trusted bitcoin core group&quot; and &quot;small group=
 of trusted<br>
users&quot; isn&#39;t 100% cypherpunk, but it sure seems better than not bo=
th not<br>
disclosing vulnerability details, and not disclosing vulnerabilities<br>
at all... (And maybe it could be made more cypherpunk by, say, having<br>
the disclosures to trusted groups have the description/patches get<br>
automatically fuzzed to perhaps allow identification of leakers?)<br>
<br>
Cheers,<br>
aj<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; On 09/10/17 18:03, Simon Liu via bitcoin-dev wrote:<br>
&gt; &gt; Hi,<br>
&gt; &gt;<br>
&gt; &gt; Given today&#39;s presentation by Chris Jeffrey at the Breaking B=
itcoin<br>
&gt; &gt; conference, and the subsequent discussion around responsible disc=
losure<br>
&gt; &gt; and industry practice, perhaps now would be a good time to discus=
s<br>
&gt; &gt; &quot;Bitcoin and CVEs&quot; which has gone unanswered for 6 mont=
hs.<br>
&gt; &gt;<br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2017-March/013751.html" rel=3D"noreferrer" target=3D"_blank">https://list=
s.linuxfoundation.<wbr>org/pipermail/bitcoin-dev/<wbr>2017-March/013751.htm=
l</a><br>
&gt; &gt;<br>
&gt; &gt; To quote:<br>
&gt; &gt;<br>
&gt; &gt; &quot;Are there are any vulnerabilities in Bitcoin which have bee=
n fixed but<br>
&gt; &gt; not yet publicly disclosed?=C2=A0 Is the following list of Bitcoi=
n CVEs<br>
&gt; &gt; up-to-date?<br>
&gt; &gt;<br>
&gt; &gt; <a href=3D"https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_=
Exposures" rel=3D"noreferrer" target=3D"_blank">https://en.bitcoin.it/wiki/=
<wbr>Common_Vulnerabilities_and_<wbr>Exposures</a><br>
&gt; &gt;<br>
&gt; &gt; There have been no new CVEs posted for almost three years, except=
 for<br>
&gt; &gt; CVE-2015-3641, but there appears to be no information publicly av=
ailable<br>
&gt; &gt; for that issue:<br>
&gt; &gt;<br>
&gt; &gt; <a href=3D"https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2=
015-3641" rel=3D"noreferrer" target=3D"_blank">https://cve.mitre.org/cgi-bi=
n/<wbr>cvename.cgi?name=3DCVE-2015-3641</a><br>
&gt; &gt;<br>
&gt; &gt; It would be of great benefit to end users if the community of cli=
ents<br>
&gt; &gt; and altcoins derived from Bitcoin Core could be patched for any k=
nown<br>
&gt; &gt; vulnerabilities.<br>
&gt; &gt;<br>
&gt; &gt; Does anyone keep track of security related bugs and patches, wher=
e the<br>
&gt; &gt; defect severity is similar to those found on the CVE list above?=
=C2=A0 If<br>
&gt; &gt; yes, can that list be shared with other developers?&quot;<br>
&gt; &gt;<br>
&gt; &gt; Best Regards,<br>
&gt; &gt; Simon<br>
&gt; &gt; ______________________________<wbr>_________________<br>
&gt; &gt; bitcoin-dev mailing list<br>
&gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-=
dev@lists.<wbr>linuxfoundation.org</a><br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit=
coin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio=
n.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt; &gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>

--f403043cc3b09882f10558e84fb9--