Distribute via flatpak

A6GibKm commented at 9:53 pm on August 5, 2019: none

Provide a flatpak for bitcoin-qt

This would provide linux users with a binary compiled from source that is distro-agnostic, this could be distributed via https://flathub.org/home.

I made a flatpak manifesto that builds Bitcoin Core’s binaries: https://github.com/A6GibKm/flathub/tree/org.bitcoin.bitcoin-qt. This is passes all criteria in https://github.com/flathub/flathub/blob/master/CONTRIBUTING.md with the exception that it gets a .patch for clang.

MarcoFalke commented at 10:06 pm on August 5, 2019: member

This is already available via https://snapcraft.io/bitcoin-core

MarcoFalke commented at 10:10 pm on August 5, 2019: member

Thanks for working on flatpak support. Though, it seems that flatpak builds are non-deterministic and your flatpak spec is building from the git source. Thus, user can not check the distributed binary for correctness. I’d prefer if the flatpak spec directly used the deterministic release binaries from our website.

See e.g. here: https://github.com/bitcoin-core/packaging/blob/40f8a131003bb1346a45d78a054db9c5b4b4f0e7/snap/snapcraft.yaml#L40

A6GibKm commented at 10:14 pm on August 5, 2019: none

It is builded from the specific commit AND tag of the releases, the only things that are non-deterministic are the flags that I am using/not using. When you say correctness you mean the actual hash of the binary? I could build a flatpak using the tar directly.

fanquake added the label Linux/Unix on Aug 5, 2019

emilengler commented at 3:00 am on August 6, 2019: contributor

I don’t see the need for flatpak and snap support. The binaries are static.

laanwj commented at 6:30 am on August 6, 2019: member

I don’t see the need for flatpak and snap support. The binaries are static.

Not entirely static. Most of the dependency libraries are linked statically, but not the C library. libc is linked dynamically. Because not doing so is risky because of, among other things, DNS lookup issues.

This means that they won’t run on systems with another libc such as musl libc. There have also been more subtle issues with libc compiled with different security flags, missing __stack_chk_fail for example (can’t find the specific issue).

Also if with flatpak, it’s possible to link Qt dynamically which means the UI can do desktop integration, use the right theme, adapt to global settings (whether GNOME or KDE) and so on.

It also provides application sandboxing.

I like this idea but I have no idea what would be involved with ,say, integrating a flatpak build into gitian (or guix) build.

laanwj added the label Build system on Aug 6, 2019

emilengler commented at 6:52 am on August 6, 2019: contributor

I’m still not very attracted by the idea of flatpak sorry. Is the sandboxing really a big advantage? The big disadvantage is that using a custom datadir could not work out of the box and some regular users might have problems installing it, but I’m not 100% sure. I think AppImages would do the job better as they are more native like but I haven’t touched distributing software with flatpak or snap

sipa commented at 7:10 am on August 6, 2019: member

I don’t think it’s so much a question of whether we believe it’s the optimal way of distributing software or not. If people are going to build flatpak support (or whatever), we’re better off helping them do it right (e.g. using gitian/guix so they’re deterministic and comparable with official built binaries).

laanwj commented at 7:55 am on August 6, 2019: member

Is the sandboxing really a big advantage?

Yes, it is, though mostly for software which you don’t trust to get security right. Say, I’m very happy to sandbox signal-desktop to not be able to access files in my home directory, as it has had javascript-based escapes in the past that allowed grabbing arbitrary files. Maybe this is not as much an issue for bitcoin, as it’s usually the thing to be protected instead of the thing to be protected from.

emilengler commented at 8:23 am on August 6, 2019: contributor

Good point but most people store their blockchain probably on other devices (including me) because their system drive hasn’t too much space and they don’t want to prune. A sandboxed instance of Bitcoin Core wouldn’t allow access to /media/ I think. Snaps however have an option to launch with the --classic arg which allows the app full access

MarcoFalke commented at 12:54 pm on August 6, 2019: member

I could build a flatpak using the tar directly.

I think that is preferable, so that the hash of the binary is always the same (regardless of where or when it was compiled)

MarcoFalke commented at 12:57 pm on August 6, 2019: member

I like this idea but I have no idea what would be involved with ,say, integrating a flatpak build into gitian (or guix) build.

I don’t think this is necessary. A wget ... && sha256sum -c ... && gpg ... && tar -x ... should be sufficient. I know that some don’t like the gitian produced binaries because they were compiled on Ubuntu, but with guix that should change and I don’t see a reason to not just use the guix deterministic (and bootstrapable) binaries.

A6GibKm commented at 6:13 pm on August 6, 2019: none

A sandboxed instance of Bitcoin Core wouldn’t allow access to /media/ I think. Snaps however have an option to launch with the --classic arg which allows the app full access

Flatpak can be given access to a specific drive via override --filesystem=path.

I think that is preferable, so that the hash of the binary is always the same (regardless of where or when it was compiled)

I updated the manifesto https://github.com/A6GibKm/flathub/tree/org.bitcoin.bitcoin-qt to use the compiled binaries. Since it was pre compiled it can’t detect the correct theme for QT for some reason.

emilengler commented at 9:57 pm on August 6, 2019: contributor

@A6GibKm I think org.bitcoin.bitcoin-qt is a bad package name. I think you should go with org.bitcoincore.bitcoin-qt. Bitcoin Core and bitcoin.org are completely two different things (since 2014 IIRC).

A6GibKm commented at 11:44 pm on August 6, 2019: none

I agree to an extent, the .desktop file that was provided in this repo used this name.

emilengler commented at 3:40 am on August 7, 2019: contributor

I only found https://github.com/bitcoin/bitcoin/blob/edc2822b9dc90af25750fd17c17c248490051431/share/qt/Info.plist.in

There are several package identifiers like org.bitcoinfoundation or org.bitcoin

MarcoFalke commented at 11:44 am on August 7, 2019: member

I updated the manifesto https://github.com/A6GibKm/flathub/tree/org.bitcoin.bitcoin-qt to use the compiled binaries. Since it was pre compiled it can’t detect the correct theme for QT for some reason.

Thanks. Some notes.

The application id should probably be org.bitcoincore... or org.bitcoin-core... (c.f. our website https://bitcoincore.org/en/about/)
For the icon, you can also use svg (c.f. src/qt/res/src/bitcoin.svg)?
Can you run the tests before installing it? We found compiler bugs due to this in the past. (c.f. https://github.com/bitcoin-core/packaging/blob/40f8a131003bb1346a45d78a054db9c5b4b4f0e7/snap/snapcraft.yaml#L51)
I see that the package is submitted as a pull request against the central flathub repo. Who is allowed to propose changes to the package? Who is allowed to sign them off? Is there an “owner” of the package?

A6GibKm commented at 5:27 pm on August 7, 2019: none

Since the actual domain is “bitcoincore” and the pack contains all the binaries, I propose to use org.bitcoincore.bitcoin, or would you rather user bitcoin-qt?

I see that the package is submitted as a pull request against the central flathub repo. Who is allowed to propose changes to the package? Who is allowed to sign them off? Is there an “owner” of the package?

The ideal scenario is that the developers of the app make the PR and have control of it, whoever makes the pull request automatically becomes maintainer. You can add in the PR “Add @XYZ as a contributor please” to add another person. In case the devs don’t want to deal with flatpak or are not interested someone else can make the pull request and becomes maintainer.

For the icon, you can also use svg (c.f. src/qt/res/src/bitcoin.svg)?

It just amounts to install the icon at /app/share/icons/hicolor/scalable/apps/org.bitcoincore.bitcoin.svg.

Can you run the tests before installing it? We found compiler bugs due to this in the past.

Will do.

EDIT: changes at https://github.com/A6GibKm/flathub/tree/org.bitcoincore.bitcoin.

MarcoFalke commented at 6:12 pm on August 7, 2019: member

The program name should indicate the it is the gui, so should contain (or equal) qt or gui. Otherwise it can be confused with the daemon. Is there a reason you don’t offer an entry point for the daemon?

Note that the snap package has the following entry points:

0bitcoin-core.cli     bitcoin-core.daemon  bitcoin-core.qt

MarcoFalke commented at 6:19 pm on August 7, 2019: member

The ideal scenario is that the developers of the app make the PR and have control of it, whoever makes the pull request automatically becomes maintainer. You can add in the PR “Add @xyz as a contributor please” to add another person. In case the devs don’t want to deal with flatpak or are not interested someone else can make the pull request and becomes maintainer.

Ok, so once you are done with the flatpak spec, I fork your repo and create the pull request.

A6GibKm commented at 7:43 pm on August 7, 2019: none

Is there a reason you don’t offer an entry point for the daemon?

I am trying to figure out how to make [Desktop Acttion …] to open a terminal. The other option is to make multiple .desktop files? idk if flatpak supports this. For the moment flatpak run --command=bitcoin-cli/bitcoind org.bitcoincore.bitcoin-qt opens the cli/daemon.

MarcoFalke commented at 7:47 pm on August 7, 2019: member

Ah ok, that seems good enough for now.

A6GibKm commented at 8:05 pm on August 7, 2019: none

Ok, I think this one is fine: https://github.com/A6GibKm/flathub/tree/org.bitcoin.bitcoin-qt. The id is now org.bitcoincore.bitcoin-qt.

You can fork it and send a PR to flathub.

Things to have in mind:

I have not tested archs that are not x86_64.
Flatpak stores the .bitcoin folder at ~/.var/org.bitcoincore.bitcoin-qt. It is possible for the sandbox to be able to read home but I think this is a decent default as the user can change this behaviour via flatpak override --filesystem=home org.bitcoincore.bitcoin-qt.

MarcoFalke commented at 8:20 pm on August 7, 2019: member

Is there a way to build this locally for testing or must the official build farm be used?

You can fork it and send a PR to flathub.

Great! Will do tomorrow.

A6GibKm commented at 8:31 pm on August 7, 2019: none

Is there a way to build this locally for testing or must the official build farm be used?

Yes, with flatpak-builder, flatpak-builder --repo="local repo path" .build org.bitcoincore.bitcoin-qt.json, then add the repo via flatpak remote-add "local repo name" "local repo path" --no-gpg-verify (You don’t want to deal with gpg signatures for the local repo just yet), then flatpak install "local repo name" org.bitcoincore.bitcoin-qt

fanquake commented at 2:43 am on August 9, 2019: member

This is being tracked upstream at: https://github.com/flathub/flathub/pull/1100

MarcoFalke closed this on Aug 9, 2019

A6GibKm commented at 3:58 pm on August 15, 2019: none

@MarcoFalke did you see https://github.com/MarcoFalke/flathub/pull/1?

ThallyssonKlein commented at 10:17 am on October 3, 2020: none

Is this version here official?

DrahtBot locked this on Feb 15, 2022

Distribute via flatpak #16550