Debian Bug report logs - #718272
upstream does not support stable releases (block migration to testing)

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Scott Howard <showard@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: upstream does not support stable releases (block migration to testing)

Date: Mon, 29 Jul 2013 10:51:34 -0400

Source: bitcoin
Severity: serious

The bitcoin network requires on strict adherence to consensus between nodes.
Small changes to underlying libraries, even justified security changes,
threaten to break consensus and could possible cause accidental forks.

For example, it is possible for bug fix in libleveldb to cause a fork in the
network if existing nodes expect buggy behaviour.

Therefore, bitcoin upstream developers have strongly encouraged downstream
packagers to use the exact version of libleveldb included with their source
code.  However, upstream does not backport or support previously released
versions of bitcoind/bitcoin-qt.

For example: if we release Debian Jessie with version 0.8 of bitcoin, and a
security bug is found in that version and fixed upstream, the fix may be based
on top of version 0.10 and unable to be ported to 0.8. Upstream will, in that
case, release version 0.10 and not backport the fix to 0.8. This is especially
tricky now that Debian is using the bitcoin packaged version of leveldb.

Because of the sensitivity of this situation (lots of money can be lost), I
believe we should block migration to testing until either upstream supports
stable releases or we have a volunteer that works closely enough with upstream
code (an upstream developer) that is will to backport security and network-
related fixes.


There has been some work on multibit and electrum packages in Debian, these may
be better choices for wallets. If we keep bitcoin in unstable, we'll be able to
update as needed and users will understand that these packages are not stable
and will need to be updated often.



-- System Information:
Debian Release: wheezy/sid
  APT prefers raring-updates
  APT policy: (500, 'raring-updates'), (500, 'raring-security'), (500, 'raring-proposed'), (500, 'raring'), (100, 'raring-backports')
Architecture: i386 (i686)

Kernel: Linux 3.8.0-27-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Message #12 received at 718272@bugs.debian.org (full text, mbox, reply):

From: "Luke-Jr" <luke@dashjr.org>

To: 718272@bugs.debian.org

Subject: backport branches are available

Date: Wed, 4 Sep 2013 15:59:50 +0000

This isn't correct. We do support backported/stable versions in a separate git 
repository:
	https://gitorious.org/bitcoin/bitcoind-stable/

Debian is welcome to choose a branch and I will do what I can to ensure it 
receives long-term support. I would recommend using the latest release 
(currently 0.8.4) if possible.

Message #17 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Scott Howard <showard314@gmail.com>

To: Luke-Jr <luke@dashjr.org>, 718272@bugs.debian.org

Subject: Re: [Pkg-bitcoin-devel] Bug#718272: backport branches are available

Date: Wed, 4 Sep 2013 12:58:58 -0400

On Wed, Sep 4, 2013 at 11:59 AM, Luke-Jr <luke@dashjr.org> wrote:
> This isn't correct. We do support backported/stable versions in a separate git
> repository:
>         https://gitorious.org/bitcoin/bitcoind-stable/
>
> Debian is welcome to choose a branch and I will do what I can to ensure it
> receives long-term support. I would recommend using the latest release
> (currently 0.8.4) if possible.

Thanks - I haven't seen that documented anywhere and wasn't aware of
it. That's a great service to provide.

How are those updated? It appears whenever there is a current-version
micro-release, those commits are backported to the stable branches.
Are only security and network related commits backported?
Is there a stable micro-release when those are backported, or is this
something that is more of a rolling stable branch.

Message #22 received at 718272@bugs.debian.org (full text, mbox, reply):

From: "Luke-Jr" <luke@dashjr.org>

To: Scott Howard <showard314@gmail.com>

Cc: 718272@bugs.debian.org

Subject: Re: [Pkg-bitcoin-devel] Bug#718272: backport branches are available

Date: Wed, 4 Sep 2013 17:07:32 +0000

On Wednesday, September 04, 2013 4:58:58 PM Scott Howard wrote:
> How are those updated? It appears whenever there is a current-version
> micro-release, those commits are backported to the stable branches.

I have a lot of different projects, and tend to cycle through them. Outside of 
that routine, I try to get stable updated and released only after master has 
released a final versions, so as to avoid taking away from testing of those 
release candidates.

> Are only security and network related commits backported?

I've been backporting fixes for bugs that affect the older versions (not 
necessarily only security-related, and also not including some more 
complicated but relatively unimportant fixes that may create new bugs), 
mandatory network changes (only), and translation updates (when possible).

> Is there a stable micro-release when those are backported, or is this
> something that is more of a rolling stable branch.

When there are security fixes or network changes, I bump the version number in 
git. There have been releases in the past, but due to lack of interest I've 
been more inclined to maintain them as a simple rolling branch lately. It's 
simple enough to add tags, however, so I'll probably keep doing that at 
logical commits.

Message #27 received at 718272@bugs.debian.org (full text, mbox, reply):

From: "Luke-Jr" <luke@dashjr.org>

To: 718272@bugs.debian.org

Subject: backport policy

Date: Wed, 4 Sep 2013 17:09:32 +0000

Also, note the backport branches have a policy of only including fixes which 
have been first merged to the master branch.

Message #32 received at 718272@bugs.debian.org (full text, mbox, reply):

From: mdt <mdt@cryptolab.net>

To: Debian Bug Tracking System <718272@bugs.debian.org>

Subject: Severity: serious - need to be changed

Date: Fri, 13 Dec 2013 08:08:19 +0100

Package: bitcoin
Severity: normal

The severity of this bug can be changed to allow migration to testing?

Message #37 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Scott Howard <showard314@gmail.com>

To: mdt <mdt@cryptolab.net>, 718272@bugs.debian.org

Subject: Bitcoin still not ready for stable release in Debian

Date: Fri, 13 Dec 2013 12:36:51 -0500

Below is my opinion, and is open for debate:

Although there are mechanisms for supporting security updates in
stable debian releases, and luke-jr's work of porting fixes is great
and exactly what is needed, updates to network protocols would not
classify as a security update and would only be available via
backports.d.o.

"Mandatory" network updates from upstream don't have a propagation
system through stable Debian releases, therefore it should not be in a
stable release.

Ubuntu has just removed the bitcoin package in favor of the upstream
"official" PPA. This package, as it is an unstable-only package, has a
similar function as a PPA at this point. Users can apt-pin to it and
stay up-to-date via regular updates.

As bitcoin evolves, and network protocols becomes standardized, we can
revisit whether this would be viable for stable release.

Message #42 received at 718272@bugs.debian.org (full text, mbox, reply):

From: "Luke-Jr" <luke@dashjr.org>

To: 718272@bugs.debian.org

Subject: Re: Bitcoin still not ready for stable release in Debian

Date: Sat, 14 Dec 2013 05:39:55 +0000

I agree with Scott's assessment, although I would note that Debian *does* have 
a suite that addresses the needs of Bitcoin: stable-updates. Mandatory 
protocol rule changes would seem to fall within the "broken by the flow of 
time" category. Thoughts?

Message #47 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Scott Howard <showard314@gmail.com>

To: Luke-Jr <luke@dashjr.org>, 718272@bugs.debian.org

Subject: Re: [Pkg-bitcoin-devel] Bug#718272: Bitcoin still not ready for stable release in Debian

Date: Sun, 15 Dec 2013 11:41:16 -0500

On Sat, Dec 14, 2013 at 12:39 AM, Luke-Jr <luke@dashjr.org> wrote:
> I agree with Scott's assessment, although I would note that Debian *does* have
> a suite that addresses the needs of Bitcoin: stable-updates. Mandatory
> protocol rule changes would seem to fall within the "broken by the flow of
> time" category. Thoughts?

I think this is the way to go once bitcoin version "1.0" (or the
equivalent) is released. It requires users to enable the
stable-updates repository, but we can put a note in the description
with a hint to do that. It may be confusing for some users to get a
message (or see a post on a forum) that says, "You MUST upgrade to
version 1.6!" then wonder why Debian is distributing version 1.5, even
if it is a patched version 1.5.

Ideally, once it is stable enough for distribution, I'd like to see
someone from upstream (Matt Corallo?) take control of the
bitcoind/bitcoin-qt packages. DDs on the packaging team can sponsor
uploads and make sure things are done in a policy compliant way.

Message #52 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Dmitry Smirnov <onlyjob@debian.org>

To: pkg-bitcoin-devel@lists.alioth.debian.org, Scott Howard <showard314@gmail.com>, 718272@bugs.debian.org

Cc: "Luke-Jr" <luke@dashjr.org>

Subject: Re: [Pkg-bitcoin-devel] Bug#718272: Bug#718272: Bitcoin still not ready for stable release in Debian

Date: Wed, 18 Dec 2013 10:16:53 +1100

Hi Scott,

For your information I have a case that you might find interesting:

Zabbix did not meet release criteria and was removed from "testing"
just before release of Wheezy. Ever since yours truly was maintaining
it in wheezy-backports.

Why wouldn't we seek backports manager(s)' permission to provide
"bitcoin" in wheezy-backports?

-- 
Cheers,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B

Message #55 received at 718272-submitter@bugs.debian.org (full text, mbox, reply):

From: Scott Howard <showard314@gmail.com>

To: Dmitry Smirnov <onlyjob@debian.org>, 718272-submitter@bugs.debian.org

Subject: Re: [Pkg-bitcoin-devel] Bug#718272: Bug#718272: Bug#718272: Bitcoin still not ready for stable release in Debian

Date: Fri, 20 Jun 2014 14:13:45 -0400

On Tue, Dec 17, 2013 at 6:16 PM, Dmitry Smirnov <onlyjob@debian.org> wrote:
> Hi Scott,
>
> For your information I have a case that you might find interesting:
>
> Zabbix did not meet release criteria and was removed from "testing"
> just before release of Wheezy. Ever since yours truly was maintaining
> it in wheezy-backports.
>
> Why wouldn't we seek backports manager(s)' permission to provide
> "bitcoin" in wheezy-backports?

Sorry for long delay, just saw this.

This sounds good., it will give us the control to prevent stable
release with the flexibility of constant updates. Users will have to
enable backports, and thus know and be willing to keep the package up
to date. I think it's crucial that we have several people working to
keep the package up to date in backports, since it will not be
automatic. There is more work, but I think this fits all the
requirements upstream wants (flexibility of updating) with the way
things work in Debian. We'd keep this bug open to prevent transition
to stable, but maintain the package in unstable and backports
directly.

If someone wants to work and backport and maintain bticoin in
backports, long-term, I think that's a good idea. It might be more
responsibility than I can take on at the moment, however.

~Scott

Message #60 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Chris Bainbridge <chris.bainbridge@gmail.com>

To: 718272@bugs.debian.org

Date: Wed, 25 Jun 2014 14:26:32 +0100

> For example: if we release Debian Jessie with version 0.8 of bitcoin, and a
> security bug is found in that version and fixed upstream, the fix may be based
> on top of version 0.10 and unable to be ported to 0.8.

A Debian package is allowed to bump versions for a security fix. Is
this any different to the Chromium situation? Chromium-35 is already
in wheezy despite only being released one month ago. Similar
reasoning; Chromium upstream do not support backported security fixes,
they just release a new version.

Message #65 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Chris Bainbridge <chris.bainbridge@gmail.com>

To: 718272@bugs.debian.org

Date: Wed, 25 Jun 2014 18:18:58 +0100

Luke-Jr wrote:
> I agree with Scott's assessment, although I would note that Debian *does* have
> a suite that addresses the needs of Bitcoin: stable-updates. Mandatory
> protocol rule changes would seem to fall within the "broken by the flow of
> time" category. Thoughts?

I agree.

Scott Howard wrote:
> I think this is the way to go once bitcoin version "1.0" (or the
> equivalent) is released. It requires users to enable the
> stable-updates repository

This is not necessary as the debian-installer already enables
stable-updates by default.

> we should block migration to testing until either upstream supports
> stable releases or we have a volunteer that works closely enough with upstream
> code (an upstream developer) that is will to backport security and network-
> related fixes.

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.

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.

Message #70 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Scott Howard <showard314@gmail.com>

To: Chris Bainbridge <chris.bainbridge@gmail.com>, 718272@bugs.debian.org

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

Date: Wed, 25 Jun 2014 14:50:20 -0400

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@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.)

Message #75 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Scott Howard <showard314@gmail.com>

To: Chris Bainbridge <chris.bainbridge@gmail.com>, 718272@bugs.debian.org

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

Date: Wed, 25 Jun 2014 14:53:57 -0400

On Wed, Jun 25, 2014 at 2:50 PM, Scott Howard <showard314@gmail.com> wrote:
> Thank you, Chris. I think you articulated the situation well and the options.

one more thing: debian is discussion dropping libdb (the db the node,
but not the wallet, uses). That might force our hand as well: either
ship and support upstream's included libdb or drop the node and just
ship the wallet. libdb long-term security maintenance might be
challenging.

Message #80 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Luke Dashjr <luke@dashjr.org>

To: 718272@bugs.debian.org, Scott Howard <showard314@gmail.com>

Cc: Chris Bainbridge <chris.bainbridge@gmail.com>

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

Date: Wed, 25 Jun 2014 19:11:45 +0000

On Wednesday, June 25, 2014 6:53:57 PM Scott Howard wrote:
> On Wed, Jun 25, 2014 at 2:50 PM, Scott Howard <showard314@gmail.com> wrote:
> > Thank you, Chris. I think you articulated the situation well and the
> > options.
> 
> one more thing: debian is discussion dropping libdb (the db the node,
> but not the wallet, uses). That might force our hand as well: either
> ship and support upstream's included libdb or drop the node and just
> ship the wallet. libdb long-term security maintenance might be
> challenging.

You mean LevelDB? Debian should use the embedded copy regardless, due to the 
consensus-critical requirements.

It is not possible to build BCCore wallets without the node at this time.

Message #85 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Scott Howard <showard314@gmail.com>

To: Luke Dashjr <luke@dashjr.org>

Cc: 718272@bugs.debian.org, Chris Bainbridge <chris.bainbridge@gmail.com>

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

Date: Wed, 25 Jun 2014 15:55:33 -0400

On Wed, Jun 25, 2014 at 3:11 PM, Luke Dashjr <luke@dashjr.org> wrote:
> On Wednesday, June 25, 2014 6:53:57 PM Scott Howard wrote:
>> On Wed, Jun 25, 2014 at 2:50 PM, Scott Howard <showard314@gmail.com> wrote:
>> > Thank you, Chris. I think you articulated the situation well and the
>> > options.
>>
>> one more thing: debian is discussion dropping libdb (the db the node,
>> but not the wallet, uses). That might force our hand as well: either
>> ship and support upstream's included libdb or drop the node and just
>> ship the wallet. libdb long-term security maintenance might be
>> challenging.
>
> You mean LevelDB? Debian should use the embedded copy regardless, due to the
> consensus-critical requirements.
>
> It is not possible to build BCCore wallets without the node at this time.

You're right, brain slip: Debian is using the embedded leveldb
distributed by bitcoin for the blockchain and have for several months.

Berkeley DB is used for wallets. Berkeley DB (libdb) is what is going
to be dropped since they were re-licensed AGPL3 (amongst other
reasons). Debian has been using Berkeley DB for a while in bitcoin
(long before I got involved) with the --with-incompatible-libdb
configure flag, so this may cause a problem since BDB has notorious
compatibility issues between versions.

Message #90 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Micha Bailey <michabailey@gmail.com>

To: "718272@bugs.debian.org" <718272@bugs.debian.org>, Scott Howard <showard314@gmail.com>

Subject: Re: BDB

Date: Thu, 26 Jun 2014 08:26:59 +0300

[Message part 1 (text/plain, inline)]

Scott said:
one more thing: debian is discussion dropping libdb (the db the node,
but not the wallet, uses). That might force our hand as well: either
ship and support upstream's included libdb or drop the node and just
ship the wallet. libdb long-term security maintenance might be
challenging.



------------------------------

Actually, it's the other way around. Since version 0.8, BDB is *only* used
for the wallet, not anything else. IIRC it was also used by the node
component until 0.8, where it was replaced with LevelDB. In fact, if you
configure with --disable-wallet, BDB isn't needed at all. But yes, as
someone mentioned, BDB is not backwards compatible. If you've been shipping
with any version newer than 4.8 (which is not recommended and throws a a
warning when configuring for this reason) you need to take responsibility
for ensuring that that version or newer remains available.

[Message part 2 (text/html, inline)]

Message #97 received at 718272-done@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: 718272-done@bugs.debian.org

Subject: Re: Bitcoin still not ready for stable release in Debian

Date: Fri, 03 Nov 2017 10:10:37 +0100

I believe Bitcoin is now stable enough for stable release.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Message #102 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Luke Dashjr <luke@dashjr.org>

To: 718272@bugs.debian.org

Subject: Re: Bitcoin still not ready for stable release in Debian

Date: Fri, 3 Nov 2017 10:25:23 +0000

On Friday 03 November 2017 9:10:37 AM you wrote:
> I believe Bitcoin is now stable enough for stable release.

Things have only gotten less stable upstream since 2013...

What is the plan for getting security and protocol change updates backported 
to Debian stable?

Luke

Message #107 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <jonas@jones.dk>

To: 718272@bugs.debian.org, Luke Dashjr <luke@dashjr.org>

Subject: Re: [Pkg-bitcoin-devel] Bug#718272: Bitcoin still not ready for stable release in Debian

Date: Fri, 03 Nov 2017 14:27:24 +0100

Quoting Luke Dashjr (2017-11-03 11:25:23)
> On Friday 03 November 2017 9:10:37 AM you wrote:
>> I believe Bitcoin is now stable enough for stable release.
>
> Things have only gotten less stable upstream since 2013...

Please provide references supporting that.


> What is the plan for getting security and protocol change updates 
> backported to Debian stable?

Debian standard procedures for updating stable packages.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Message #112 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Luke Dashjr <luke@dashjr.org>

To: Jonas Smedegaard <jonas@jones.dk>

Cc: 718272@bugs.debian.org

Subject: Re: [Pkg-bitcoin-devel] Bug#718272: Bitcoin still not ready for stable release in Debian

Date: Fri, 3 Nov 2017 20:31:33 +0000

On Friday 03 November 2017 1:27:24 PM Jonas Smedegaard wrote:
> Quoting Luke Dashjr (2017-11-03 11:25:23)
> 
> > On Friday 03 November 2017 9:10:37 AM you wrote:
> >> I believe Bitcoin is now stable enough for stable release.
> > 
> > Things have only gotten less stable upstream since 2013...
> 
> Please provide references supporting that.

Back in 2013 (0.8.0 release), I was still supporting stable versions 0.4.x 
(originally released in 2011), 0.5.x (OR 2011), 0.6.x (OR 2012), and
0.7.x (OR 2012). No such long-term support is provided anymore - we only 
maintain the most recent 2 versions (with a 6 month release schedule), which 
gives approximately 1 year of support to any particular release.

Furthermore, with increasing miner hostilities to Bitcoin in the last few 
years, the importance of timely deployment of softforks is even more crucial 
to security than previously. This past August, there was a fear that miners 
would violate the new softfork rules, causing a chainsplit. If that had 
occurred, obsolete nodes would have been vulnerable.

> > What is the plan for getting security and protocol change updates
> > backported to Debian stable?
> 
> Debian standard procedures for updating stable packages.

In my experience, that has been "never update, even when fixes are available" 
except for highly-visible security issues. :(

Luke

Message #117 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Anthony Towns <aj@erisian.com.au>

To: Luke Dashjr <luke@dashjr.org>

Cc: Jonas Smedegaard <jonas@jones.dk>, 718272@bugs.debian.org

Subject: Re: [Pkg-bitcoin-devel] Bug#718272: Bitcoin still not ready for stable release in Debian

Date: Sun, 5 Nov 2017 04:28:07 +1000

Hey Luke, Jonas,

On Fri, Nov 03, 2017 at 08:31:33PM +0000, Luke Dashjr wrote:
> > >> I believe Bitcoin is now stable enough for stable release.
> > > Things have only gotten less stable upstream since 2013...
> > Please provide references supporting that.

0.15 is certainly "stable" in the sense that it's a well-maintained
piece of software, but it's not stable in the sense that it should
be reliably used without changes over a period of years. For instance
0.15.1 is currently being prepared to work around p2p problems that are
expected within a couple of weeks.

> > > What is the plan for getting security and protocol change updates
> > > backported to Debian stable?
> > Debian standard procedures for updating stable packages.
> In my experience, that has been "never update, even when fixes are available" 
> except for highly-visible security issues. :(

Not sure if there's something more up to date, but

https://lists.debian.org/debian-devel-announce/2016/11/msg00009.html

says:

   * Fixes must be minimal and relevant and include a sufficiently
     detailed changelog entry

which seems like it generally precludes uploading new upstream releases
(0.14 to 0.15 at least, perhaps 0.15 to 0.15.1 would be fine). I don't
think upstream will generally be providing sufficiently "minimal and
relevant" backports to satisfy that rule...

AIUI, stable-updates is a subset of proposed-updates, so it's not easier
to get in there than regular updates to stable?

(If the release team are willing to accept new upstream releases into
stable or stable-updates, this seems like a good idea; it just doesn't
seem like they would be as far as I can see?)

Cheers,
aj

Message #124 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Vincas Dargis <vindrg@gmail.com>

To: 718272@bugs.debian.org

Subject: Re: [Pkg-bitcoin-devel] Bug#718272: Bitcoin still not ready for stable release in Debian

Date: Tue, 19 Jun 2018 19:49:02 +0300

Any news after half a year?

Why it's marked "fixed-upstream"?

Message #129 received at 718272-done@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <jonas@jones.dk>

To: 718272-done@bugs.debian.org

Cc: Vincas Dargis <vindrg@gmail.com>

Subject: Re: Bug#718272: [Pkg-bitcoin-devel] Bug#718272: Bitcoin still not ready for stable release in Debian

Date: Tue, 19 Jun 2018 19:21:09 +0200

[Message part 1 (text/plain, inline)]

Hi Vincas,

Quoting Vincas Dargis (2018-06-19 18:49:02)
> Any news after half a year?

News that Debian stable no longer means stable? No.

News that Bitcoin protocol has stabilized? No.

But let's change approach: Treat it as releasable, and leave it to 
Debian release managers to kick it out during freeze if by then deemed 
too unstable for stable.


> Why it's marked "fixed-upstream"?

Because someone flagged it as such. Not sure why. Not important.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #140 received at 718272-done@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <jonas@jones.dk>

To: 718272-done@bugs.debian.org

Cc: Moritz Muehlenhoff <jmm@debian.org>

Subject: Re: Processed: reopening 718272

Date: Thu, 07 Jan 2021 14:51:50 +0100

[Message part 1 (text/plain, inline)]

Quoting Debian Bug Tracking System (2020-12-27 19:33:02)
> Processing commands for control@bugs.debian.org:
> 
> > reopen 718272
> Bug #718272 {Done: Jonas Smedegaard <jonas@jones.dk>} [src:bitcoin] upstream does not support stable releases (block migration to testing)
> Bug reopened
> Ignoring request to alter fixed versions of bug #718272 to the same values previously set
> > thanks
> Stopping processing here.
> 
> Please contact me if you need assistance.

I consider Bitcoin suitable for release with stable Debian.

If seciurity team or others disagree with that, then please elaborate on 
your concerns.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #145 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Luke Dashjr <luke@dashjr.org>

To: Jonas Smedegaard <jonas@jones.dk>

Cc: 718272@bugs.debian.org, Moritz Muehlenhoff <jmm@debian.org>

Subject: Re: Processed: reopening 718272

Date: Thu, 7 Jan 2021 17:26:43 +0000

We (upstream) already elaborated many years ago, copied here:

http://luke.dashjr.org/tmp/code/20130723-linux-distribution-packaging-and-bitcoin.md.asc

At a minimum, to be safe, Debian would need to:

1) Either:
1a) Build with the bundled LevelDB statically linked.
1b) Guarantee LevelDB package remains consensus-compatible, including NOT
    fixing any bugs without a proper consensus-compatibility audit.
2) Backport (at least) security fixes for Debian's security support period.
   Upstream, we generally only maintain releases for a year or so at most.

Luke


On Thursday 07 January 2021 13:51:50 Jonas Smedegaard wrote:
> Quoting Debian Bug Tracking System (2020-12-27 19:33:02)
>
> > Processing commands for control@bugs.debian.org:
> > > reopen 718272
> >
> > Bug #718272 {Done: Jonas Smedegaard <jonas@jones.dk>} [src:bitcoin]
> > upstream does not support stable releases (block migration to testing)
> > Bug reopened
> > Ignoring request to alter fixed versions of bug #718272 to the same
> > values previously set
> >
> > > thanks
> >
> > Stopping processing here.
> >
> > Please contact me if you need assistance.
>
> I consider Bitcoin suitable for release with stable Debian.
>
> If seciurity team or others disagree with that, then please elaborate on
> your concerns.
>
>
>  - Jonas

Message #150 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <jonas@jones.dk>

To: Luke Dashjr <luke@dashjr.org>

Cc: 718272@bugs.debian.org, Moritz Muehlenhoff <jmm@debian.org>

Subject: Re: Processed: reopening 718272

Date: Thu, 07 Jan 2021 19:24:39 +0100

[Message part 1 (text/plain, inline)]

Quoting Luke Dashjr (2021-01-07 18:26:43)
> We (upstream) already elaborated many years ago, copied here:
> 
> http://luke.dashjr.org/tmp/code/20130723-linux-distribution-packaging-and-bitcoin.md.asc
> 
> At a minimum, to be safe, Debian would need to:
> 
> 1) Either:
> 1a) Build with the bundled LevelDB statically linked.
> 1b) Guarantee LevelDB package remains consensus-compatible, including NOT
>     fixing any bugs without a proper consensus-compatibility audit.
> 2) Backport (at least) security fixes for Debian's security support period.
>    Upstream, we generally only maintain releases for a year or so at most.

Thanks for your input on upstream position on this matter, Luke, and in 
particular this condensed summary.  It is helpful for Debian to make its 
decision.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #155 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Luke Dashjr <luke@dashjr.org>

To: 718272@bugs.debian.org, Jonas Smedegaard <jonas@jones.dk>

Cc: Moritz Muehlenhoff <jmm@debian.org>

Subject: Re: Bug#718272: Processed: reopening 718272

Date: Thu, 7 Jan 2021 20:21:57 +0000

FWIW, I brought this up at our weekly developer meeting, and there was also 
another concern about apt upgrades across softforks: It could be problematic 
to not deploy a softfork, and problematic to deploy one without the user's 
consent.

I think I recall Debian has a way for packages to interactively prompt the 
user during upgrade. Maybe if softforks were turned into a runtime option, 
that could resolve that issue. What do you think?

For reference, the meeting log:

https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-01-07-19.00.moin.txt

Luke


On Thursday 07 January 2021 18:24:39 Jonas Smedegaard wrote:
> Quoting Luke Dashjr (2021-01-07 18:26:43)
>
> > We (upstream) already elaborated many years ago, copied here:
> >
> > http://luke.dashjr.org/tmp/code/20130723-linux-distribution-packaging-and
> >-bitcoin.md.asc
> >
> > At a minimum, to be safe, Debian would need to:
> >
> > 1) Either:
> > 1a) Build with the bundled LevelDB statically linked.
> > 1b) Guarantee LevelDB package remains consensus-compatible, including NOT
> >     fixing any bugs without a proper consensus-compatibility audit.
> > 2) Backport (at least) security fixes for Debian's security support
> > period. Upstream, we generally only maintain releases for a year or so at
> > most.
>
> Thanks for your input on upstream position on this matter, Luke, and in
> particular this condensed summary.  It is helpful for Debian to make its
> decision.
>
>
>  - Jonas

Message #160 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Moritz Mühlenhoff <jmm@inutil.org>

To: 718272@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: Processed: reopening 718272

Date: Wed, 27 Jan 2021 20:03:40 +0100

reopen 718272
thx

Reopening. The reasons are listed in the bug log and were given by
the upstream developers. If you want to provide it to bullseye
stable users, get it into fasttrack.debian.net.

Cheers,
        Moritz

Message #167 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <jonas@jones.dk>

To: 718272@bugs.debian.org, Moritz Mühlenhoff <jmm@inutil.org>

Cc: control@bugs.debian.org

Subject: Re: Bug#718272: Processed: reopening 718272

Date: Wed, 27 Jan 2021 20:51:00 +0100

[Message part 1 (text/plain, inline)]

close 718272
thanks

Quoting Moritz Mühlenhoff (2021-01-27 20:03:40)
> reopen 718272
> thx
> 
> Reopening. The reasons are listed in the bug log and were given by
> the upstream developers. If you want to provide it to bullseye
> stable users, get it into fasttrack.debian.net.

Thanks for sharing your interpretation of the state of this bug, and for 
suggesting how to maintain this package.

I disagree with both the interpretation and the suggestion, however.
Closing, reflecting my views on this bug as package maintainer.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #176 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: debian-release@lists.debian.org

Cc: 718272@bugs.debian.org

Subject: why was bitcoin package removed from testing?

Date: Sat, 30 Jan 2021 11:50:42 +0100

[Message part 1 (text/plain, inline)]

The bitcoin package was removed from testing some hours ago - 
https://tracker.debian.org/news/1225530/bitcoin-removed-from-testing/ 
references bug#718272 but that bug is closed.

If the removal accidental (e.g. cause by bug closure flip-flop, then 
please consider correcting that by fast-trackign a re-acceptance.

If the release team consider bitcoin unacceptable for Debian stable, 
then please elaborate why.

Please don't just point to the bug log (as security team did): This bug 
log contains a variety of claims, and it is quite helpful that we are 
transparent about _which_ reasons Debian consider release-critical.


Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #181 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Paul Gevers <elbrus@debian.org>

To: Jonas Smedegaard <dr@jones.dk>, debian-release@lists.debian.org

Cc: 718272@bugs.debian.org

Subject: Re: why was bitcoin package removed from testing?

Date: Sat, 30 Jan 2021 19:49:31 +0100

[Message part 1 (text/plain, inline)]

Hi Jonas,

On 30-01-2021 11:50, Jonas Smedegaard wrote:
> If the release team consider bitcoin unacceptable for Debian stable, 
> then please elaborate why.

We consider it unacceptable for Debian bullseye because the security
team doesn't want to support it.

Paul

[OpenPGP_signature (application/pgp-signature, attachment)]

Message #186 received at 718272@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk>

To: Paul Gevers <elbrus@debian.org>, debian-release@lists.debian.org

Cc: 718272@bugs.debian.org

Subject: Re: why was bitcoin package removed from testing?

Date: Sat, 30 Jan 2021 21:04:24 +0100

[Message part 1 (text/plain, inline)]

Quoting Paul Gevers (2021-01-30 19:49:31)
> On 30-01-2021 11:50, Jonas Smedegaard wrote:
> > If the release team consider bitcoin unacceptable for Debian stable, 
> > then please elaborate why.
> 
> We consider it unacceptable for Debian bullseye because the security 
> team doesn't want to support it.

Thanks for the clarification.

Now, if only the security team would clarify... :-/


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #191 received at 718272@bugs.debian.org (full text, mbox, reply):

From: se@myfairpoint.net

To: Recipients <se@myfairpoint.net>

Subject: Take Advantage On Bitcoin NOW !

Date: Thu, 04 Feb 2021 13:23:32 +0100

What are you waiting for ? Get 200% Return On Investment ( ROI ) within 14 -31 days GUARANTEED. Bitcoin is on the rise, Take advantage NOW ! Kindly reach out for more information.

Global BTC Base
Promotion Team

Message #192 received at 718272-done@bugs.debian.org (full text, mbox, reply):

From: se@myfairpoint.net

To: Recipients <se@myfairpoint.net>

Subject: Take Advantage On Bitcoin NOW !

Date: Thu, 04 Feb 2021 13:23:32 +0100

What are you waiting for ? Get 200% Return On Investment ( ROI ) within 14 -31 days GUARANTEED. Bitcoin is on the rise, Take advantage NOW ! Kindly reach out for more information.

Global BTC Base
Promotion Team

Message #195 received at 718272-submitter@bugs.debian.org (full text, mbox, reply):

From: se@myfairpoint.net

To: Recipients <se@myfairpoint.net>

Subject: Take Advantage On Bitcoin NOW !

Date: Thu, 04 Feb 2021 13:23:32 +0100

What are you waiting for ? Get 200% Return On Investment ( ROI ) within 14 -31 days GUARANTEED. Bitcoin is on the rise, Take advantage NOW ! Kindly reach out for more information.

Global BTC Base
Promotion Team

Send a report that this bug log contains spam.