Bitcoin RPM packages for Fedora and Red Hat Enterprise Linux - page 5.

2112

legendary

Activity: 2128

Merit: 1073

Quote from: error on August 25, 2012, 04:44:52 PM

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

hero member

Activity: 588

Merit: 500

Quote from: 2112 on August 25, 2012, 04:33:09 PM

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.

Quote from: 2112 on August 25, 2012, 04:33:09 PM

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.

Quote from: 2112 on August 25, 2012, 04:33:09 PM

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

legendary

Activity: 2128

Merit: 1073

Quote from: error on August 25, 2012, 04:06:57 PM

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.

Quote from: error on August 25, 2012, 04:06:57 PM

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

hero member

Activity: 588

Merit: 500

Quote from: 2112 on August 25, 2012, 03:39:23 PM

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

legendary

Activity: 2128

Merit: 1073

Quote from: error on August 25, 2012, 02:39:55 PM

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

hero member

Activity: 588

Merit: 500

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

legendary

Activity: 2128

Merit: 1073

Quote from: error on August 25, 2012, 12:35:02 AM

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

hero member

Activity: 588

Merit: 500

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?

error

hero member

Activity: 588

Merit: 500

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.

marcus_of_augustus

legendary

Activity: 3920

Merit: 2349

Eadem mutata resurgo

Quote from: error on August 23, 2012, 05:20:39 PM

Quote from: marcus_of_augustus on August 23, 2012, 05:08:51 PM

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

hero member

Activity: 588

Merit: 500

Quote from: marcus_of_augustus on August 23, 2012, 05:08:51 PM

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

legendary

Activity: 3920

Merit: 2349

Eadem mutata resurgo

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

hero member

Activity: 588

Merit: 500

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 .
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. Grin

Topic: Bitcoin RPM packages for Fedora and Red Hat Enterprise Linux - page 5. (Read 31450 times)