From: Gregory Maxwell <greg@xiph•org>
To: Anthony Towns <aj@erisian•com.au>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Responsible disclosure of bugs
Date: Tue, 12 Sep 2017 17:41:42 +0000 [thread overview]
Message-ID: <CAAS2fgRNkM3cSF8YpE8u8Znh-0nMCNR2oD_tMpyC91yOuAZFNA@mail.gmail.com> (raw)
In-Reply-To: <20170912033703.GD19080@erisian.com.au>
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.
prev parent reply other threads:[~2017-09-12 17:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-10 22:03 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
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 [this message]
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=CAAS2fgRNkM3cSF8YpE8u8Znh-0nMCNR2oD_tMpyC91yOuAZFNA@mail.gmail.com \
--to=greg@xiph$(echo .)org \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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