I submit this package now that EC crypto has been enabled in Fedora. Co-mantainers are welcomed!

I'm happy to co-maintain this, especially since you've based this on my previous work.

One big problem that is not resolved here is that Bitcoin ships a bundled copy of leveldb, and this needs to be dealt with. This is harder than it looks: Bitcoin uses code from leveldb that Fedora does not currently ship, so leveldb is going to need to be changed first.

I'll do a full review later.

Upstream developers including gmaxwell, jgarzik and myself expressed an interest in being involved with this review.  Please DO NOT APPROVE without upstream cooperation.

Bitcoin is very strange software where distributions can create systemic risk if inappropriately modified nodes exist in large numbers due to the danger of altering the norms of global consensus.

http://bitcoinmagazine.com/5858/linux-distribution-packaging-and-bitcoin/
""For this reason, it is vital that as much of the network as possible uses unmodified implementations that have been carefully audited and tested, including dependencies. For instance, if the included copy of LevelDB in bitcoind is replaced by a system-wide shared library, any change to that shared library requires auditing and testing, a requirement generally not met by standard distributor packaging practices."

<Luke-Jr> packagers can use system leveldb, but doing so safely *needs* appropriate care
<Luke-Jr> most distros aren't willing to give that care
<Luke-Jr> in particular, they need to lock leveldb to known-good versions (not even doing bugfixes), and disable snappy support

Bitcoin's leveldb is a fork or a separately built and maintained instance of leveldb.  I suggested that they rename this separate leveldb to make it clear that it is Bitcoin-specific.

If anyone with deeper understanding of the inner workings of Bitcoin want to take the ownership of this request, feel free to do it.

I'm not a developer, so all the work needed with the libraries will be hard to me.

Michael, thank you for your previous work.

Bitcoin is part of a new category of software that relies on distributed consensus.  The integrity of the entire system, the ability to secure money itself, relies on all nodes coming to a consensus on a timeline of transactions (block chain).

Any part of the system which causes a deviation, however slight, in a hash-secured system will partition nodes away from the main network.

In bitcoin's history, the database library has **already** played a role in causing the network consensus to fail: https://en.bitcoin.it/wiki/BIP_50

To be specific, if Fedora's system leveldb is upgraded, that could partition nodes receiving the upgrade away from other nodes on the network, if a network-exposed database detail is present.

It may seem counterintuitive, but for the sake of distributed consensus, we may even elect to _not_ upgrade a piece of code, thereby maintaining bug-for-bug compatibility with existing network nodes.

Bitcoin is quite literally a new form of database, similar to Amazon Dynamo's "eventually consistent" distributed database.

We need a special Fedora policy exception WRT system libraries, for this reason.

It is standard distro policy to remove embedded libs, for very good reasons:   an embedded zlib, for example, would not receive a bug fix that the system zlib will receive.

Bitcoin is the opposite.  We MUST be bug-for-bug compatible, and an upgrade of a system lib has the potential to break consensus.

(In reply to Jeff Garzik from comment #5)

> To be specific, if Fedora's system leveldb is upgraded, that could partition
> nodes receiving the upgrade away from other nodes on the network, if a
> network-exposed database detail is present.

This sounds very strange to me. If it's true, and Bitcoin is so fragile due to changes in underlying libraries, then it looks like a potential attack vector.

Btw why not to maintain glibc, kernel, compilers in sync as well?

We have direct field experience[1], learned during the ongoing growth of this $1.6 billion dollar system[2], that database is a particularly sensitive area, and chose to bundle the database after discussion.

Further, we have seen packagers in other distros -- Debian -- unthinkingly change out bundled libraries and patch bitcoin to the point where the software simply did not work:  it would not validate the blockchain at all.

Few technologists have (1) experience with distributed consensus, and (2) have worked on sotware that secures over $1 billion in money from counterfeiting.  Details which need care are not readily apparent, if you are not already familiar with this technology.

Bitcoin has been compared to avionics or medical device software.  You simply /have/ to get all details right.  The consequences of failure are total loss of bitcoin value for the user, or even worse, total loss of value for all users.

Like avionics or medical device software, component and module upgrades are VERY carefully tested and staged, much more rigorously than "yum -y upgrade"

[1] https://en.bitcoin.it/wiki/BIP_50
[2] http://bitcoinwatch.com/

(Jeff said all that I think needed to be said on the consensus points, so I'll leave that alone for the moment)

The patch bitcoin-0.8.5-libdb_path.patch is unnecessary. The build uses BDB_INCLUDE_PATH for this purpose, and it appears to be set in the spec so I'm not sure why this patch is there.

I don't think installing the "debian example configuration" is of any use. I'd forgotten that was in contrib at all, and the system will not work with that configuration alone in any case. (Though in principle I don't see anything wrong with using it in principle, the one in the bitcoin codebase is outdated and not useful).

The only thing that needs to be set for the daemon to actually be usable is the rpcuser / rpcpassword settings, and rpcpassword should be set to a cryptographically strong random value.

I have dropped the patch, qmake didn't get the environment variables, so I've added them as arguments.

Spec URL: http://jorti.fedorapeople.org/bitcoin/bitcoin.spec
SRPM URL: http://jorti.fedorapeople.org/bitcoin/bitcoin-0.8.5-3.fc19.src.rpm

Regarding selinux ...

/etc/bitcoin(/.*)?              gen_context(system_u:object_r:bitcoin_conf_t,s0)
/usr/bin/bitcoind               --      gen_context(system_u:object_r:bitcoin_exec_t,s0)
/var/lib/bitcoin(/.*)?          gen_context(system_u:object_r:bitcoin_var_lib_t,s0)

1) Is this the only location where we want Bitcoin to have its configuration and data files?  It is also very common for users to run it where all of this stuff is in ~/.bitcoin/

2) bitcoin-qt (using the ~/.bitcoin) is unconfined?

3) Is it normal for packages to ship their own policy?

Currently bitcoind is not well suited to operate as a system service.

The user's bitcoind as a RPC client could hypothetically operate to control the system bitcoind, but that isn't true of the user's bitcoin-qt.  This makes operating bitcoind as a system service confusingly disjunct from the user's bitcoind and bitcoin-qt.  The user's bitcoind and bitcoin-qt are meant to operate on the same data files and wallet while a system bitcoind.

bitcoin 0.9 is planned to have key improvements that make it more suitable to use as system service.

Perhaps bitcoin 0.8 as packaged should ...

* Include a README.FEDORA in %doc explaining the current state of the package, how it is meant to be used.
* The entire selinux policy design should be thought through carefully to be able to handle the future expected uses of bitcoin.
* To handle today's normal use, the selinux policies should confine and permit usage of the standard ~/.bitcoin directory in homedirs.
* Perhaps the selinux policy should additionally handle the system service directories, even though it isn't commonly used yet.  Would that within the same policy weaken protection of the system service?
* For now do not include the .service file.  That would misleadingly suggest that running it as a system service is the normal method of operation.  Wait until changes come in 0.9 then reassess the situation.
* Put the .service file in installed examples documented by README.FEDORA so people know how to use the unsupported method of operation for now if they really want it.

(In reply to Warren Togami from comment #10)
> Regarding selinux ...
> 
> /etc/bitcoin(/.*)?             
> gen_context(system_u:object_r:bitcoin_conf_t,s0)
> /usr/bin/bitcoind               --     
> gen_context(system_u:object_r:bitcoin_exec_t,s0)
> /var/lib/bitcoin(/.*)?         
> gen_context(system_u:object_r:bitcoin_var_lib_t,s0)
> 
> 1) Is this the only location where we want Bitcoin to have its configuration
> and data files?  It is also very common for users to run it where all of
> this stuff is in ~/.bitcoin/
> 
> 2) bitcoin-qt (using the ~/.bitcoin) is unconfined?

The only real interest that I have had expressed to me with respect to an SELinux policy was for securing it when running as a service. Nobody has yet expressed interest in having a policy for the GUI client, though I think this is a good idea anyway.

> 3) Is it normal for packages to ship their own policy?

It's normal when there is no SELinux policy already existing upstream for the package. For instance, see (possibly out of date) https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft

Ideally the policy should eventually go upstream into the reference policy/Red Hat policy.

(In reply to Warren Togami from comment #11)
> Currently bitcoind is not well suited to operate as a system service.
> 
> The user's bitcoind as a RPC client could hypothetically operate to control
> the system bitcoind, but that isn't true of the user's bitcoin-qt.  This
> makes operating bitcoind as a system service confusingly disjunct from the
> user's bitcoind and bitcoin-qt.  The user's bitcoind and bitcoin-qt are
> meant to operate on the same data files and wallet while a system bitcoind.

It's been my experience that very few people who are interested in running a system service also want to run the GUI client _on the same machine_. The usual use case here is a service operator who wants his code to talk to bitcoind via its API, and there's no GUI anywhere on the server. But, as you noted, bitcoind isn't very well suited to run as a system service. The FHS compliance patch and init script in my build address this, but not as well as could be done with more extensive changes.

> bitcoin 0.9 is planned to have key improvements that make it more suitable
> to use as system service.

I am definitely looking forward to this.

> Perhaps bitcoin 0.8 as packaged should ...
> 
> * Include a README.FEDORA in %doc explaining the current state of the
> package, how it is meant to be used.

This is a good idea and I'll put it in my next release.

> * The entire selinux policy design should be thought through carefully to be
> able to handle the future expected uses of bitcoin.
> * To handle today's normal use, the selinux policies should confine and
> permit usage of the standard ~/.bitcoin directory in homedirs.
> * Perhaps the selinux policy should additionally handle the system service
> directories, even though it isn't commonly used yet.  Would that within the
> same policy weaken protection of the system service?

The SELinux policy definitely needs more eyeballs. It's functional for what it does though. But I expect it will need some perhaps significant work for the 0.9 changes you alluded to, so I want to look at how 0.9 is shaping up first.

> * For now do not include the .service file.  That would misleadingly suggest
> that running it as a system service is the normal method of operation.  Wait
> until changes come in 0.9 then reassess the situation.
> * Put the .service file in installed examples documented by README.FEDORA so
> people know how to use the unsupported method of operation for now if they
> really want it.

This is a problem because if we don't install the init script, we can't update it later except by overwriting the user's manually installed init script. (And I want to switch this out for a systemd unit file soon, which would still be a pain for users to manually install. This will almost certainly wait for 0.9.) And if we remove it, then existing installations break after updating. Bad news both ways.

Please close. The OpenSSL RPM in Fedora has now been re-hobbled to only use NIST endorsed curves (commit b3551463cafee86a63c60e294f754a8c5cddc37a), unlike the initial w/ EC OpenSSL RPM, and thus stock Fedora is unsuitable for Bitcoin.

Juan, can you add this package to rpmfusion repository? With needed ssl additions.

(In reply to Vasiliy Glazov from comment #14)
> Juan, can you add this package to rpmfusion repository? With needed ssl
> additions.

I doubt that the package (along with its dependencies) of this complexity can make it to RPMFusion. And I didn't say anything about the further state, and support of the package there.

(In reply to Vasiliy Glazov from comment #14)
> Juan, can you add this package to rpmfusion repository? With needed ssl
> additions.

There should be available openssl-freeworld as a parallel installable library first.
I think this bug should be reopened:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2842

Please do not defame Bitcoin by sticking it in some "freeworld" repository and suggesting that there is any patent concern unless you are willing to contact me (in private, if you like) with the patent numbers in particular you are concerned with.

The patent environments around the authentication we use has been carefully reviewed and there are no known concerns.  If RedHat is interested in only shipping NIST approved cryptography thats its decision to make, but please don't use this decision to suggest that there is any patent concern with Bitcoin. It's simply not true as far as anyone knows.

CANTFIX is a silly resolution while bug 1021898 is open.  The real current status of this bug is that there's a dependency on other unfinished work.  Drama or distro politics doesn't belong in a bug tracker.

(In reply to Bill McGonigle from comment #18)
> CANTFIX is a silly resolution while bug 1021898 is open.  The real current
> status of this bug is that there's a dependency on other unfinished work. 
> Drama or distro politics doesn't belong in a bug tracker.

Agree. Let's reopen it.

The secp256k1 curve has now been enabled in our openssl package (#1021898), so I think we can finally move forward with this.

is this time for a copr build ? 

anyone willing to take the review ?

I'll have to refresh myself about this package, since I haven't looked at it since a lot of time ago.

If someone wants to take over it, I'll be thankful, because I won't have many free time in the near term. If some one is willing to take it, I can help comaintaining.

I'm happy to take this over (as I'm already building these anyway) but it'll be a few days before I have something reviewable up, as I do want to test the new OpenSSL version carefully before doing anything else. And it still needs a FESCo exception for bundling libraries (mainly LevelDB), that needs to be taken care of as well.

I strongly suggest that I either take over the package or have last say in the package review.  I work on the upstream project and yes, we have a number of special security and safety hazard considerations that require discussion with FESCO because it falls outside the ordinary rules of the packaging guidelines.

I've been using Michael's packages for quite a while - +1. 

Fedora's model is to trust the packagers.  If there's not a 'make test' validation suite then perhaps that can be fixed upstream.  We shouldn't treat any software as magic and requiring particular people's blessings (not meant to dissuade any potential packagers, of course).  If the upstream code is right and the SPEC is right, the binary should work correctly (or one or both need fixing).

I might well prefer to build from source anyway for a given mtune; if there's ambiguity in the correctness of the build process that's going to be a large problem for many users.

Warren - do you want to take lead on the FESCO ticket?

There are actually several different test suites that should be run, which validate various things. Some of them are non-obvious, some aren't enabled by default, and some require downloading a separate test suite.

I've made a draft package (cutting out all the old EL6 stuff since we can't build for it anymore) and I'll be submitting it here as soon as the openssl build lands in updates-testing and I can do koji scratch builds. But all the tests are passing for me locally.

I would be happy to pass off part or all of this work to Warren or another Bitcoin Core developer. In fact I'm quite happy that upstream is so closely involved; this is not a typical thing with most software projects. 

What is needed for a bundling exception is documented here: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Exceptions

I would fill this out, but since upstream is involved I think it would be better for an upstream developer to do it, as they'll be able to better make the case for it.

Upstream has several major concerns about how to proceed here.  It is rather complex to the point that I need to draft several pages and get them to review it before approaching FESCo.

Please be patient and know that I am handling this.  This must not be rushed if you want Bitcoin to be safe.  It matters that we get this right in how Fedora and (and later EPEL) ships Bitcoin because a Fedora-specific bug could cause the entire world to fail due to the peculiar and relatively new field of consensus critical networks.

http://luke.dashjr.org/tmp/code/20130723-linux-distribution-packaging-and-bitcoin.md.asc
This was a 2013 note on the hazards of consensus.  This is not a mere hypothetical, paranoid concern.  It consensus already broke once due to leveldb in early 2013, and things got close to horribly wrong due to unexpected behaviors or bugs in openssl.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html

This is fixable and Fedora can feasibly ship Bitcoin safely.  We just need to fully communicate the issues between upstream Bitcoin and FESCo and decide on what we can do together.  More details forthcoming.

Sorry for the delay.  Long story short, upstream Bitcoin recommends extreme caution against shipping Bitcoin linked against the heavily patched openssl that Fedora uses.  Upstream openssl has proven to be buggy and hazardous to consensus due to unexpected behaviors on different architectures, and they do not have the bandwidth to doubly check bug-for-bug compatibility with another variant that is Fedora's openssl.

https://github.com/bitcoin/secp256k1
The next major release of Bitcoin within months will switch the consensus critical portion of secp256k1 ECDSA signing and validation to a super optimized and 2-year audited internal implementation that will be much safer.

The upstream recommendation is to HOLD on shipping Bitcoin in Fedora until the new version is available.  The possibility of breaking the Bitcoin network due to a large quantity of nodes having a subtly different rule is not only a hypothetical problem.  The security issue recently fixed in BIP66 would have been a way to break the network accidentally or intentionally.

There are other challenges in the build that will require discussion with FESCo.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011182.html
Release schedule for Bitcoin Core 0.12

https://fedoraproject.org/wiki/BITCOIN
See packaging and security notes

> the binary output packaged must be identical when built by anyone. 

Are we having Fedora-level problems where this isn't always true?  I'm used to comparing md5sums when locally building to verify security-related packages.  Not super-recently, though; wondering if there's been breakage. We had issues dealing with ugly buildroots on CentOS 6, but I thought this was all straight at this point.

> There are other challenges in the build that will require discussion with FESCo.

can you outline those here?  We have folks on this bug who can help work those in parallel.

>> the binary output packaged must be identical when built by anyone. 
> Are we having Fedora-level problems where this isn't always true?

When using mock to build a clean buildroot, given a set of N-V-R's the binary output must be identical as the same package built in an identical buildroot.  This would require build-time hacks beyond the usual 

>> There are other challenges in the build that will require discussion with FESCo.
> can you outline those here?

A few examples:
* The official file format of the wallet.dat is BDB4.  For this reason it MUST build against libdb4-devel.  It appears this is fine in Fedora, but RHEL7 ships only libdb4 without the -devel package, so we'd need an exception for EPEL.
* The leveldb/ directory of the source is a Bitcoin-specific fork of leveldb.  Upstream leveldb is abandoned as a project, and leveldb is consensus critical so it is unsafe to link it to an general distribution library maintained in a separate package that could differ from leveldb used by non-Fedora Bitcoin nodes.  FESCo would need to approve Bitcoin shipping its own fork of leveldb that is static linked in Bitcoin itself.
* libsecp256k1/ directory of the source is another consensus critical library static linked in Bitcoin.  FESCo must just allow Bitcoin to maintain and ship its own internal components, especially these components that are shipped in the Bitcoin source itself because they are consensus critical.

bitcoin (core) > 0.12 is released

Like to ask whether I can take over the maintainership of this package?

When you are reviewing this spec, please take a closer look on the crypto part.
Please also take a look on the daemon part as I dont feel fully comfortable about the %pre and %post steps. As well as that their maybe should be a daemon default config file?

Spec URL: https://raw.githubusercontent.com/sspreitzer/bitcoin-specs/master/bitcoin.spec
SRPM URL: https://kojipkgs.fedoraproject.org//work/tasks/1826/13821826/bitcoin-0.12.1-2.fc23.src.rpm
Description:
Bitcoin is an experimental new digital currency that enables instant
payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
technology to operate with no central authority: managing transactions
and issuing money are carried out collectively by the network. Bitcoin Core
is the name of the open source software which enables the use of this currency.

Fedora Account System Username: sspreitz

(In reply to Sascha Spreitzer from comment #34)
> Like to ask whether I can take over the maintainership of this package?

Sure. Thank you.

A few of the upstream Bitcoin Core project requests that Fedora reconsider shipping any Bitcoin package at all.  It is notable that Debian does not, and Ubuntu stopped shipping a bitcoin package a while ago.  Upstream has a new plan to address the needs of the leading deb and rpm distros that significantly reduces security risk for both the Linux distributions and the users.  I will be bring the reasons to FESCo as this is not a normal situation after the new plan has been implemented in code.  Sorry for the delays.

Please consider that in 0.12 the vital cryptograpic parts are shipped with the source:

[..]
-rw-r--r-- root/root      1057 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/COPYING
drwxr-xr-x root/root         0 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/include/
-rw-r--r-- root/root      1014 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/include/secp256k1_ecdh.h
-rw-r--r-- root/root     25771 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/include/secp256k1.h
-rw-r--r-- root/root      4700 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/include/secp256k1_recovery.h
-rw-r--r-- root/root      8302 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/include/secp256k1_schnorr.h
-rw-r--r-- root/root       322 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/libsecp256k1.pc.in
-rw-r--r-- root/root      3521 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/Makefile.am
-rw-r--r-- root/root     61657 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/Makefile.in
drwxr-xr-x root/root         0 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/src/
-rw-r--r-- root/root       944 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/src/basic-config.h
-rw-r--r-- root/root      1576 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/src/bench_ecdh.c
-rw-r--r-- root/root      1726 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/src/bench.h
-rw-r--r-- root/root     12623 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/src/bench_internal.c
-rw-r--r-- root/root      2022 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/src/bench_recover.c
-rw-r--r-- root/root      2462 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/src/bench_schnorr_verify.c
-rw-r--r-- root/root      1594 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/src/bench_sign.c
-rw-r--r-- root/root      2437 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/src/bench_verify.c
-rw-r--r-- root/root      1172 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/src/ecdsa.h
-rw-r--r-- root/root     10247 2016-01-01 01:00 bitcoin-0.12.1/src/secp256k1/src/ecdsa_impl.h
[..]

Thus bitcoin is now safe for packaging for distributions? Please raise this to the FESCo.

A few upstream developers were alarmed to hear how quickly Fedora releases are EOL'ed.  This is of concern because it is hazardous for unmaintained versions of Bitcoin to continue running after EOL.

There is a separate even bigger concern that it is very dangerous to have automatic updates of Bitcoin software.  Does Fedora infrastructure have options to further lock down the ability of insiders or hackers to push a trojan through the update process?  The scenario of a compromised auto-update leading to millions of dollars of losses is not a trivial risk when the incentive is very high.

For reasons like this Ubuntu and Debian do not distribute Bitcoin at all.

Upstream goes through extreme effort to build deterministic, bit-for-bit reproducible binaries that are verifiable as being identical to what others can build as added protection against the possibility of trojan distribution.  They are now in favor of upstream adding both rpm and deb outputs to distribute their existing deterministic binary.

So yes, upstream would strongly caution against Fedora distributing Bitcoin for the above reasons.  If Fedora insists on shipping Bitcoin then let us discuss how to mitigate the risks in ways like:

* Ship the upstream deterministic binary in an RPM.  This is very much against Fedora policy but this is the safest and easiest to maintain option.
* Make the build of Bitcoin within the Fedora build system deterministic and verifiable when compared to building it on an identical buildroot.
* Add additional safeguards to the update process to require a much higher threshold of review including build determinism testing.

It might be worth considering exclusively offering Bitcoin in an out-of-band repository built somewhat differently. For example, perhaps building against EL7 and using that build for all Fedora targets along with EL7. Since it uses its own bundled crypto, I would suggest that's probably the best way to go. It might even be worth working with upstream to provide fully deterministic builds that would work for RPM based distributions, built from the Fedora infrastructure.

Has upstream considered building and distributing a Flatpak of Bitcoin? That would solve quite a few issues, including those exposed here.

Bitcoin is now getting close to building a self-hosted, general purpose deterministic toolchain.  This toolchain will eventually be buildable from any Linux distro, and using it in a controlled manner will allow building binaries that are bit-for-bit identical no matter what Linux system you built it upon.  I think this is the highest level of assurance we can realistically achieve in guarding against potential compromise.

When this toolchain is ready we'll be able to separately package it in Fedora and use it to build a Bitcoin RPM where the binary output could be identical to binaries that we build elsewhere.  It could be compared to be similar in concept to a cross-compilation toolchain.

Now it is a separate question if Fedora would allow special casing beyond the normal packaging guidelines to allow for the use of such a different build toolchain.

Another question is if Fedora will allow special casing to allow Bitcoin to ship with its own static linked copies of libraries that it maintains internally.  This is the only way it can achieve bit-for-bit determinism.

https://fedoraproject.org/wiki/Chromium
Historically Chromium was not allowed into Fedora because it relied upon Google maintained internal copies of libraries, but it seems this was allowed into Fedora August 2016.  Looking at the .spec it looks like Fedora must have allowed it in as a special case, as it ships its own internal Google-maintained libraries.  I wonder if they decided to just trust that the libraries maintained by the vendor are well cared for.

So perhaps this a good sign that Fedora may allow this crazy package to be built in a way that is compatible with upstream's security concerns.

Hmm, looking deeper at the chromium.spec it appears that we actually mostly rely on Fedora's libraries, so this isn't a good point of comparison.

I think given the upcoming deterministic toolchain we can at least hopefully look forward toward a COPR or maybe upstream yum/dnf repo.

There remains the concern that upstream is against automatic upgrades.  I don't have a good suggestion for dealing with this issue.

(In reply to Warren Togami from comment #42)
> Hmm, looking deeper at the chromium.spec it appears that we actually mostly
> rely on Fedora's libraries, so this isn't a good point of comparison.

Am I missing something here? I see this in the chromium rpm:

bundled(NSBezierPath) = 1.0
bundled(SMHasher) = 0
bundled(angle) = 2422
bundled(bintrees) = 1.0.1
bundled(boringssl)
bundled(brotli)
bundled(bspatch)
bundled(cacheinvalidation) = 20150720
bundled(cardboard) = 0.5.4
bundled(colorama) = 799604a104
bundled(crashpad)
bundled(dmg_fp)
bundled(expat) = 2.1.0
bundled(fdmlibm) = 5.3
bundled(ffmpeg) = 2.6
bundled(fips181) = 2.2.3
bundled(fontconfig) = 2.11.0
bundled(gperftools) = svn144
bundled(gtk3) = 3.1.4
bundled(hunspell) = 1.3.2
bundled(iccjpeg)
bundled(icu) = 54.1
bundled(kitchensink) = 1
bundled(leveldb) = r80
bundled(libXNVCtrl) = 302.17
bundled(libaddressinput) = 0
bundled(libjingle) = 9564
bundled(libphonenumber) = svn584
bundled(libpng) = 1.6.22
bundled(libsrtp) = 1.5.2
bundled(libudis86) = 1.7.1
bundled(libvpx) = 1.4.0
bundled(libwebp) = 0.4.3
bundled(libyuv) = 1444
bundled(lzma) = 9.20
bundled(mesa) = 9.0.3
bundled(mozc)
bundled(mt19937ar) = 2002.1.26
bundled(ots) = 767d6040439e6ebcdb867271fcb686bd3f8ac739
bundled(protobuf) = r476
bundled(qcms) = 4
bundled(re2)
bundled(sfntly) = svn111
bundled(skia)
bundled(snappy) = r80
bundled(speech-dispatcher) = 0.7.1
bundled(sqlite) = 3.8.7.4
bundled(superfasthash) = 0
bundled(talloc) = 2.0.1
bundled(usrsctp) = 0
bundled(v8) = 4.5.103.35
bundled(webrtc) = 90usrsctp
bundled(woff2) = 445f541996fe8376f3976d35692fd2b9a6eedf2d
bundled(x86inc) = 0
bundled(xdg-mime)
bundled(xdg-user-dirs)
bundled(zlib) = 1.2.5

It bundles a lot of stuff that is already in Fedora.

OK thanks, I misunderstood what I was seeing.  I have not been keeping close tabs on Fedora dev in recent years.

https://fedoraproject.org/wiki/Bundled_Libraries
It seems that we have some hope for packaging this in a way that would be compatible with upstream's security concerns.  We now need to wait for the deterministic toolchain, demonstrate how it works, and then proceed to get approval for this.

It took years but upstream Bitcoin is now approaching a satisfactory replacement for the reproducible build problem.

https://github.com/bitcoin/bitcoin/pull/15277
This GNU GUIX based build system is a very minimal deterministic build environment that results in a reproducible binary. It is meant to replace the unverifiable, Ubuntu based Gitian build system. Once upstream is satisfied with the stability of this approach then the upstream deterministic binaries is exactly what we should ship in Fedora's RPM. Hypothetically the minimum core of the build system could be packaged for Fedora so this can be built in the Fedora build system resulting in an identical binary. This will take hopefully a few months.

https://github.com/bitcoin/bitcoin/pull/12255/files
A different discussion we should have among the various RPM packagers of Bitcoin is where the data directories should be. 10 days ago they changed various paths in upstream's reference .spec file. We don't want Fedora shipping a Bitcoin RPM to cause sudden surprises to people who had different paths from other packages in recent years.

A few ideas to reduce risk:
* We should consider naming Fedora's package "bitcoincore" for those who want exactly upstream's bit-for-bit identical distribution that also behaves in a manner matching upstream documentation. It should conflict with "bitcoin". A popular feature-fork "bitcoinknots" would have the same binary and configuration files and would thus conflict with these other names.
* Also Fedora should disallow any package named "bitcoin". There are multiple reasons for this including unexpected upgrade conflicts with ways it was previously packaged and also convenient way in which to sidestep eternal political fights over what has the right to be called "bitcoin".
* Another upstream concern is the risk of old bitcoin binaries in the wild when Fedora goes EOL. The simplest safeguard to this issue is to ship a final RPM update before a Fedora release's EOL that simply removes the binary.

https://youtu.be/I2iShmUTEl8
The above verifiable bootstrapping and reproducible toolchain is explained in this video. I'm hoping it will become mature enough this year.

https://github.com/bitcoin/bitcoin/tree/master/contrib/guix
The verifiable bootstrap and reproducibly built Bitcoin Core was merged a while ago. Linux builds work great today but they are working to fix their Windows and OS X cross compiled builds before the project switches to this method for releases.

If people want this to be packaged into Fedora first we need to get its buildsystem Guix accepted into Fedora. We might need FESCo approval for this or later Bitcoin-specific steps.

https://copr.fedorainfracloud.org/coprs/lantw44/guix/
I have not tried this but somebody maintains it in COPR already.

Just a reminder, Fedora does not ship pre-built binaries. I honestly can't tell if that's what you're advocating here or not.

This package does not seem to ready for the review.

Once the packager, last seen on 2016-04-27, comes with a suitable spec file, Warren, or anybody else can start the formal review with assigning the review to himself, setting a state to ASSIGNED, and setting fedora-review flag to "?".

I've been packaging the software for myself for a few years now, if there is no answer to this ticket from the original poster I will re-create the review and close this as a duplicate.

Go ahead, no problem.

Thanks!

*** This bug has been marked as a duplicate of bug 1834731 ***

(In reply to Michael Hampton from comment #2)
> I'm happy to co-maintain this, especially since you've based this on my
> previous work.

Please feel free to jump in and comaintain! Thanks.

If I may chime in, not an expert on Bitcoin, but I do follow some of the technical discussion in the community.

As I understand it, security of the distributed binary is of utmost importance.  I believe to that effect, upstream now builds its releases in reproducible builds (some info might be here: https://bitcoinops.org/en/topics/reproducible-builds/).  Unless Fedora can guarantee that the distributed binary will be identical to the upstream binary, or at least Fedora infrastructure will provide sufficient information to the user such that they can verify the Fedora packaged binaries aren't compromised, Fedora should not be including this in the repo.  Events since 2017 have shown this is an important concern.

(In reply to Suvayu from comment #54)
> Unless Fedora can
> guarantee that the distributed binary will be identical to the upstream
> binary

This can never happen. Libraries, compilers, etc. will be different. Based on the same logic there should be one and only Linux distribution that everybody uses.

> or at least Fedora infrastructure will provide sufficient
> information to the user such that they can verify the Fedora packaged
> binaries aren't compromised, Fedora should not be including this in the
> repo.  Events since 2017 have shown this is an important concern.

This can be guaranteed by the various chain of trust (builders, package signatures, etc.) and is easily verifiable. Putting this under doubt means saying the distribution can not be trusted at all and any binary/pacakge in it can be compromised easily.

(In reply to Simone Caronni from comment #55)
> (In reply to Suvayu from comment #54)
> > Unless Fedora can
> > guarantee that the distributed binary will be identical to the upstream
> > binary
> 
> This can never happen. Libraries, compilers, etc. will be different. Based
> on the same logic there should be one and only Linux distribution that
> everybody uses.

Sorry, here I misspoke slightly.  With reproducible builds already merged upstream, it should be possible to have binaries that are identical when built on a specific Fedora release, see comment #45 through comment #47 (also I linked to relevant resources in my original response).

> I've been packaging the software for myself for a few years now, if there is no answer to this ticket from the original poster I will re-create the review and close this as a duplicate.

Sorry. The original security reasons to strongly request that Fedora not ship bitcoin have not changed.

I'm working on a new status update and updated upstream recommendation.

(In reply to Warren Togami from comment #47)
> https://github.com/bitcoin/bitcoin/tree/master/contrib/guix
> The verifiable bootstrap and reproducibly built Bitcoin Core was merged a
> while ago. Linux builds work great today but they are working to fix their
> Windows and OS X cross compiled builds before the project switches to this
> method for releases.
> 
> If people want this to be packaged into Fedora first we need to get its
> buildsystem Guix accepted into Fedora. We might need FESCo approval for this
> or later Bitcoin-specific steps.
> 
> https://copr.fedorainfracloud.org/coprs/lantw44/guix/
> I have not tried this but somebody maintains it in COPR already.

https://twitter.com/dustyweb/status/1353459955861434368
Debian Unstable now ships Guix. This is how we can build binaries that are identical to upstream while eliminating possible security concerns about the buildroot.

Guix can be bootstrapped using standard build tools. So with some effort Guix could be bootstrapped on Fedora. It should become binary identical to Guix bootstrapped elsewhere. I'm looking into this but I would appreciate help to figure out how to get this packaged in Fedora.

https://salsa.debian.org/debian/guix/-/tree/debian/devel/debian
I'm told this is how Debian packaged Guix. It appears to be a proper bootstrap starting from guile.

I'm going to close this again as duplicate of #1834731
There's no need to have both open.

*** This bug has been marked as a duplicate of bug 1834731 ***