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
|
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 104EC504
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Sep 2017 04:48:10 +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 6A7B913E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Sep 2017 04:48:09 +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 1drd7F-0000qk-Lx; Tue, 12 Sep 2017 14:48:07 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Tue, 12 Sep 2017 14:47:58 +1000
Date: Tue, 12 Sep 2017 14:47:58 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20170912044758.GE19080@erisian.com.au>
References: <3e4541f3-f65c-5199-5e85-9a65ea5142e7@bitcartel.com>
<cb968a34-f8d2-ab61-dd15-9bd282afd18c@mattcorallo.com>
<20170911021506.GA19080@erisian.com.au>
<CAPWm=eVCh2FYp=SpOcZFLqz1ZCq3=Z_F9Sj+EAXFvqU-8aMuTg@mail.gmail.com>
<CAHpxFbH_5Pb5ZmNCW==fmZWxN3bH7KNjzJsMV5KJ=bjCPWMx6A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAHpxFbH_5Pb5ZmNCW==fmZWxN3bH7KNjzJsMV5KJ=bjCPWMx6A@mail.gmail.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: Tue, 12 Sep 2017 04:48:10 -0000
On Mon, Sep 11, 2017 at 10:43:52AM -0700, Daniel Stadulis wrote:
> I think it's relevant to treat different bug severity levels with different
> response plans.
That makes sense.
For comparison, Monero defines a response process that has three levels
and varies the response for each:
] a. HIGH: impacts network as a whole, has potential to break entire
] network, results in the loss of monero, or is on a scale of great
] catastrophe
] b. MEDIUM: impacts individual nodes, wallets, or must be carefully
] exploited
] c. LOW: is not easily exploitable
-- https://github.com/monero-project/monero/blob/master/VULNERABILITY_RESPONSE_PROCESS.md
Among other things, HIGH gets treated as an emergency, MEDIUM get fixed
in a point release; LOW get deferred to the next regular release eg.
Additionally, independently of the severity, Monero's doc says they'll
either get their act together with a fix and report within 90 days,
or otherwise the researcher that found the vulnerability has the right
to publically disclose the issue themselves...
I wouldn't say that's a perfect fit for bitcoin core (at a minimum, given
the size of the ecosystem and how much care needs to go into releases,
I think 90 days is probably too short), but it seems better than current
practice...
For comparison, if you're an altcoin developer or just bitcoin core user,
and are trying to work out whether the software you're using is secure;
if you do a quick google and end up at:
https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
you might conclude that as long as you're running version 0.11 or later,
you're fine. That doesn't seem like an accurate conclusion for people
to draw; but if you're not tracking every commit/PR, how do you do any
better than that?
Maybe transitioning from keeping things private indefinitely to having
a public disclosure policy is tricky. Maybe it might work to build up to it,
something like:
* We'll start releasing info about security vulnerabilities fixed in
0.12.0 and earlier releases as of 2018-01-01
* Then we'll continue with 0.13.0 and earlier as of 2018-03-01
* Likewise for 0.14.0 as of 2018-05-01
* Thereafter we'll adopt a regular policy at http://...
That or something like it at least gives people relying on older,
potentially vulnerable versions a realistic chance to privately prepare
and deploy any upgrades or fixes they've missed out on until now.
Cheers,
aj
|
