summaryrefslogtreecommitdiff
path: root/02/0ab4ead0d4c7a7dca1995dc24e013f5e73e3d6
blob: a57d91eeaae65baef8c4c5e43c20ce7572e7829d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id AA7EC9C0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 11 Sep 2017 02:15:17 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CB01DE5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 11 Sep 2017 02:15:16 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
	by azure.erisian.com.au with esmtpsa (Exim 4.84_2 #1 (Debian))
	id 1drEFk-0006iW-UD for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 11 Sep 2017 12:15:14 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
	Mon, 11 Sep 2017 12:15:07 +1000
Date: Mon, 11 Sep 2017 12:15:07 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20170911021506.GA19080@erisian.com.au>
References: <3e4541f3-f65c-5199-5e85-9a65ea5142e7@bitcartel.com>
	<cb968a34-f8d2-ab61-dd15-9bd282afd18c@mattcorallo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cb968a34-f8d2-ab61-dd15-9bd282afd18c@mattcorallo.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Spam-Score: -1.9
X-Spam-Score-int: -18
X-Spam-Bar: -
X-Spam-Status: No, score=0.0 required=5.0 tests=RP_MATCHES_RCVD,
	UNPARSEABLE_RELAY 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 02:15:17 -0000

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