bitcoin-core snap issues #17912

Following up the recent discussion about Bitcoin Core packaging (#17343, IRC meeting) I've started to test bitcoin-core snap.

1. The most frighten issue, IMO, is automatic updates:

• https://snapcraft.io/docs/keeping-snaps-up-to-date
• https://snapcraft.io/blog/8-ways-snaps-are-different:

However, some users do not wish to have their software updated immediately. ... Snaps enable users to control when updates are delivered. Users can postpone them to update outside the working day, overnight, or later in the month

It seems there is no way to disable updates at all.

2. The default datadir is ~/snap/bitcoin-core/common/.bitcoin, which means it will be removed during removing of bitcoin-core snap or the entire snap framework.

3. The GUI settings (currently, QSettings) are stored in ~/snap/bitcoin-core/<revision>/.config/Bitcoin directory, which means they will be dropped after the snap update.

4. ~On Debian 10.2 I didn't find the way to launch bitcoin-qt with command line options. This makes it impossible to use -choosedatadir option (a minor issue).~ (bitcoin-core.qt works)

5. On Debian 10.2 "Start Bitcoin Core on system login" does not work (a minor issue).

Should we clear inform users about mentioned pitfalls?

Refs:

• #15936
• #17636

It seems there is no way to disable updates at all.

lt is always possible to select a different "track", e.g. 0.19 to avoid upgrading to 0.20

The default datadir is ~/snap/bitcoin-core/common/.bitcoin, which means it will be removed during removing of bitcoin-core snap or the entire snap framework.

snaps can create snapshots, and they do by default on uninstall. See https://snapcraft.io/docs/snapshots

On Debian 10.2 I didn't find the way to launch bitcoin-qt with command line options. This makes it impossible to use -choosedatadir option (a minor issue).

What is the error message of bitcoin-core.qt -regtest -help or similar?

It seems there is no way to disable updates at all.

lt is always possible to select a different "track", e.g. 0.19 to avoid upgrading to 0.20

This option does not defend a user from (possibly malicious) update within a "track", e.g., from 0.19.0 to 0.19.1, no?

The default datadir is ~/snap/bitcoin-core/common/.bitcoin, which means it will be removed during removing of bitcoin-core snap or the entire snap framework.

snaps can create snapshots, and they do by default on uninstall. See https://snapcraft.io/docs/snapshots

TIL, thank you. More from https://snapcraft.io/docs/snapshots:

... a snapshot is generated automatically when a snap is removed. These snapshots are retained for 31 days before being deleted automatically.

I like "automatically" stuff, but not in Bitcoin Core ;) Should we just suggest a user to place a datadir into the $HOME directory, which is a non-default in snap installation?

This option does not defend a user from (possibly malicious) update within a "track", e.g., from 0.19.0 to 0.19.1, no?

It does not. Though the alternatives (ppa or flatpak) don't "defend" against that either.

Should we just suggest a user to place a datadir into the $HOME directory, which is a non-default in snap installation?

Yeah, why not. See also https://github.com/bitcoin-core/packaging/issues/34

On Debian 10.2 I didn't find the way to launch bitcoin-qt with command line options. This makes it impossible to use -choosedatadir option (a minor issue).

What is the error message of bitcoin-core.qt -regtest -help or similar?

Thanks, did not know about bitcoin-core.qt, bitcoin-core.daemon and bitcoin-core.cli.

This option does not defend a user from (possibly malicious) update within a "track", e.g., from 0.19.0 to 0.19.1, no?

It does not. Though the alternatives (ppa or flatpak) don't "defend" against that either.

If current version number could be stored in the datadir, it would possible for client to detect if it was updated and warn a user. Is it worth?

If current version number could be stored in the datadir, it would possible for client to detect if it was updated and warn a user. Is it worth?

No, because if the update was malicious it would not show the warning. If the update was not malicious it would show the warning every time and users would ignore this.

Anything left to answer here? I think this can be closed.