Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3F03D98C for ; Tue, 12 Sep 2017 04:50:16 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5B29013E for ; Tue, 12 Sep 2017 04:50:15 +0000 (UTC) Received: by mail-io0-f177.google.com with SMTP id v36so26633865ioi.1 for ; Mon, 11 Sep 2017 21:50:15 -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; bh=0TD+bKHGIq4CGZG2q+adVUDIgniwlU0JiJkyaJrvqMM=; b=uE48q1+DTABoFF4XVxBr9kQfEJVM5Oz2PTCUoPvmqWuGLXPkBWXjQeUNUj3oOKRUsJ BpvxnC2PlcgwPkho2IcXbUnjKmKvGm9OZ/q4PYEnDUoAlCcm+7q0axSs5fUnXTZSaUDc GDL4jmBmF6Fk+goC+P7paFrM5ed3zweScGg75PEGSPyPZ9TjE+eJuOxiqeyawQJErpuM 2eR1YTz/9DfRwuMzYmh8gv1aDaPga+aKP3yB8++EgXvLHpPJ9XfFDnCLKmIJjVRiAUGH 9lUq1ZEkGgIMziGs5SWdTXeKTs81uqS3EIJgsi+R0ywTqwCUCXiGv0XvVKdpT4LW12Kp cakw== 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; bh=0TD+bKHGIq4CGZG2q+adVUDIgniwlU0JiJkyaJrvqMM=; b=kNLnEkmgkphI4S0j103rJ6AWKUMrpcp7+L0fC7wwakeUxCJKqkCe4NgaPapoD/Cepd ZW0idiZGR2ZEzIxj3v0ZjBHME0vR2wFEjBmcMSBjIaRQ2T/Z6pF9J9HP59xwL5WWQUPS rrRmcphvfqXH2d6nnltoEPlNbymjfSJ1Cypvj4sW2+eEddaA8hal5AjZeYo+3S+GZndG Lubebt8mPPAz2bG6SWMnnGlQdh/PDPRqwPBpLU7z3OnFPDhFIihl3xZyCnbsB1woDKtP ABMc+KdrpwcAXjEezgDhrsDCkJ6Tx9qXnl1I8kOG1zmys0Lk5UWrUW6RDDLSzjS+BsJZ YwvA== X-Gm-Message-State: AHPjjUjTTCOE74iOzfGFfH6yRe2FVOiFQOu50zr8o93B1fg8PO6hGEvK LMqjfxY7U9Ode/GtM9UuEu4Hj0sL6w== X-Google-Smtp-Source: ADKCNb5puOwsmFk6Eq773b8iTqUiwqrjGBfIY1mbE6exke1HRG1s6q6Ki1faBbEz0OGIAiYHeZOMIjKdKQqELXXW7Ck= X-Received: by 10.202.178.133 with SMTP id b127mr4680305oif.319.1505191814585; Mon, 11 Sep 2017 21:50:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.20.229 with HTTP; Mon, 11 Sep 2017 21:49:34 -0700 (PDT) In-Reply-To: <20170912033703.GD19080@erisian.com.au> References: <3e4541f3-f65c-5199-5e85-9a65ea5142e7@bitcartel.com> <20170911021506.GA19080@erisian.com.au> <20170912033703.GD19080@erisian.com.au> From: Sergio Demian Lerner Date: Tue, 12 Sep 2017 01:49:34 -0300 Message-ID: To: Anthony Towns , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a113b5e326d632b0558f6c704" 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: Tue, 12 Sep 2017 11:24:14 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 04:50:16 -0000 --001a113b5e326d632b0558f6c704 Content-Type: text/plain; charset="UTF-8" Historically people have published vulnerabilities in Bitcoin only after >80% of the nodes have upgraded. This seems to be the general (but not publicly stated) policy. If you're a core developer and you know better, please correct me. This means that: - a critical vulnerability, like a remote code execution, will be patched immediately (without disclosing the actual problem) and all participants will be notified asap. This is no different from any other open source project. An example of this case was the OpenSSL Heartbleed vulnerability that affected Bitcoin. - a non-critical vulnerability, either because miners only can exploit it or because it requires vast resources to pull, may require a wait of years before publication, after a vulnerability was found and reported. This is because the "natural" node upgrade rate is slow. It also implies that some times a researcher works hard to investigate a vulnerability and later he finds out it was previously reported. It also means that the researcher cannot report to alt-coins which have a different policy. This policy has nothing to do with a loyalty to Bitcoin Core (or in fact, the two or so developers that actually receive the e-mails to security@bitcoincore.org). This is a policy that has simply proven to work to protect Bitcoiners. It began long long ago. On Tue, Sep 12, 2017 at 12:37 AM, Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Mon, Sep 11, 2017 at 07:34:33AM -0400, Alex Morcos wrote: > > I don't think I know the right answer here, but I will point out two > things > > that make this a little more complicated. > > 1 - There are lots of altcoin developers and while I'm sure the majority > would > > greatly appreciate the disclosure and would behave responsibly with the > > information, I don't know where you draw the line on who you tell and > who you > > don't. > > If you can't pick even a small group that's trustworthy (top five by > market cap as a start [0]? or just major bitcoin wallets / exchanges / > alt node implementations?), then it still seems better to (eventually) > disclose publically than keep it unrevealed and let it be a potential > advantage for attackers against people who haven't upgraded for other > reasons? > > 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 > on bitcoin users and businesses; at best 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) > > > 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? (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...") > > (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. That > way a new release going out to other people helps keep you safe, even > while you continue to maintain the same definition of money by not > upgrading at all) > > If altcoin maintainers are inconvenienced by tracking bitcoin-core > updates, that would be an argument for them to contribute back to their > upstream to make their own job easier; either helping with backports, > or perhaps contributing to patches like PR#8994 might help. > > All of those things seem like they'd help not just altcoins but bitcoin > investors/traders too, so it's not even a trade-off between classes of > bitcoin core users. And if in the end various altcoins aren't able to > keep up with security fixes, that's probably valuable information to > provide to the market... > > Cheers, > aj > > [0] Roughly: BCash, Litecoin, Dash, BitConnect, ZCash, Dogecoin? > I've no idea which of those might have trustworthy devs to work with, > but surely at least a couple do? > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a113b5e326d632b0558f6c704 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Historically people have published vulnerabilities in Bitc= oin only after >80% of the nodes have upgraded. This seems to be the gen= eral (but not publicly stated) policy. If you're a core developer and y= ou know better, please correct me.

This means that:

- a critical vulnerability, like a remote code executi= on, will be patched immediately (without disclosing the actual problem) and= all participants will be notified asap. This is no different from any othe= r open source project. An example of this case was the OpenSSL Heartbleed v= ulnerability that affected Bitcoin.

- a non-critic= al vulnerability, either because miners only can=C2=A0exploit it or because= it requires vast resources to pull, may require a wait of years before pub= lication, after a vulnerability was found and reported. This is because the= "natural" node upgrade rate is slow.

It= also implies that some times a researcher works hard to investigate a vuln= erability and later he finds out it was previously reported. It also means = that the researcher cannot report to alt-coins which have a different polic= y.

This policy has nothing to do with a loyalty to= Bitcoin Core (or in fact, the two or so developers that actually receive t= he e-mails to security@bitcoinc= ore.org).=C2=A0

This is a policy that has simp= ly proven to work to protect Bitcoiners. It began long long ago.
=


On Tue, Sep 12, 2017 at 12:37 AM, Anthony Towns via bitcoin-d= ev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Mon, Sep 11= , 2017 at 07:34:33AM -0400, Alex Morcos wrote:
> I don't think I know the right answer here, but I will point out t= wo things
> that make this a little more complicated.
> 1 - There are lots of altcoin developers and while I'm sure the ma= jority would
> greatly appreciate the disclosure and would behave responsibly with th= e
> information, I don't know where you draw the line on who you tell = and who you
> don't.

If you can't pick even a small group that's trustworthy (top= five by
market cap as a start [0]? or just major bitcoin wallets / exchanges /
alt node implementations?), then it still seems better to (eventually)
disclose publically than keep it unrevealed and let it be a potential
advantage for attackers against people who haven't upgraded for other reasons?

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<= br> on bitcoin users and businesses; at best 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)

> 2- Unlike other software, I'm not sure good security for bitcoin i= s defined by
> constant upgrading.=C2=A0 Obviously upgrading has an important benefit= , but one of
> the security considerations for Bitcoin is knowing that your definitio= n of the
> money hasn't changed.=C2=A0 Much harder to know that if you change= software.

Isn't that just an argument for putting more effort into backpor= ting
fixes/workarounds? (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...")

(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 w= ill. That
way a new release going out to other people helps keep you safe, even
while you continue to maintain the same definition of money by not
upgrading at all)

If altcoin maintainers are inconvenienced by tracking bitcoin-core
updates, that would be an argument for them to contribute back to their
upstream to make their own job easier; either helping with backports,
or perhaps contributing to patches like PR#8994 might help.

All of those things seem like they'd help not just altcoins but bitcoin=
investors/traders too, so it's not even a trade-off between classes of<= br> bitcoin core users.=C2=A0 And if in the end various altcoins aren't abl= e to
keep up with security fixes, that's probably valuable information to provide to the market...

Cheers,
aj

[0] Roughly: BCash, Litecoin, Dash, BitConnect, ZCash, Dogecoin?
=C2=A0 =C2=A0 I've no idea which of those might have trustworthy devs t= o work with,
=C2=A0 =C2=A0 but surely at least a couple do?

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--001a113b5e326d632b0558f6c704--