BITCOIN: Difference between revisions

Latest revision as of 00:34, 21 January 2016

Previous Discussion

https://bugzilla.redhat.com/show_bug.cgi?id=1020292

RPM Package and SELinux

Bitcoin is used in two different ways. The most common is as a user daemon (bitcoind) or graphical UI (bitcoin-qt) that both use ~/.bitcoin/ in the user homedir. Less common is as a system service with homedir in a location like /var/lib/bitcoin. The package should support either modes of operation, but for the sake of simplicity they should share the same SELinux contexts, fs labels and policy.

User service bitcoind and graphical bitcoin-qt
- The most common way to use Bitcoin Core is users run their own bitcoind or bitcoin-qt as a non-root user with datadir ~/.bitcoin/.
  - Note: Arbitrary other services may need to be granted both UNIX filesystem and SELinux permission to read the autotoken file from the user's ~/.bitcoin directory. This is a newer way in which bitcoin-cli is intended to know how authenticate with the bitcoind RPC interface that in Warren's opinion is difficult to support in a consistent way. Perhaps for now we should suggest using the old method of manually configured rpc ports, usernames and passwords.
- Maybe we provide an example user-level systemd .service file.
System Service bitcoind
- bitcoind is not normally used as a system service but people want it to be packaged in this way. Perhaps this should be an optional sub-package like bitcoin-system-service. It would contain only the .service file, config, and README's.
- Should have its datadir somewhere like %{_datadir}bitcoin/ which expands to /var/lib/bitcoin/
- Config file %config(noreplace) %{_datadir}/bitcoin/bitcoin.conf with wallet disabled by default, but they could enable it with wallet=1 if they really want it.
- With system username like: bitcoin
- %doc README-FEDORA-BITCOIN-SERVICE should probably explain how the service is meant to be configured, used and controlled with bitcoin-cli or RPC/REST interfaces as the non-default datadir does not match upstream documentation and it thus may be non-obvious to users.

Safety Requirements

Wait for Bitcoin Core 0.12 for libsecp256k1.

Security Requirements

Build Determinism/Reproducible Builds: Given identical inputs of source code and N-V-R's of dependencies in the buildroot, the binary output packaged must be identical when built by anyone.
- In this way anyone can verify that the binaries built on the Fedora buildsystem are not different from what should have been built from that source code. This allows for improved assurance that the build is not compromised.
- Work towards this is being done at https://github.com/fkautz/ReproducibleBuilds which builds on kholia's prior work.
Medium-term goal: Also modify the .spec's of all library dependencies to make their builds reproducible.

@@ Line 3: / Line 3: @@
 == RPM Package and SELinux ==
-There probably should be two separate SELinux policy modules for the two different ways Bitcoin Core is used.
+Bitcoin is used in two different ways.  The most common is as a user daemon (bitcoind) or graphical UI (bitcoin-qt) that both use ~/.bitcoin/ in the user homedir.  Less common is as a system service with homedir in a location like /var/lib/bitcoin.  The package should support either modes of operation, but for the sake of simplicity they should share the same SELinux contexts, fs labels and policy.
 * '''User service bitcoind and graphical bitcoin-qt'''
 ** The most common way to use Bitcoin Core is users run their own bitcoind or bitcoin-qt as a non-root user with datadir <code>~/.bitcoin/</code>.
-** There should be a separate user homedir SELinux policy for bitcoind and bitcoin-qt operated in this manner, with a context like <code>user_bitcoin_t</code>.
+*** Note: Arbitrary other services may need to be granted both UNIX filesystem and SELinux permission to read the autotoken file from the user's ~/.bitcoin directory.  This is a newer way in which bitcoin-cli is intended to know how authenticate with the bitcoind RPC interface that in Warren's opinion is difficult to support in a consistent way. Perhaps for now we should suggest using the old method of manually configured rpc ports, usernames and passwords.
-*** Note: Arbitrary other services may need to be granted both UNIX filesystem and SELinux permission to read the autotoken file from the user's ~/.bitcoin directory.
+** Maybe we provide an example user-level systemd .service file.
 * '''System Service bitcoind'''
-** bitcoind is not normally used as a system service but people want it to be packaged in this way.  Perhaps this should be a sub-package like bitcoin-system-service.  It would contain only the .service file, config, and README's.
+** bitcoind is not normally used as a system service but people want it to be packaged in this way.  Perhaps this should be an optional sub-package like <code>bitcoin-system-service</code>.  It would contain only the .service file, config, and README's.
-** Should have its datadir somewhere like %{_datadir}bitcoinsys/ which expands to /var/lib/bitcoinsys/
+** Should have its datadir somewhere like %{_datadir}bitcoin/ which expands to /var/lib/bitcoin/
-** Config file <code>%config(noreplace) %{_datadir}/bitcoinsys/bitcoin.conf</code> with wallet disabled by default, but they could enable it with wallet=1 if they really want it.
+** Config file <code>%config(noreplace) %{_datadir}/bitcoin/bitcoin.conf</code> with wallet disabled by default, but they could enable it with wallet=1 if they really want it.
-** With system username like: <code>bitcoinsys</code>
+** With system username like: <code>bitcoin</code>
-** Wrapper should launch bitcoind in a context named like: <code>bitcoinsys_t</code>
 ** %doc README-FEDORA-BITCOIN-SERVICE should probably explain how the service is meant to be configured, used and controlled with bitcoin-cli or RPC/REST interfaces as the non-default datadir does not match upstream documentation and it thus may be non-obvious to users.
@@ Line 25: / Line 24: @@
 * Build Determinism/Reproducible Builds: Given identical inputs of source code and N-V-R's of dependencies in the buildroot, the binary output packaged must be identical when built by anyone.
 ** In this way anyone can verify that the binaries built on the Fedora buildsystem are not different from what should have been built from that source code.  This allows for improved assurance that the build is not compromised.
+** Work towards this is being done at https://github.com/fkautz/ReproducibleBuilds which builds on kholia's prior work.
 * Medium-term goal: Also modify the .spec's of all library dependencies to make their builds reproducible.

Search