[Pkg-bitcoin-devel] Armory in Stable?

[Scott Howard]

Hi Joseph,

Quick responses:

On Wed, Oct 29, 2014 at 1:14 PM, Joseph Bisch <joseph.bisch at gmail.com> wrote:
> Hi,
>
> I originally thought that Armory would be okay in stable, because it
> is bitcoind that does all the network communication. So no network
> consensus issues should arise from bugs in Armory. But Charles from
> upstream raised the following concerns in an email:
>
> "Understood. I'm a little bit worried that if we release a new version of
> Armory that fixes compatilbity with Qt, or if bitcoin core updates, Debian
> users won't get the new version. I think it's important that Debian not get
> "security patches", but rather our most up-to-date release as part of the
> debian-updates or debian-security repositories. Is this possible?"
>
> Regarding the stable-updates method, my understanding is that a line
> has to be added to sources.list to enable that. So it is not a viable
> option.

stable-updates is enabled by default. I think that may be a good option for you:

to get into stable-updates, the update must be one of the following cases [1]:
1) The update is urgent and not of a security nature. Security updates
will continue to be pushed through the security archive. Examples
include packages broken by the flow of time (c.f. spamassassin and the
year 2010 problem) and fixes for bugs introduced by point releases.
2) The package in question is a data package and the data must be
updated in a timely manner (e.g. tzdata).
3) Fixes to leaf packages that were broken by external changes (e.g.
video downloading tools and tor).
4) Packages that need to be current to be useful (e.g. clamav).

I think armory updates would fit 1, 3, and 4.

[1] https://www.debian.org/News/2011/20110215

> I'm not able to provide the same level of testing that Armory
> Techologies Inc is able to provide, so I'd rather release new versions
> instead of backporting patches anyway.
>
> I asked yesterday in #debian-security about releasing new versions for
> security reasons (I figure if out of date versions can potentially
> result in lost bitcoins, then that is a security issue). The only
> response I got was that new versions have been released in a few
> cases. I did not get any response as to whether or not Armory's
> specific case would allow for a new version to be released. Is there a
> better method of communication with the security team for non-urgent
> matters like this?

This is why my personal opinion has been to hold back bitcoin from
testing (for now). We don't want anyone losing money because we can't
update versions fast enough, and even worse we don't want to risk
damaging the greater bitcoin network by providing out-of-date client
software. I think stable updates (which are enabled by default) is
good for fixing broken features/usability in stable packages and
backports (which are not enabled by default) is good for providing new
versions and features to stable.

You may want to communicate with the stable release managers about how
it would work for you:
https://wiki.debian.org/Teams/ReleaseTeam

> I imagine this came up when bitcoin-qt/bitcoind were being packaged. I
> know ultimately the decision was to block the migration to testing,
> but was there any discussion with the security team?

There was, briefly, and it came to a similar conclusion: targeted
patches fixing specific security bugs could be accepted through
security, but network changes/upgrades that are required for consensus
should go through stable-updates. stable-updates, however, can take
months to be approved, tested, and included in a point release.
Backports are an option too for new versions and features, but they
are not enabled by default.

security: good for security bugs
stable-updates: to fix features broken or out of date due to things
external to debian (i.e., bitcoin network or protocol changes)
backports: new versions of software

> How should I proceed? Just block the migration or pursue getting a
> more specific answer from the security team? I want to decide on a
> course of action before the migration to testing on November 4, so I
> can block the migration if necessary.

I think it's ok to let it migrate, you can always remove it from
testing later if you learn maintenance will be problematic (which I
don't necessarily see it being a problem). I'd discuss your situation
with the release team, since they are the keepers of the point
releases and stable-updates.

~Scott