Bitcoin RPM packages for Fedora and Red Hat Enterprise Linux

[error]

Now available: Bitcoin for Fedora and Red Hat Enterprise Linux

Quick Start:

• Install the bitcoin-release RPM for RHEL or Fedora.
• Install the bitcoin package for the Bitcoin GUI, or the bitcoin-server package for bitcoind, using yum install <packagename>.
• If using bitcoind, start it with run_init service bitcoin start as root (on Fedora, use systemctl start bitcoin.service instead), and chkconfig bitcoin on (on Fedora, use systemctl enable bitcoin.service) to enable automatic startup.
• If using bitcoin GUI, click the icon in your applications menu. You should find it filed under Office.

Info:

I am pleased to present Bitcoin RPM repositories for Fedora and Red Hat Enterprise Linux.

These repositories provide OpenSSL with EC support, resolving the primary issue holding back Bitcoin builds for Fedora and RHEL. They also provide an SELinux-enhanced bitcoin daemon, protecting the server's Bitcoin wallet against unexpected exploits of other system services. The whole stack has undergone nearly two months of testing prior to today's announcement to ensure system compatibility and security.

More information and a FAQ can be found at the repository homepage.

Of particular note, bitcoind as distributed here has some important differences from that distributed by the project. The primary differences are SELinux support and having bitcoind store all its files in standard locations such as /etc/bitcoin and /var/lib/bitcoin. It is otherwise unmodified.

Known Issues:

• The system tray icon is blank when running bitcoin-qt under GNOME. (It appears normally under KDE.) This seems to be an upstream issue.

Donate:

If you approve of this project and wish it to continue, send donations to 17fDs8d2ACKhfwGHMADpWtBGiU6WneyxkZ , click on the image above with a bitcoin URL-enabled client, or scan its QR code. If this helps you build a more secure Bitcoin service, send a big donation.

[1713434349]

1713434349

[1713434349]

1713434349

[marcus_of_augustus]

Can you confirm that installing your RPM will remove the system libraries for OpenSSL (libssl and libcrypto) and install your own versions in its place?

[error]

Can you confirm that installing your RPM will remove the system libraries for OpenSSL (libssl and libcrypto) and install your own versions in its place?

It did on all of my test boxes. I spent almost a full day on making sure this worked.

This Bitcoin repository ships separate OpenSSL packages which do not replace the system packages and are reserved for the exclusive use of the Bitcoin daemon and Qt GUI.

[marcus_of_augustus]

Can you confirm that installing your RPM will remove the system libraries for OpenSSL (libssl and libcrypto) and install your own versions in its place?

It did on all of my test boxes. I spent almost a full day on making sure this worked.

Ok thanks for confirming that ... different people with different trust levels will view this fact differently but probably a big, fat red warning is in order to make it clear to users that this is what will happen.

E.g. if you have ever tried to remove OpenSSL from your system (I do not recommend you do this btw!) you will notice how many security critical programs require these libraries as a dependency ... putting a binary libssl and libcrypto from a dev. other than official repo will be a big leap of trust for an enterprise server system administrator, just for example.

[error]

Yeah, don't ever remove OpenSSL or you'll break your system beyond repair.

I spent a very long time testing everything I could to ensure the replacement libraries would work 100% with other existing programs on the system. (Which is partly why they're the 1.0.0 branch and not 1.0.1.) So far so good.

As for trust, that's why there are source RPMs. If you unpack it and look around you will find an OpenSSL source tarball which is completely pristine (unlike Red Hat's which has been heavily stripped). I would have liked to avoid having to ship OpenSSL, but there was no good way to do so. Fortunately it looks like Red Hat might finally fix this problem soon (it's tied up in their legal department right now). Once they do, I will be happy to not have to ship OpenSSL.

[error]

Now that this has been out a couple of days with zero issues reported, (and I haven't lost all my bitcoins either! I run this code myself) I'd like to ask your comment on:

What other Bitcoin-related software needs to be made available for Red Hat/Fedora?

Right now I am considering Electrum, MultiBit and Armory clients. I don't normally use any of these, so there will be a short delay in getting any of them packaged.

In addition to alternative clients, what else should be packaged for distribution?

[2112]

Now that this has been out a couple of days with zero issues reported,

Only yourself and desperadoes would try your RPMs. May I suggest that:

1) don't replace any RedHat libraries, everything private should
be linked with "-rpath" to a private directory or "$ORIGIN"
2) don't run bitcoind as root, but as a regular user (despite all your SELinux configuration)

or:

3) get yourselves hired at RedHat

Good luck.

[error]

Since you didn't even bother to look, you are probably unaware that I do not run bitcoind as root.

Not replacing a system library is a good idea; it just turns out to be much harder than you think it is.

[2112]

Since you didn't even bother to look, you are probably unaware that I do not run bitcoind as root.

I apologise, I was wrong. Indeed the /etc/rc.d/init.d/bitcoin starts the app as user "bitcoin". I couldn't find any "useradd" and "groupadd" calls, but they are there in the RPMs. As it turns out my rpm2cpio tool is buggy and doesn't do the proper conversion for some RPMs. It appears that the packaged files are owned by "root", but it may be another bug in my tool. As you may have expected I wouldn't dare to actually install the RPM.

[error]

I apologise, I was wrong. Indeed the /etc/rc.d/init.d/bitcoin starts the app as user "bitcoin". I couldn't find any "useradd" and "groupadd" calls, but they are there in the RPMs. As it turns out my rpm2cpio tool is buggy and doesn't do the proper conversion for some RPMs. It appears that the packaged files are owned by "root", but it may be another bug in my tool. As you may have expected I wouldn't dare to actually install the RPM.

The packaged files are supposed to be owned by root. That's bog standard security. The binaries should not have access to modify themselves.

There's a fine line between distrust and paranoia. It's very easy to verify that the RPMs are good. That's why we have source RPMs in the first place. A distrustful person would inspect the source RPMs carefully to ensure there was no funny business going on, and perhaps rebuild them himself if they appeared OK.

[2112]

The packaged files are supposed to be owned by root. That's bog standard security. The binaries should not have access to modify themselves.

I'm sorry, I was expecting "bin:bin" not "root:root" as the owner of the read-only files.

There's a fine line between distrust and paranoia. It's very easy to verify that the RPMs are good. That's why we have source RPMs in the first place. A distrustful person would inspect the source RPMs carefully to ensure there was no funny business going on, and perhaps rebuild them himself if they appeared OK.

The main motivation is neither distrust nor paranoia. The main problem with the RedHat package manager is the difficulty of recovering from the situation where a RHN system update kills customer's own applications. The secondary problem is that by replacing an RH-provided library you implicitly break the RedHat's service contract agreement; i.e. RedHat gets off the hook on the support of such a system.

The ternary problem (but for me primary problem) is basically a replay of the "Windows DLL hell" game under another operating system. I'm not going to play it and would not recommend anyone to play it unless they get paid by the hour for refixing the same problems. Side-by-side is the way to go and Linux supports it fairly well (using -rpath and $ORIGIN).

I say all this as a long-time RedHat Partner.

[error]

I'm sorry, I was expecting "bin:bin" not "root:root" as the owner of the read-only files.

The result is much the same either way.

The main motivation is neither distrust nor paranoia. The main problem with the RedHat package manager is the difficulty of recovering from the situation where a RHN system update kills customer's own applications. The secondary problem is that by replacing an RH-provided library you implicitly break the RedHat's service contract agreement; i.e. RedHat gets off the hook on the support of such a system.

This is a valid concern for people running RHEL. A bit less so for those running CentOS or another clone, since they aren't getting support anyway.

The ternary problem (but for me primary problem) is basically a replay of the "Windows DLL hell" game under another operating system. I'm not going to play it and would not recommend anyone to play it unless they get paid by the hour for refixing the same problems. Side-by-side is the way to go and Linux supports it fairly well (using -rpath and $ORIGIN).

This is a reasonable concern. I hate DLL hell myself, and I'm perfectly willing to give this another go. I actually tried this at first, and RPM did not want to cooperate. So I'll beat on it some more.

[2112]

This is a reasonable concern. I hate DLL hell myself, and I'm perfectly willing to give this another go. I actually tried this at first, and RPM did not want to cooperate. So I'll beat on it some more.

Thank you for your understanding. I know my position on software updates isn't the most common, but it did and it does hold the value pretty well.

May I suggest that you also "privatize" boost:: ? My reasoning is the same and I know that the potential market (for consulting, support, etc.) would greatly increase. I'm not on the market myself, but I see people needlessly shutting themselves out and find that regretfull. This really depends on the default GNU compiler for particular RHEL, not on the boost:: itself. But if you already have a test installations then the additional work required is fairly small.

Admittendly I'm somewhat extreme in software conservatism having supported RHEL2.1 until the beginning of this year. The money was good, and the savings for my clients (from e.g. not upgrading ColdFusion from Macromedia to Adobe) were staggering.

[error]

May I suggest that you also "privatize" boost:: ? My reasoning is the same and I know that the potential market (for consulting, support, etc.) would greatly increase. I'm not on the market myself, but I see people needlessly shutting themselves out and find that regretfull. This really depends on the default GNU compiler for particular RHEL, not on the boost:: itself. But if you already have a test installations then the additional work required is fairly small.

Don't use the system provided Boost library?! There's nothing wrong with it, as far as I know. Or did you mean something else?

[2112]

Don't use the system provided Boost library?! There's nothing wrong with it, as far as I know. Or did you mean something else?

I took the following quote at the face value, maybe incorrectly.

Q. Do you support Red Hat Enterprise Linux 5?

A. I have no plans to support Red Hat Enterprise Linux 5 at this time. Certain libraries (such as Boost) included with RHEL5 are too old to support current versions of Bitcoin and cannot be safely updated without risking breakage to other parts of the existing system.

I'm familiar with the "upgrade treadmill" as a way of revenue pumping and padding the billable hours, but my position is that the only way to win is to not play. I'm positive that RedHat will change the key libraries from underneath of your program, so prepare early. Ubuntu does that all the time, but the core developers are happy to play.

Edit: I'm not proposing that you support GNU C++ 2.96 and RH7.2/RHEL2.1; but I see that RedHat still actively supports it in RHEL6. Apparently they have enough customers/partners who refused to jump on the treadmill:

compat-libstdc++-296-2.96-144.el6.i686.rpm

2010-05-17 - Jakub Jelinek  <...> 2.96-144
- ensure libstdc++.so is linked with -Wl,-z,noexecstack (#592519)
2010-04-26 - Dennis Gregorovic <...> - 2.96-143.2
- Rebuilt for RHEL 6
Related: rhbz#566527

The above is just one of the things I had memorized from many years ago. I actually never installed that release except in virtual machines. But I see that the general strategy is still working for many of the RedHat's customers/partners.

[error]

Ah, OK, so that is what you meant. Sure it would make it easy to build it on EL5. Probably be a couple of days before I can get around to that part, though.

Though I don't really expect somebody to be dumb enough to use an ancient OS for a new project, I suppose it could happen...

[2112]

Though I don't really expect somebody to be dumb enough to use an ancient OS for a new project, I suppose it could happen...

I can assure you that RHEL5.* is widely used, probably still even more than RHEL6.* . Think of all the people who already have things/projects going on for them and making money (or at least sleeping peacefully at night). They were maybe thinking of adding Bitcoin to them as a trial. The stridency of the core developers with respect to supporting only the most recent Ubuntu was really off-putting for them.

[error]

Though I don't really expect somebody to be dumb enough to use an ancient OS for a new project, I suppose it could happen...

I can assure you that RHEL5.* is widely used, probably still even more than RHEL6.* . Think of all the people who already have things/projects going on for them and making money (or at least sleeping peacefully at night). They were maybe thinking of adding Bitcoin to them as a trial. The stridency of the core developers with respect to supporting only the most recent Ubuntu was really off-putting for them.

EL5 hasn't reached end of life yet. I was thinking of EL4 and prior, old versions of Fedora, and maybe Windows 2000 Datacenter, all of which I've seen in active use recently.

[Daily Anarchist]

The Bitcoin-release-1.4 is an older version of Bitcoin, right? It's not 0.7.0?

So, there's no way to get 0.7.0 on my Fedora 17?

[marcus_of_augustus]

The Bitcoin-release-1.4 is an older version of Bitcoin, right? It's not 0.7.0?

So, there's no way to get 0.7.0 on my Fedora 17?

You can run with the multiply signed binaries the dev team publishes.
Or you can build (or otherwise install somehow) a local version of openssl with ecdsa support and build bitcoin 0.7.0 locally upon that.