Meta: Packaging Bitcoin Core as vanilla system package

MarcoFalke commented at 3:35 pm on November 1, 2019: member

Depending on the user, we offer a wide range of ways to get Bitcoin Core:

Self-compilation (using system packages and optionally ./depends)
Static gitian binaries (using ./depends and Ubuntu system packages). They are signed for macOS and Windows, and reproducible to some extent.
https://snapcraft.io/bitcoin-core (using the gitian binaries)
https://flathub.org/apps/details/org.bitcoincore.bitcoin-qt (using the gitian binaries)

However, there is no way to get Bitcoin Core as a vanilla system package, where it could serve as a dependency for other packages. Currently the user needs to install and maintain the dependencies manually. This might not be ideal for everyone and we should make it easy to use Bitcoin Core as a non-sysadmin.

I think in the past, a vanilla system package has been rejected because it would make it hard to apply security fixes (some distros ship year-old software, https://lists.debian.org/debian-backports/2013/12/msg00062.html). Also, those package would generally not be deterministically compiled, thus not easily auditable.

However, now that Debian and Ubuntu are capable of shipping updated software (e.g. recent versions of docker or firefox), which receives security and other bugfixes, it seems time to maybe reconsider this decision.

And given that users of an operating system already need to trust the maintainers of their vanilla system package manager, it doesn’t seem to get worse when Bitcoin Core is offered through the same. I guess, if Bitcoin Core were offered as a new package and it used a deterministic build (like debians deterministic build effort) or bootstrapable build (like guix) it would be really nice to have, but not a requirement.

I am opening this issue mostly to see what everyone else thinks about this.

fanquake added the label Brainstorming on Nov 1, 2019

fanquake added the label Build system on Nov 1, 2019

laanwj commented at 10:54 am on November 2, 2019: member

However, now that Debian and Ubuntu are capable of shipping updated software (e.g. recent versions of docker or firefox), which receives security and other bugfixes, it seems time to maybe reconsider this decision.

So are they willing make a similar exception for bitcoin core? I think that’s what matter here foremost. If not, this is hopeless, if they are, I don’t think it’s much of a problem. At least Gentoo already has bitcoin core as a distro package.

elichai commented at 1:58 pm on November 14, 2019: contributor

I’ll hijack the conversation to also ask do we know who currently maintains the bitcoin packages in Arch Linux? (both in official-community and in AUR)

https://www.archlinux.org/packages/community/x86_64/bitcoin-qt/ https://aur.archlinux.org/packages/bitcoin-git/ https://aur.archlinux.org/packages/bitcoin-core/ https://aur.archlinux.org/packages/bitcoin-core-git/

Anyway I think if distros already have bitcoin core packages we’re better off maintaining them properly and making sure they’re not vulnerabilities stealing private keys.

MarcoFalke commented at 2:47 pm on November 14, 2019: member

Anyway I think if distros already have bitcoin core packages we’re better off maintaining them properly and making sure they’re not vulnerabilities stealing private keys.

I don’t think we have the resources to maintain them ourselves. Us not providing them, will make people provide “community versions” of Bitcoin Core, which could be assumed to be of lower quality than a vanilla package. Also, I don’t think we can protect against people installing packages that steal their keys. I think that this is the responsibility of the package manager maintainers of that distro. Again, I assume that vanilla packages are less likely to steal your keys. And if any vanilla package was to steal your keys, there is nothing we could do about that anyway.

MarcoFalke commented at 7:51 pm on January 2, 2020: member

This has been discussed in today’s IRC meeting: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-01-02-19.00.log.html#l-51

Some TLDR (for myself):

The current debian package uses system leveldb, instead of our subtree. This was considered a blocker.
The debian patch policy was considered too strict. (1) not allowing even minor fixes to stable versions. And (2), not providing an upgrade path to newer versions of Bitcoin Core and the risk of new users running outdated versions of Bitcoin Core. No conclusion was reached on (1). No conclusion was reached on (2), but I mentioned that “backports” could be used to release newer versions of Bitcoin Core in older releases of debian.
The PPA was considered superior to a vanilla debian package, especially in light of “backports” pacakges. I mentioned that it was lacking a maintainer who is willing to spend time on our current bitcoin/bitcoin PPA.

hebasto commented at 10:45 am on January 12, 2020: member

Depending on the user, we offer a wide range of ways to get Bitcoin Core: …

https://flathub.org/apps/details/org.bitcoincore.bitcoin-qt (using the gitian binaries)

Are any reasons that flathab link is not provided by https://bitcoincore.org/en/download/:

?

MarcoFalke closed this on Jan 17, 2022

DrahtBot locked this on Jan 17, 2023

Meta: Packaging Bitcoin Core as vanilla system package #17343