rabbitmq / erlang-rpm

Latest Erlang/OTP releases packaged as a zero dependency RPM, just enough for running RabbitMQ
https://rabbitmq.com/install-rpm.html
Other
545 stars 117 forks source link

CentOS 7.3 does not provide OpenSSL 1.0.2 or later #83

Closed henryon closed 5 years ago

henryon commented 5 years ago

I am trying to install erlang-21.1.1-1.el7.centos.x86_64.rpm on centos7.3 but I met below errors

warning: erlang-21.1.1-1.el7.centos.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID 6026dfca: NOKEY error: Failed dependencies: libcrypto.so.10(OPENSSL_1.0.2)(64bit) is needed by erlang-21.1.1-1.el7.centos.x86_64

And I found opensl1.0.2 supported on centos7.6 but centos7.3. Do we have workround for centos7.3 with openssl version is 1.0.1? Thanks.

michaelklishin commented 5 years ago

Thank you for your time.

Team RabbitMQ uses GitHub issues for specific actionable items engineers can work on. GitHub issues are not used for questions, investigations, root cause analysis, discussions of potential issues, etc (as defined by this team).

We get at least a dozen of questions through various venues every single day, often light on details. At that rate GitHub issues can very quickly turn into a something impossible to navigate and make sense of even for our team. Because GitHub is a tool our team uses heavily nearly every day, the signal/noise ratio of issues is something we care about a lot.

Please post this to rabbitmq-users.

Thank you.

michaelklishin commented 5 years ago

I doubt it. The minimum supported OpenSSL version is an Erlang's crypto module requirement, not something this package imposes (although it was produced on a CentOS version newer than 7.3 for sure).

To my knowledge 1.0.2 and 1.1.x should both work fine, at least that's what our Chef cookbook suites use (they provision Erlang using this package on some RPM-based distributions).

I couldn't find a backports repository for CentOS 7.3 but newer OpenSSL versions can be built from source (one, two).

@dumbbell do you have anything to add?

michaelklishin commented 5 years ago

I quick search reveals plenty of discussions around OpenSSL 1.0.2 on CentOS 7.3 and the suggestion from most maintainers is: use a newer CentOS release, otherwise you won't get any security patches. Fair enough.

dumbbell commented 5 years ago

Hi! No, I don't have anything to add.

henryon commented 5 years ago

@michaelklishin Thanks for reply and update. It's harder for me to upgrade existing OS. So my question becomes how should we support erlang with openssl lower version 1.0.1 instead of 1.0.2.

It's no doubt we need upgrade OS version. But for those who can't or don't willing upgrade OS. the Openssl Version become a blocker for use erlang. It's not acceptable. IMHO.

henryon commented 5 years ago

@michaelklishin or is there any version erlang using Openssl 1.0.1?

michaelklishin commented 5 years ago

@henryon I'm afraid our team won't support OpenSSL 1.0.1 even if you find it "unacceptable". CentOS 7.3 is 3 years old. A lot has happened to OpenSSL in the last 3 years and most software (including Erlang/OTP) moved on to require latest versions because of a broad range of vulnerabilities discovered in older releases. This trend is not going to revert. So if you want to stick to an old CentOS release, provisioning a compatible OpenSSL version is on you, not on us.

RabbitMQ documentation mentions where recent Erlang releases can be installed from. You can try earlier versions and/or Erlang Solutions packages. I doubt the outcome would be different since IIRC Erlang started requiring recent OpenSSL versions starting with 20.0.

Every recent patch of 21.x, 20.x of this package was produced with at least OpenSSL 1.0.2. 19.x might still support OpenSSL 1.0.1 but it is no longer supported by recent RabbitMQ releases.

One relatively easy way out is to run RabbitMQ in Docker on a CentOS 7.3 host. The image ships with the latest versions of OpenSSL and Erlang/OTP. It does not use CentOS and has it own complications and limitations but at least it is an option.

I'm locking this because our team does not use GitHub issues for discussions and there are no plans to support OpenSSL 1.0.1 in this package. Sorry.