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.bainbri...@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.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
