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
141
142
143
144
145
146
147
148
149
150
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 52E1AA7B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Sep 2017 17:41:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com
[209.85.213.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D5BC0203
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Sep 2017 17:41:43 +0000 (UTC)
Received: by mail-vk0-f53.google.com with SMTP id x85so13662524vkx.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Sep 2017 10:41:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to; bh=391rJZeMRRonfJ8Os6svahe6VWbb7POjwZo4wpq97OA=;
b=Vctnx1/C06PnoCZIwfttfMMx+16NVW2jQRzmJZp9lqPRE3tErhRjSZqJ4sB58akjyt
RKsKEX8i0x55tQ4EdrnrlmfWS2jiHaJsG7Q1iHpOj8fnS+f5f2Vse58DX3Mjf0AZpuh8
+2p6BxaK0RjrlPRmDKpBhzvqzl5fhUNJXBxEh3Nf7/xeBa5wU0PHJ+SxRz4Y3kC5ZNz6
wB4N5XuyuP8bkryfTaFWlrV0f8iN1qRn4IBnGt0+XQvdv9IaxymMEM4Ff327BCiRdkxE
ZHa6Cd6/ytWqpf9Pjldc/H9LquZ1fARZ8LehprpTm2M90uv3LJ2lrjYTjaug6dk+2Fyn
+H9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to;
bh=391rJZeMRRonfJ8Os6svahe6VWbb7POjwZo4wpq97OA=;
b=JzkCgWbBihKxgX6CGlUW4UWL7issZjJoznoA4D7tEAaiAQVQFjtgsMw2cH/EyNuHW1
Q6flmQnt+psPnJYZ+zmgk7jrQ707D7Kv4kJZCDU3JvDPKC+lJWlWaNJ7GprES8rdRtJr
6BHlccGueZE92eMwB1pWb+u0v/M8slXaAZuXK8Sc17tBindxs60ABn6OgIp3zaVuYaIZ
xpxGObWek5EZ2nxLGW9oK2Pr9sB7dxO1CMk08b1O7Agjp6mLeu6fYG9+VSqkFmNacUz8
JlwKaaSm12gur1MJ0TIyJILxl47AoSj7ESn6FSUtzahOOmJxt4JivzxgF3RbPdcC9piu
klvw==
X-Gm-Message-State: AHPjjUijswNxRvUtMzLLiQdTqj09ByV09hIb8GCFX+EpM2yuHgIcG//w
hF6y74x8hVsxPQ9kLHtsH0mEZrgTGg==
X-Google-Smtp-Source: AOwi7QAIlewaNtn3p5abJanAzXZ4ODinZSEFUm6Wmb3jG87ChZfsDZNFkE96oSqtTCL5DTPu2Yfq9LSBHjubsJB6GHA=
X-Received: by 10.31.254.195 with SMTP id l186mr10057919vki.149.1505238102945;
Tue, 12 Sep 2017 10:41:42 -0700 (PDT)
MIME-Version: 1.0
Sender: gmaxwell@gmail.com
Received: by 10.103.146.78 with HTTP; Tue, 12 Sep 2017 10:41:42 -0700 (PDT)
In-Reply-To: <20170912033703.GD19080@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>
<20170912033703.GD19080@erisian.com.au>
From: Gregory Maxwell <greg@xiph.org>
Date: Tue, 12 Sep 2017 17:41:42 +0000
X-Google-Sender-Auth: ZnxvrZypiT9TBd5__g5XAmS5ZRc
Message-ID: <CAAS2fgRNkM3cSF8YpE8u8Znh-0nMCNR2oD_tMpyC91yOuAZFNA@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
FREEMAIL_FROM, 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: Tue, 12 Sep 2017 17:41:44 -0000
On Tue, Sep 12, 2017 at 3:37 AM, Anthony Towns via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> If you can't pick even a small group that's trustworthy
No.
> I find it hard to imagine bitcoin's still obscure enough that people
> aren't tracking git commit logs to use them as inspiration for attacks
For embargoed fixes we test the specific fixes against experienced
developers inside the project, handing them the proposed commit and
informing them that it fixes a vulnerability and asking them to
identify it.
This does not guarantee that the fix won't leak the issue, but in
virtually all cases in the past the issues we've dealt with would not
be made worse off being leaked in that way vs just making it public
outright.
If we had an issue that would be-- e.g. an RCE that could lead to
private key theft, we would likely handle it differently (e.g. making
a public notice to take sensitive systems offline before attempting
any fix).
> I would have thought it'd
> only be a few months of development time between a fix being proposed
> as a PR or committed to master and black hats having the ability to
> exploit it in users who are running older nodes. (Or for that matter,
> being able to be exploited by otherwise legitimate bitcoin businesses
> with an agenda to push, a strong financial motive behind that agenda,
> and a legal team that says they'll get away with it)
History does not support your assumptions.
>> 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.
>
> Isn't that just an argument for putting more effort into backporting
> fixes/workarounds?
Not really. Any forced change still creates centralization,
dependence, and an opportunity for insecurity.
> (I don't see how you do that without essentially
> publically disclosing which patches have a security impact -- "oh,
> gosh, this patch gets a backport, I wonder if maybe it has security
> implications...")
That is a concern too, but our bar for backport fixes is low enough
that they're often able to include more serious fixes without calling
attention to them.
> (In so far as bitcoin is a consensus system, there can sometimes be a
> positive network effect, where having other people upgrade can help your
> security, even if you don't upgrade; "herd immunity" if you will.
This is true even outside of the consensus critical parts. In the P2P
network other people upgrading can be protective.
> If altcoin maintainers are inconvenienced by tracking bitcoin-core
> updates, that would be an argument for them to contribute back to their
Sure, a few have. Most do not because they are either not focused on
software quality or consider themselves as having an adversarial
relationship with Bitcoin.
> keep up with security fixes, that's probably valuable information to
> provide to the market...
If you'd like to provide the sort of valuable information to the
market which may get you sued or targeted for harassment of physical
attack-- feel free. Don't ask the rest of us to do so.
|
