[Pkg-bitcoin-devel] Bug#718272: Bug#718272:

[Scott Howard]

Thank you, Chris. I think you articulated the situation well and the options.


On Wed, Jun 25, 2014 at 1:18 PM, Chris Bainbridge
<chris.bainbridge at gmail.com> wrote:
> This is not necessary as the debian-installer already enables
> stable-updates by default.

stable-updates is enabled by default, but not stable-proposed-updates.
That means that users will have to wait on the order of 2 months or
more for new versions. security updates are instantaneous and is
probably the better way of handling network changes that cannot be
delayed.

> Backporting is not necessary. The package can be version bumped for a
> security update, or version bumped in stable-updates for non-security
> changes. In the case of Bitcoin, mandatory network changes could
> arguably be considered "security updates" if they prevent the bitcoin
> server from working, because being unable to update the copy of the
> blockchain would open up additional attack vectors.

I agree mandatory network changes can be argued to be a security
update and could be the best way forward, but they do not prevent the
bitcoin server from working. It still works and creates a fragmented
network with every other non-updated server. That network acts just
like the "real" network and could, in theory, supplant or reject the
"real" network. That's what happened here [1]. It wasn't really a
security threat as much as a incompatibility in the protocols with a
potential for financial loss. This is a new area for Debian: data
loss, corruption, exploitation, unauthorized access are all clearly
security bugs, but is potential financial loss from to a "working as
intended" system a security bug? Maybe, we'd need the security team's
opinion on that.

> tor has very similar restrictions (version <1.0, network protocol
> could change) and yet it is in both stable and testing. Testing
> already has other software (cgminger, bfgminer) that is reliant on the
> bitcoin protocol. Given all this, I do not think that the problems
> presented in this bug are a reason to hold up bitcoin from entering
> testing or, ultimately, stable.

I think it's possible for us to get the package ready for release in
jessie if we have a proper management plan. There are 3 possible
changes to bitcoin:

1) Security fixes
2) Network protocol changes [2]
3) New features/usability bug fixes

We need a plan that allows us to definitely fix 1 and 2 for users in a
stable release as needed on short notice.

1) is clearly doable via security updates.
2) is harder. stable-updates takes too long (see above). Protocol
changes are not traditional security bugs, but might be classified as
one. It's a different situation than tor [3].
3) doable via stable-updates (or backports)

This is my opinion, but if we can get someone from the security team
to say that they will accept bitcoin network protocol changes as
security bugs, then I think that would be acceptable to do 1 and 2 via
security AND also update the package to new versions using
stable-updates. This is my opinion, but I think 2 months+ is too long
for default users to wait for network protocol changes which sometimes
require a response on the order of days or hours. We'd also have to
remember to patch both the stable and stable-updates version of the
package for each protocol change. As you can see, this gets
complicated, and there is much downside if something goes wrong - thus
my general uneasiness towards having bitcoin in a stable release.

Something to keep in mind: this may be confusing to some users when
they are told they must upgrade to version 0.10, and we keep 0.9-2
where our -2 includes the required protocol changes in 0.10, but that
isn't that big of a problem and would just require proper
communication probably via the debian news and changelog files.

In somewhat related news, bitcoin is talking about splitting the
wallet out from the node. An SPV wallet will be safe to ship in a
stable release, even if the nodes are not.


In summary: I think the next step is for someone to contact the
security team to see what they think of the situation.

Cheers,
Scott


[1] https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki

[2] cgminer and bfgminer actually don't rely on the bitcoin protocol,
they use either JSON RPC commands or the stratum protocol and are
independent of the bitcoin protocol. Yes, that interface can (and
does) change, but such changes are not as catastrophic as a bitcoin
fork and have been backwards compatible in the past.

[3] Like tor, if a large percentage of users are using the wrong
version of the bitcoin protocol, it is possible that the network will
become fragmented. A fragmented bitcoin network could lead to lost
transactions for the specific user and damage bitcoin's credibility
(leading to large financial losses for every user of the network). I
may be wrong, but I believe tor fragmentation is serious, but not as
grave (if the tor network fragments due to a non-security based
protocol change, all that happens is the network of peers you are
connecting to shrinks to the set of people with the same protocol as
you and you may not connect to a specific peer/server you want to
connect to.)