public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Anthony Towns <aj@erisian.com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Responsible disclosure of bugs
Date: Tue, 12 Sep 2017 14:47:58 +1000	[thread overview]
Message-ID: <20170912044758.GE19080@erisian.com.au> (raw)
In-Reply-To: <CAHpxFbH_5Pb5ZmNCW==fmZWxN3bH7KNjzJsMV5KJ=bjCPWMx6A@mail.gmail.com>

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



  parent reply	other threads:[~2017-09-12  4:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-10 22:03 [bitcoin-dev] Responsible disclosure of bugs Simon Liu
2017-09-10 23:02 ` Matt Corallo
2017-09-10 23:28   ` CryptAxe
2017-09-11  2:15   ` Anthony Towns
2017-09-11 11:34     ` Alex Morcos
2017-09-11 17:43       ` Daniel Stadulis
2017-09-11 18:29         ` Gregory Maxwell
2017-09-12  4:47         ` Anthony Towns [this message]
2017-09-12  3:37       ` Anthony Towns
2017-09-12  4:49         ` Sergio Demian Lerner
2017-09-12 16:10           ` Simon Liu
2017-09-14  5:27             ` Anthony Towns
2017-09-22  2:00               ` Nathan Wilcox
2017-09-22 19:53                 ` Sergio Demian Lerner
2017-09-12 17:57           ` Gregory Maxwell
2017-09-12  5:18         ` Bryan Bishop
2017-09-12 17:41         ` Gregory Maxwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170912044758.GE19080@erisian.com.au \
    --to=aj@erisian.com.au \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox