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
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
|
Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 664728E3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Sep 2017 19:54:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f174.google.com (mail-io0-f174.google.com
[209.85.223.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 11158189
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Sep 2017 19:54:27 +0000 (UTC)
Received: by mail-io0-f174.google.com with SMTP id k101so5497213iod.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Sep 2017 12:54:27 -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
:cc; bh=oFLy5wp/mTR5xOzBETDoi5EBgLxPEvqnarWWffx0YuU=;
b=NdBtKHbDnLG0oZgQB4kUba1bg1YXMwqITf0HStCS4QOiHqtQwRjF5KDlIaWfB0Jv+e
4IHfltz+nn4bVOO0U/uMf9Gpflatx5Oftu8MB7YHYa3+C9q52glKqKrXKFz9thoC9wI1
EFVvKgG1BJe4w8un8J9dzbwRKuixIplS1S/pa4eJtHZ/lpfaO5wtjN5zrxyWBMKnpAEr
6ZRKCFLGKJpL1pTnUD89a3rLLxmiY6rFhnAP3HxnX9VVqoleKpBXY9rlA2ys8QPyrvWg
tpGwkTGjAkQ89nHU4k/KU+7rm50O9t2FGStrQKhLBiLlcrdmFJoXgdCugpVWdJ2rgjYM
z5HA==
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:cc;
bh=oFLy5wp/mTR5xOzBETDoi5EBgLxPEvqnarWWffx0YuU=;
b=RvC8qVBmdMmC/WxQVa1EMYAducI0gePxBI5uP2ossc1XWWQ5fjwYMmro0y05DhaicD
SuTSz7HhrXJfQEZTEi00uKb+IppcMiiVnkyf88yHjl4USRdsTWrzCJyvgFTBViT1MqKO
u3nkDx/e92Edb5eJoWNjlGjFLMLBCw9lrlpA1VCexNIYZZovi9pq+/HbM9hxdEGSxC0y
CdG3IhBzopNdUX0zIiCpVxVgth5E0mrVSp8ximbU5q7AI3td4PIx9el+Jm8w+6ggmP40
oNeOqhFDxelHCI9gfiyfNSipwIac4TkUeOKJSr+T393cNSUVp8but2w2PH9foHDH4hm1
lUFw==
X-Gm-Message-State: AHPjjUhJl0ev2Jnykhoon/kTdaw46hebBNCbCHfvZC4+gZM+Cz5MET83
hNY6wBB2yu0gEsnStKAeJfhkmaevauEgW8imcrE=
X-Google-Smtp-Source: AOwi7QAM1a/WhfhsqrXi4Mx14mF2xw+/jv5/urhk2LqZX9W0TTGkNPiyrbeI6tuwPL6l2aLeMq8a0TicTftQL/kD9w4=
X-Received: by 10.202.232.140 with SMTP id f134mr351593oih.204.1506110067194;
Fri, 22 Sep 2017 12:54:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.85.72 with HTTP; Fri, 22 Sep 2017 12:53:46 -0700 (PDT)
In-Reply-To: <CAK8perD5as_oTJ3tRvrG2pAjWZq91xbuzguuVD5ZY4UswyL5kQ@mail.gmail.com>
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>
<CAKzdR-oYQ8EchpJVE56yJbfBgNHihx7WO_gtFtp6QKOcK7uT-w@mail.gmail.com>
<e28e151a-1a67-4e90-f5fd-721cbc7f213d@bitcartel.com>
<20170914052740.GA2674@erisian.com.au>
<CAK8perD5as_oTJ3tRvrG2pAjWZq91xbuzguuVD5ZY4UswyL5kQ@mail.gmail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Fri, 22 Sep 2017 16:53:46 -0300
Message-ID: <CAKzdR-ok5Gd8fBbDuCcAuZ1S_iym4Ub3eXRvKBj31w1us5NG4Q@mail.gmail.com>
To: Nathan Wilcox <nathan@z.cash>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a114085f48c47350559cc9368"
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
X-Mailman-Approved-At: Fri, 22 Sep 2017 19:59:19 +0000
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: Fri, 22 Sep 2017 19:54:30 -0000
--001a114085f48c47350559cc9368
Content-Type: text/plain; charset="UTF-8"
The policy seems good with the exception of this paragraph:
* Bitcoin devs will disclose vulnerabilities publically after 99% of the
bitcoin network has upgraded [7], and fixes have been released for
at least 12 months.
99% upgrade may never be reached. Some nodes cannot even be categorized. I
suggest a number close to 95%.
If the 95% of network has upgraded, it means we're pretty secure from the
point of view of consensus. It is supposed that from the time the fix has
been released, all other alt-coins will also have released their fixes.
Remember we must also incentivize security researchers to do the hard and
silent research work. Most of them do not hold Bitcoins. They do research
because of other interests, including getting public acknowledgment for
their findings. They'll be frustrated if they have to wait 2 years.
I propose this paragraph to replace the previous one:
* Bitcoin devs will disclose vulnerabilities publically after 95% of the
bitcoin network has upgraded [7], and fixes have been released for
at least 6 months.
Also I suggest we track vulnerabilities with standard CVE codes. IS there
any drawback of this?
regards
On Thu, Sep 21, 2017 at 11:00 PM, Nathan Wilcox via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> [inline responses]
>
>
> On Thu, Sep 14, 2017 at 2:27 PM, Anthony Towns via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Tue, Sep 12, 2017 at 09:10:18AM -0700, Simon Liu wrote:
>> > It would be a good starting point if the current policy could be
>> > clarified, so everyone is on the same page, and there is no confusion.
>>
>> Collecting various commentary from here and reddit, I think current de
>> facto policy is something like:
>>
>> * Vulnerabilities should be reported via security@bitcoincore.org [0]
>>
>> * A critical issue (that can be exploited immediately or is already
>> being exploited causing large harm) will be dealt with by:
>> * a released patch ASAP
>> * wide notification of the need to upgrade (or to disable affected
>> systems)
>> * minimal disclosure of the actual problem, to delay attacks
>> [1] [2]
>>
>> * A non-critical vulnerability (because it is difficult or expensive to
>> exploit) will be dealt with by:
>> * patch and review undertaken in the ordinary flow of development
>> * backport of a fix or workaround from master to the current
>> released version [2]
>>
>> * Devs will attempt to ensure that publication of the fix does not
>> reveal the nature of the vulnerability by providing the proposed fix
>> to experienced devs who have not been informed of the vulnerability,
>> telling them that it fixes a vulnerability, and asking them to identify
>> the vulnerability. [2]
>>
>> * Devs may recommend other bitcoin implementations adopt vulnerability
>> fixes prior to the fix being released and widely deployed, if they
>> can do so without revealing the vulnerability; eg, if the fix has
>> significant performance benefits that would justify its inclusion. [3]
>>
>> * Prior to a vulnerability becoming public, devs will generally recommend
>> to friendly altcoin devs that they should catch up with fixes. But this
>> is only after the fixes are widely deployed in the bitcoin network. [4]
>>
>> * Devs will generally not notify altcoin developers who have behaved
>> in a hostile manner (eg, using vulnerabilities to attack others, or
>> who violate embargoes). [5]
>>
>> * Bitcoin devs won't disclose vulnerability details until >80% of bitcoin
>> nodes have deployed the fixes. Vulnerability discovers are encouraged
>> and requested to follow the same policy. [1] [6]
>>
>> Those seem like pretty good policies to me, for what it's worth.
>>
>>
> I advocate a policy like this, except I propose two modifications:
>
> - Point 4 should include *zero or more* altcoin developers, such that
> those altcoins also deploy mitigations as early as Bitcoin. (Call this
> "early altcoin disclosure".)
>
> - Disclose of vulnerabilities, by social convention, always explicitly
> names which altcoin developers were included in my proposed Early Altcoin
> Disclosure and Point 6.
>
> The rationale is that the policy should allow closer coordination with
> altcoins. If the goal is minimizing economic damage, including altcoins
> earlier may be the better trade-off between inclusiveness and secrecy. At
> the same time, the policy doesn't establish *which* altcoins, which is a
> tricky choice. However it *does* require disclosure of those relationships,
> which provides a form of feedback on the system.
>
> Imagine if altcoin X is compromised, and later disclosure occurs that
> reveals that altcoin X was not contacted early, then this *might* indicate
> leaks, maliciousness in the Bitcoin mitigation organization, or it *might*
> be coincidence or dumb luck. In the other case, if the Bitcoin disclosure
> reveals that X was indeed contacted early, then it probably indicates
> incompetence of the altoin X.
>
> Finally, notice that this kind of loose early disclosure policy can be
> symmetric. For example, Zcash developers may choose to disclose
> vulnerabilities they discover which affect Bitcoin to Bitcoin developers
> *before* Zcash releases fixes, or before those fixes are widely adopted in
> Zcash. We actually have a policy of doing this, since it's obvious that if
> our mitigation process leaks and that's used to attack Bitcoin the
> potential economic damage is very large.
>
>
>
>> I haven't seen anything that indicates bitcoin devs will *ever* encourage
>> public disclosure of vulnerabilities (as opposed to tolerating other
>> people publishing them [6]). So I'm guessing current de facto policy is
>> more along the lines of:
>>
>> * Where possible, Bitcoin devs will never disclose vulnerabilities
>> publically while affected code may still be in use (including by
>> altcoins).
>>
>> rather than something like:
>>
>> * Bitcoin devs will disclose vulnerabilities publically after 99% of the
>> bitcoin network has upgraded [7], and fixes have been released for
>> at least 12 months.
>>
>>
> I advocate for something like the latter case. I'd like to see a timeout
> on disclosure. There's an endless tail of alt-coins that could be affected,
> and no guarantee all will vigilantly upgrade. Meanwhile, deciding which of
> them to disclose to confidentially versus which should just receive hints
> to apply new patches is tricky and political.
>
> Having a global timeout is a reasonable stop-gap. I consider the cost of
> never disclosing, publicly, a known vulnerbility to be very high, even if
> the fix is ubiquitously deployed, because it's a loss of security
> knowledge, a precious public good.
>
>
>>
>> Instinctively, I'd say documenting this policy (or whatever it actually
>> is) would be good, and having all vulnerabilities get publically released
>> eventually would also be good; that's certainly the more "open source"
>> approach. But arguing the other side:
>>
>> - documenting security policy gives attackers a better handle on where
>> to find weak points; this may be more harm than there is benefit to
>> improving legitimate users' understanding of and confidence in the
>> development process
>>
>>
> Publishing a policy *might* increase organizational vulnerability, but so
> might *not publishing* a policy. It seems fairly neutral to me on
> vulnerability impact, whereas the benefit is good for users and developers.
>
>
>
>> - the main benefit of public vulnerability disclosure is a better
>> working relationship with security researchers and perhaps better
>> understanding of what sort of bugs happen in practice in general;
>> but if most of your security research is effectively in house [6],
>> maybe those benefits aren't as great as the harm done by revealing
>> even old vulnerabilities to attackers
>>
>>
> Publishing after a reasonable timeout has many benefits. Many security
> researchers learn from vulnerability disclosures across many disciplines
> and industries. Future protocol designers of things potentially unrelated
> to blockchain altogether may also learn important lessons.
>
>
> If the first of those arguments holds, well, hopefully this message has
>> egregious errors that no one will correct, or it will quickly get lost
>> in this list's archives...
>>
>> Cheers,
>> aj
>>
>>
> regards,
> Nathan Wilcox
> Zcash
>
>
>> [0] http://bitcoincore.org/en/contact
>> referenced from .github/ISSUE_TEMPLATE.md in git
>>
>> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
>> -September/014986.html
>>
>> [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
>> -September/014990.html
>>
>> [3] https://www.reddit.com/r/btc/comments/6zf1qo/peter_todd_nice
>> ly_pulled_away_attention_from_jjs/dmxcw70/
>>
>> [4] https://www.reddit.com/r/btc/comments/6z827o/chris_jeffrey_j
>> j_discloses_bitcoin_attack_vector/dmxdg83/
>>
>> [5] https://www.reddit.com/r/btc/comments/6zb3lp/maxwell_admits_
>> core_sat_on_vulnerability/dmv4y7g/
>>
>> [6] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
>> -September/014991.html
>>
>> [7] Per http://luke.dashjr.org/programs/bitcoin/files/charts/branche
>> s.html
>> it seems like 1.7% of the network is running known-vulnerable versions
>> 0.8 and 0.9; but only 0.37% are running 0.10 or 0.11, so that might
>> argue
>> revealing any vulnerabilities fixed since 0.12.0 would be fine...
>> (bitnodes.21.co doesn't seem to break down anything earlier than
>> 0.12)
>>
>> _______________________________________________
>> 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
>
>
--001a114085f48c47350559cc9368
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The policy seems good with the exception of this paragraph=
:<div><br></div><div><span style=3D"font-size:12.8px">* Bitcoin devs will d=
isclose vulnerabilities publically after 99% of the</span><br style=3D"font=
-size:12.8px"><span style=3D"font-size:12.8px">=C2=A0 =C2=A0bitcoin network=
has upgraded [7], and fixes have been released for</span><br style=3D"font=
-size:12.8px"><span style=3D"font-size:12.8px">=C2=A0 =C2=A0at least 12 mon=
ths.</span><br style=3D"font-size:12.8px"></div><div><span style=3D"font-si=
ze:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">99% upgra=
de may never be reached. Some nodes cannot even be categorized. I suggest a=
number close to 95%.=C2=A0</span></div><div><span style=3D"font-size:12.8p=
x">If the 95% of network has upgraded, it means we're pretty secure fro=
m the point of view of consensus. It is supposed that from the time the fix=
has been released, all other alt-coins will also have released their fixes=
. =C2=A0</span></div><div><span style=3D"font-size:12.8px">Remember=C2=A0we=
must also incentivize security researchers to do the hard and silent resea=
rch=C2=A0work. Most of them do not hold Bitcoins. They do research because =
of other interests, including getting public acknowledgment=C2=A0for their =
findings. They'll be frustrated if they have to wait 2 years.=C2=A0</sp=
an></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span =
style=3D"font-size:12.8px">I propose this paragraph to replace the previous=
one:</span></div><div><span style=3D"font-size:12.8px"><br></span></div><d=
iv><div><span style=3D"font-size:12.8px">* Bitcoin devs will disclose vulne=
rabilities publically after 95% of the</span><br style=3D"font-size:12.8px"=
><span style=3D"font-size:12.8px">=C2=A0 =C2=A0bitcoin network has upgraded=
[7], and fixes have been released for</span><br style=3D"font-size:12.8px"=
><span style=3D"font-size:12.8px">=C2=A0 =C2=A0at least 6 months.</span><br=
style=3D"font-size:12.8px"></div></div><div><span style=3D"font-size:12.8p=
x"><br></span></div><div><span style=3D"font-size:12.8px">Also I suggest we=
track vulnerabilities with standard CVE codes. IS there any drawback of th=
is?</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div=
><span style=3D"font-size:12.8px">regards</span></div><div><br></div></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Sep 21, 2=
017 at 11:00 PM, Nathan Wilcox via bitcoin-dev <span dir=3D"ltr"><<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoi=
n-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">[inline responses]<br><br><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Thu, Sep =
14, 2017 at 2:27 PM, Anthony Towns via bitcoin-dev <span dir=3D"ltr"><<a=
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bi=
tcoin-dev@lists.<wbr>linuxfoundation.org</a>></span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><span class=3D"m_28150306049552594=
99gmail-">On Tue, Sep 12, 2017 at 09:10:18AM -0700, Simon Liu wrote:<br>
> It would be a good starting point if the current policy could be<br>
> clarified, so everyone is on the same page, and there is no confusion.=
<br>
<br>
</span>Collecting various commentary from here and reddit, I think current =
de<br>
facto policy is something like:<br>
<br>
=C2=A0* Vulnerabilities should be reported via <a href=3D"mailto:security@b=
itcoincore.org" target=3D"_blank">security@bitcoincore.org</a> [0]<br>
<br>
=C2=A0* A critical issue (that can be exploited immediately or is already<b=
r>
=C2=A0 =C2=A0being exploited causing large harm) will be dealt with by:<br>
=C2=A0 =C2=A0 =C2=A0* a released patch ASAP<br>
=C2=A0 =C2=A0 =C2=A0* wide notification of the need to upgrade (or to disab=
le affected<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0systems)<br>
=C2=A0 =C2=A0 =C2=A0* minimal disclosure of the actual problem, to delay at=
tacks<br>
=C2=A0 =C2=A0[1] [2]<br>
<br>
=C2=A0* A non-critical vulnerability (because it is difficult or expensive =
to<br>
=C2=A0 =C2=A0exploit) will be dealt with by:<br>
=C2=A0 =C2=A0 =C2=A0* patch and review undertaken in the ordinary flow of d=
evelopment<br>
=C2=A0 =C2=A0 =C2=A0* backport of a fix or workaround from master to the cu=
rrent<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0released version [2]<br>
<br>
=C2=A0* Devs will attempt to ensure that publication of the fix does not<br=
>
=C2=A0 =C2=A0reveal the nature of the vulnerability by providing the propos=
ed fix<br>
=C2=A0 =C2=A0to experienced devs who have not been informed of the vulnerab=
ility,<br>
=C2=A0 =C2=A0telling them that it fixes a vulnerability, and asking them to=
identify<br>
=C2=A0 =C2=A0the vulnerability. [2]<br>
<br>
=C2=A0* Devs may recommend other bitcoin implementations adopt vulnerabilit=
y<br>
=C2=A0 =C2=A0fixes prior to the fix being released and widely deployed, if =
they<br>
=C2=A0 =C2=A0can do so without revealing the vulnerability; eg, if the fix =
has<br>
=C2=A0 =C2=A0significant performance benefits that would justify its inclus=
ion. [3]<br>
<br>
=C2=A0* Prior to a vulnerability becoming public, devs will generally recom=
mend<br>
=C2=A0 =C2=A0to friendly altcoin devs that they should catch up with fixes.=
But this<br>
=C2=A0 =C2=A0is only after the fixes are widely deployed in the bitcoin net=
work. [4]<br>
<br>
=C2=A0* Devs will generally not notify altcoin developers who have behaved<=
br>
=C2=A0 =C2=A0in a hostile manner (eg, using vulnerabilities to attack other=
s, or<br>
=C2=A0 =C2=A0who violate embargoes). [5]<br>
<br>
=C2=A0* Bitcoin devs won't disclose vulnerability details until >80%=
of bitcoin<br>
=C2=A0 =C2=A0nodes have deployed the fixes. Vulnerability discovers are enc=
ouraged<br>
=C2=A0 =C2=A0and requested to follow the same policy. [1] [6]<br>
<br>
Those seem like pretty good policies to me, for what it's worth.<br>
<br></blockquote></div></div><div><br><div>I advocate a policy like this, e=
xcept I propose two modifications:<br><br></div><div>-
Point 4 should include *zero or more* altcoin developers, such that=20
those altcoins also deploy mitigations as early as Bitcoin. (Call this=20
"early altcoin disclosure".)<br><br></div><div>- Disclose of=20
vulnerabilities, by social convention, always explicitly names which=20
altcoin developers were included in my proposed Early Altcoin Disclosure
and Point 6.<br><br></div><div>The rationale is that the policy should=20
allow closer coordination with altcoins. If the goal is minimizing=20
economic damage, including altcoins earlier may be the better trade-off=20
between inclusiveness and secrecy. At the same time, the policy doesn't=
=20
establish *which* altcoins, which is a tricky choice. However it *does*=20
require disclosure of those relationships, which provides a form of=20
feedback on the system.<br><br></div><div>Imagine if altcoin X is=20
compromised, and later disclosure occurs that reveals that altcoin X was
not contacted early, then this *might* indicate leaks, maliciousness in
the Bitcoin mitigation organization, or it *might* be coincidence or=20
dumb luck. In the other case, if the Bitcoin disclosure reveals that X=20
was indeed contacted early, then it probably indicates incompetence of=20
the altoin X.<br><br></div>Finally, notice that this kind of loose=20
early disclosure policy can be symmetric. For example, Zcash developers=20
may choose to disclose vulnerabilities they discover which affect=20
Bitcoin to Bitcoin developers *before* Zcash releases fixes, or before=20
those fixes are widely adopted in Zcash. We actually have a policy of=20
doing this, since it's obvious that if our mitigation process leaks and=
=20
that's used to attack Bitcoin the potential economic damage is very=20
large.<br><br>=C2=A0</div><span class=3D""><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">
I haven't seen anything that indicates bitcoin devs will *ever* encoura=
ge<br>
public disclosure of vulnerabilities (as opposed to tolerating other<br>
people publishing them [6]). So I'm guessing current de facto policy is=
<br>
more along the lines of:<br>
<br>
=C2=A0* Where possible, Bitcoin devs will never disclose vulnerabilities<br=
>
=C2=A0 =C2=A0publically while affected code may still be in use (including =
by<br>
=C2=A0 =C2=A0altcoins).<br>
<br>
rather than something like:<br>
<br>
=C2=A0* Bitcoin devs will disclose vulnerabilities publically after 99% of =
the<br>
=C2=A0 =C2=A0bitcoin network has upgraded [7], and fixes have been released=
for<br>
=C2=A0 =C2=A0at least 12 months.<br>
<br></blockquote></span><div><br>I advocate for something like the latter c=
ase. I'd like to see a timeout
on disclosure. There's an endless tail of alt-coins that could be=20
affected, and no guarantee all will vigilantly upgrade. Meanwhile,=20
deciding which of them to disclose to confidentially versus which should
just receive hints to apply new patches is tricky and political.<br><br>Ha=
ving
a global timeout is a reasonable stop-gap. I consider the cost of never
disclosing, publicly, a known vulnerbility to be very high, even if the
fix is ubiquitously deployed, because it's a loss of security=20
knowledge, a precious public good.<br>=C2=A0</div><span class=3D""><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
solid rgb(204,204,204);padding-left:1ex">
<br>
Instinctively, I'd say documenting this policy (or whatever it actually=
<br>
is) would be good, and having all vulnerabilities get publically released<b=
r>
eventually would also be good; that's certainly the more "open sou=
rce"<br>
approach. But arguing the other side:<br>
<br>
=C2=A0- documenting security policy gives attackers a better handle on wher=
e<br>
=C2=A0 =C2=A0to find weak points; this may be more harm than there is benef=
it to<br>
=C2=A0 =C2=A0improving legitimate users' understanding of and confidenc=
e in the<br>
=C2=A0 =C2=A0development process<br>
<br></blockquote><br></span></div><div class=3D"gmail_quote">Publishing a p=
olicy *might* increase organizational vulnerability, but so might *not publ=
ishing* a policy. It seems fairly neutral to me on vulnerability impact, wh=
ereas the benefit is good for users and developers.<br><br></div><div class=
=3D"gmail_quote"><span class=3D""><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">
=C2=A0- the main benefit of public vulnerability disclosure is a better<br>
=C2=A0 =C2=A0working relationship with security researchers and perhaps bet=
ter<br>
=C2=A0 =C2=A0understanding of what sort of bugs happen in practice in gener=
al;<br>
=C2=A0 =C2=A0but if most of your security research is effectively in house =
[6],<br>
=C2=A0 =C2=A0maybe those benefits aren't as great as the harm done by r=
evealing<br>
=C2=A0 =C2=A0even old vulnerabilities to attackers<br>
<br></blockquote><div><br></div></span><div>Publishing after a reasonable t=
imeout has many benefits. Many security researchers learn from vulnerabilit=
y disclosures across many disciplines and industries. Future protocol desig=
ners of things potentially unrelated to blockchain altogether may also lear=
n important lessons.<br><br></div><span class=3D""><div><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">
If the first of those arguments holds, well, hopefully this message has<br>
egregious errors that no one will correct, or it will quickly get lost<br>
in this list's archives...<br>
<br>
Cheers,<br>
aj<br>
<br></blockquote><div><br></div></span><div>regards,<br></div><div>Nathan W=
ilcox<br></div><div>Zcash<br></div><span class=3D""><div>=C2=A0<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">
[0] <a href=3D"http://bitcoincore.org/en/contact" rel=3D"noreferrer" target=
=3D"_blank">http://bitcoincore.org/en/cont<wbr>act</a><br>
=C2=A0 =C2=A0 referenced from .github/ISSUE_TEMPLATE.md in git<br>
<br>
[1] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017=
-September/014986.html" rel=3D"noreferrer" target=3D"_blank">https://lists.=
linuxfoundation.<wbr>org/pipermail/bitcoin-dev/2017<wbr>-September/014986.h=
tml</a><br>
<br>
[2] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017=
-September/014990.html" rel=3D"noreferrer" target=3D"_blank">https://lists.=
linuxfoundation.<wbr>org/pipermail/bitcoin-dev/2017<wbr>-September/014990.h=
tml</a><br>
<br>
[3] <a href=3D"https://www.reddit.com/r/btc/comments/6zf1qo/peter_todd_nice=
ly_pulled_away_attention_from_jjs/dmxcw70/" rel=3D"noreferrer" target=3D"_b=
lank">https://www.reddit.com/r/btc/c<wbr>omments/6zf1qo/peter_todd_nice<wbr=
>ly_pulled_away_attention_from_<wbr>jjs/dmxcw70/</a><br>
<br>
[4] <a href=3D"https://www.reddit.com/r/btc/comments/6z827o/chris_jeffrey_j=
j_discloses_bitcoin_attack_vector/dmxdg83/" rel=3D"noreferrer" target=3D"_b=
lank">https://www.reddit.com/r/btc/c<wbr>omments/6z827o/chris_jeffrey_j<wbr=
>j_discloses_bitcoin_attack_vec<wbr>tor/dmxdg83/</a><br>
<br>
[5] <a href=3D"https://www.reddit.com/r/btc/comments/6zb3lp/maxwell_admits_=
core_sat_on_vulnerability/dmv4y7g/" rel=3D"noreferrer" target=3D"_blank">ht=
tps://www.reddit.com/r/btc/c<wbr>omments/6zb3lp/maxwell_admits_<wbr>core_sa=
t_on_vulnerability/<wbr>dmv4y7g/</a><br>
<br>
[6] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017=
-September/014991.html" rel=3D"noreferrer" target=3D"_blank">https://lists.=
linuxfoundation.<wbr>org/pipermail/bitcoin-dev/2017<wbr>-September/014991.h=
tml</a><br>
<br>
[7] Per <a href=3D"http://luke.dashjr.org/programs/bitcoin/files/charts/bra=
nches.html" rel=3D"noreferrer" target=3D"_blank">http://luke.dashjr.org/pro=
gram<wbr>s/bitcoin/files/charts/branche<wbr>s.html</a><br>
=C2=A0 =C2=A0 it seems like 1.7% of the network is running known-vulnerable=
versions<br>
=C2=A0 =C2=A0 0.8 and 0.9; but only 0.37% are running 0.10 or 0.11, so that=
might argue<br>
=C2=A0 =C2=A0 revealing any vulnerabilities fixed since 0.12.0 would be fin=
e...<br>
=C2=A0 =C2=A0 (<a href=3D"http://bitnodes.21.co" rel=3D"noreferrer" target=
=3D"_blank">bitnodes.21.co</a> doesn't seem to break down anything earl=
ier than 0.12)<br>
<div class=3D"m_2815030604955259499gmail-HOEnZb"><div class=3D"m_2815030604=
955259499gmail-h5"><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br>
</div></div></blockquote></span></div><br></div></div>
<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>
<br></blockquote></div><br></div>
--001a114085f48c47350559cc9368--
|