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 1: / Line 1: @@
+== Previous Discussion ==
+https://bugzilla.redhat.com/show_bug.cgi?id=1020292
 == 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>.
+*** 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'''
-** Should have its datadir somewhere like %{_datadir}bitcoind/ which expands to /var/lib/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 <code>bitcoin-system-service</code>.  It would contain only the .service file, config, and README's.
-** Config file <code>%config(noreplace) %{_datadir}/bitcoind/bitcoin.conf</code> with wallet disabled by default, but they could enable it with wallet=1 if they really want it.
+** Should have its datadir somewhere like %{_datadir}bitcoin/ which expands to /var/lib/bitcoin/
-** With system username like: <code>bitcoinservice</code>
+** 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.
-** Wrapper should launch bitcoind in a context named like: <code>bitcoindservice_t</code>
+** With system username like: <code>bitcoin</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.
-* '''User service bitcoind and bitcoin-qt'''
-** The most common way in which Bitcoin Core users run their own bitcoind or bitcoin-qt with is as a non-root user with datadir <code>~/.bitcoin/</code>.
+== Safety Requirements ==
-** There should be a separate user homedir SELinux policy for bitcoind and bitcoin-qt operated in this manner.
+* 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.

Search