Can we use Bitcoin client packaged from Debian

[arnuschky]

Hello,

this got me confused:
https://docs.google.com/document/d/1naenR6N6fMWSpHM0f4jpQhYBEkCEQDbLBs8AXC19Y-o/

I always considered using distribution packages over self-compiled versions a good practice security-wise (you don't miss updates) and in terms of compatibility with the overall system.

Is it advised not to follow this reasoning for the Bitcoin client?

What was the incident that caused the developers to create the document above?

[1713283553]

1713283553

[1713283553]

1713283553

[1713283553]

1713283553

[1713283553]

1713283553

[Kluge]

https://en.bitcoin.it/wiki/BIP_50

[arnuschky]

I am aware of the incident (and the wikipage documenting the BIP), but I fail to see the relation to the Debian packaging. Also, this doesn't give an answer to the question if I can safely use a pre-packaged Bitcoin client or if I should compile myself.

Could someone enlighten me?

[mandros]

I am aware of the incident (and the wikipage documenting the BIP), but I fail to see the relation to the Debian packaging. Also, this doesn't give an answer to the question if I can safely use a pre-packaged Bitcoin client or if I should compile myself.

Could someone enlighten me?

Right now, it's safer to get the official binaries than the packaged ones.

As Luke-Jr explains: Testing bitcoind/bitcoin-qt is not sufficient: you must guarantee that your libraries (especially LevelDB) are bug-for-bug compatible with the ones used by everyone else. And not only the current versions, but every future version to ever hit the repository.

The packaging problem is still an ongoing matter, here you can see the mailing list discussion as of today: http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development&thread_name=CAAS2fgRO4ngp%3DXJ3FN%3DTSmLkVguewQXCzK9Oqb68CSeKanW8ug%40mail.gmail.com

[Mike Hearn]

The letter explains why it's better to use upstream binaries.

Also, it's not true that you get updates via your distribution. Typically you don't get updates. What you get is stale software with some security fixes backported, but whether those backports are done correctly or not is anyone's guess - also, some changes aren't easily backported because they may be large architectural changes.  This is the problem Firefox was having which is why they forced Debian to rename their fork of it.

[coinft]

The letter explains why it's better to use upstream binaries.

Also, it's not true that you get updates via your distribution. Typically you don't get updates. What you get is stale software with some security fixes backported, but whether those backports are done correctly or not is anyone's guess - also, some changes aren't easily backported because they may be large architectural changes.  This is the problem Firefox was having which is why they forced Debian to rename their fork of it.

As an aside, Debian does provide excellent security upgrades for their stable distros. Mozilla does not provide security upgrades, and does not allow anyone else to do it either under the name of Firefox. They rather have all users upgrade to the newest version, regardless if new features or bugs break certain use cases. Debian cannot distribute such software so they had to fork and rename it.

I think a software which cannot be supported at a stable version with security backports is flawed or in beta. But bitcoin-qt is even worse as according to the google document it cannot even be reliably built from unmodified source. If we can't trust the source, that's almost like having no source at all.

Fixing this should be highest priority IMHO, and could be the only blocker to get out of beta (1.0).

[Mike Hearn]

Actually it's pretty normal. Some kinds of security upgrades cannot be backported because they are too large, and it's misleading to tell users they are running software that's "stable and secure" when in fact, it lacks important crash/bug fixes and security upgrades.

The idea that you can separate out the security fixes from other changes is somewhat applicable for small programs written in C where security holes are frequent because it's such an unsafe language and the fixes are usually just a small, self-contained patch. Firefox is a very large, complex program written in a mix of different languages where the security issues are often more complicated than buffer overflows. For instance, sandboxed JavaScript execution is inherently difficult because it's such a complex task and that's why browsers have been moving towards process isolation of their JavaScript engines. This is a huge and important security upgrade that all users need to get (Chrome users had it since day 1 of course). But Debian can't backport that no matter what they do. Users who don't make the transition will always be less secure than those who do.

[coinft]

Users who don't make the transition will always be less secure than those who do.

Wrong. Debian users on stable can avoid getting bugs related to new features into their system a priori. The question if stable or the bleeding edge is more secure is a matter of the software, and arguably the bleeding edge is only better for new beta software or software with a flawed development model.

[Mike Hearn]

Er, no. The "bleeding edge" (the latest released version) in any healthy software project is less buggy than the previous versions.

The idea that software somehow ages like a fine cheese is nonsense. This rubbish is peddled by Linux distributors that have boxed themselves into a corner through the failure of initiatives like the LSB. The reality is that if you're running old versions of web browsers (and some other kinds of security critical software) then you are not using software that's more "stable", you're running old software that has known bugs and missing upgrades to the security architecture.

Anyway, I can't be bothered arguing about this. The gigantic screwup that is Linux software distribution is something I sunk too much time into years ago. Fortunately now we have Android that gives a second chance at a working open source OS.

[2112]

I'm just saving this for the future reference. This is perfect example how one is supposed to shill for the software treadmill supplier: first make sure to not follow any quality management process and then produce the stream of rapid updates.

Er, no. The "bleeding edge" (the latest released version) in any healthy software project is less buggy than the previous versions.

The idea that software somehow ages like a fine cheese is nonsense. This rubbish is peddled by Linux distributors that have boxed themselves into a corner through the failure of initiatives like the LSB. The reality is that if you're running old versions of web browsers (and some other kinds of security critical software) then you are not using software that's more "stable", you're running old software that has known bugs and missing upgrades to the security architecture.

Anyway, I can't be bothered arguing about this. The gigantic screwup that is Linux software distribution is something I sunk too much time into years ago. Fortunately now we have Android that gives a second chance at a working open source OS.

[coinft]

Er, no. The "bleeding edge" (the latest released version) in any healthy software project is less buggy than the previous versions.

The idea that software somehow ages like a fine cheese is nonsense. This rubbish is peddled by Linux distributors that have boxed themselves into a corner through the failure of initiatives like the LSB. The reality is that if you're running old versions of web browsers (and some other kinds of security critical software) then you are not using software that's more "stable", you're running old software that has known bugs and missing upgrades to the security architecture.

Anyway, I can't be bothered arguing about this. The gigantic screwup that is Linux software distribution is something I sunk too much time into years ago. Fortunately now we have Android that gives a second chance at a working open source OS.

1. The bleeding edge is usually defined as the newest. Almost all bugs start their public life in a bleeding edge version. If you were right, new versions would only ever reduce the bug count and never make it worse. I don't buy that, except for comatose projects, surely not healthy ones.

2. Are you serious? Android is another Linux Distro with custom frontend and some special hardware drivers. I don't have time to feed trolls.