I am replying to provide the community with an update to this situation just in case it will help anyone else in the future or just in case anyone was curious about how I proceeded. I was able
to prove that we had other transitive dependencies on openssl that resulted in multiple versions of libssl and libcrypto being loaded at run time. I was able to work around it by writing some code to force the version I want to use to be loaded first which
helped to confirm the root cause.
Since we happen to use gdal libraries which has a lot of dependencies we found that it was going to be near to impossible to continue using the openssl 1.0.2 series of software on RHEL8. We
were able to rebuild a few dependencies to ensure that many were linking with the version we wanted to distribute. However I was finding one thing after another that I would need to rebuild. Some of those were dependent on other software installed to the
operating system which depended on the SSL installed to the system. I concluded that we need to just upgrade to OpenSSL 1.1.1 and move on. We don’t seem to have a large number of breaking changes to resolve so we are upgrading.
Thanks,
Shawn Fox
From: Shah, Amul <Amul.Shah@xxxxxxxxxxxxx>
Sent: Friday, December 8, 2023 7:22 AM
To: Jan Just Keijser <jan.just.keijser@xxxxxxxxx>; Fox, Shawn D (US) <shawn.fox@xxxxxxxxxxxxxx>; openssl-users@xxxxxxxxxxx
Subject: Re: Question about Open SSL 1.0.2 series compatibility
|
External Email Alert
|
|
This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report
phishing by clicking the button “Report Phishing” on the Outlook toolbar.
|
[sorry for the top post]
Fedora maintains its EPEL (Extended Packages for Enterprise Linux) which includes OpenSSL 1.1.1 for RHEL 7 (https://packages.fedoraproject.org/pkgs/openssl11/openssl11-libs/epel-7.html).
The files are versioned and do not override the default OpenSSL 1.02 installation. That could be an option for you and your customers. Looking at my RHEL 8 host and the file listing of the EPEL OpenSSL 1.1.1 package, the libraries have the same version name
(1.1.1k) and should work.
We’re facing a similar issue with partners dragging their feet. RHEL 7 is in extended support and RHEL 8 will exit regular support next year. On top of that, OpenSSL 1.1.1 line is deprecated. Our team is encouraging
partners to skip RHEL 8 and go straight to RHEL 9.
Hope this helps,
Amul
Hi there,
On 07/12/2023 19:22, Fox, Shawn D (US) via openssl-users wrote:
Yes the idea is to get our customers off of RHEL7, but we have to get our software working on RHEL8 first. We will have some overlap where we release SW that runs on either by producing two
different sets of binaries. We’ll have to wait until our customers agree that we can stop building releases for RHEL7.
We do link to the dynamic libraries which I didn’t mention before and when we setup our execution environment we do update LD_LIBRARY_PATH. I would think that would resolve conflicts as the
applications would then find our custom installation of openssl first. We have done something similar on RHEL7 using a slightly older version than what RHEL7 has installed to the system and that worked so I hoped that building v1.0.2u would be possible. I’m
trying to find a least common denominator that will work on RHEL7 and RHEL8 until we can move on from RHEL7.
The function PEM_read_X509 seems to be the root my issue. On RHEL8 it doesn’t populate the out parameter the same way and it results in a downstream seg fault. I have not been able to find
where that function is defined. I used grep on the openssl code and couldn’t find a function definition to read. If anyone could help me understand why that is, I would appreciate it. It doesn’t look like a MACRO but perhaps it is exported from somewhere
but I cannot find the function implementation so that I can read the code and figure out how to debug it. I’ve built openssl with debug symbols, and I cannot step into that function with ‘gnu ddd’ nor can I figure out how to navigate to the function implementation.
FWIW:
PEM_read_X509 comes from `include/openssl/pem.h` (in conjunction with `crypto/pem/pem_lib.c` and pem_x509.c):
IMPLEMENT_PEM_rw(X509, X509, PEM_STRING_X509, X509)
resulting in
309 # define IMPLEMENT_PEM_rw(name, type, str, asn1) \
310 IMPLEMENT_PEM_read(name, type, str, asn1) \
311 IMPLEMENT_PEM_write(name, type, str, asn1)
resulting in
305 # define IMPLEMENT_PEM_read(name, type, str, asn1) \
306 IMPLEMENT_PEM_read_bio(name, type, str, asn1) \
307 IMPLEMENT_PEM_read_fp(name, type, str, asn1)
leading to
221 # define IMPLEMENT_PEM_read_fp(name, type, str, asn1) \
222 type *PEM_read_##name(FILE *fp, type **x, pem_password_cb *cb, void *u)\
223 { \
224 return PEM_ASN1_read((d2i_of_void *)d2i_##asn1, str,fp,(void **)x,cb,u); \
225 }
which, as far as I can tell, results in
X509 *PEM_read_X509(FILE *fp, X509 **x, pem_password_cb *cb, void *u)\
{
return PEM_ASN1_read((d2i_of_void *)d2i_X509, PEM_STRING_X509,fp,(void **)x,cb,u); \
}
(I am sure I am missing some substitutions here).
Having said that:
- yes, you can build and link OpenSSL 1.1.1 (or OpenSSL 3+) on RHEL7 but *don't* try to replace system libssl.so/libcrypto.so libraries - it will break your RHEL support.
- yes, you can build and link the fully obsolete OpenSSL 1.0.2 on RHEL8 but again, *don't* try to replace system libssl.so/libcrypto.so libraries - it will break your RHEL support.
- openssl 1.0.2 and 1.1.1. are (rather subtly) API incompatible, so don't mix and match
- my advice is to build and link statically using your own build of OpenSSL 1.1.1 - RedHat tends to apply tons of patches to OpenSSL
HTH,
JJK
My understanding is that openssl does not guarantee binary compatibility at major releases.
A big value-add of the distros like RHEL is that they recompile everything and guarantee that it all works. Replacing with a custom openssl, or any other system library, will probably break applications.
I would try either static link to your old version or link to a local old version, but not install openssl in the system area.
The ideal solution would be to get your customers off RHEL7, which was end of life 3 years ago, but you may have no choice.
I’m supporting a project that has been using the openssl 1. 0. 0 series built for RHEL7 for some time now. OpenSSL 1. 1. 1 has breaking API changes, so I’ve built OpenSSL 1. 0. 2u for starters in
order to upgrade to that version first,
I’m supporting a project that has been using the openssl 1.0.0 series built for RHEL7 for some time now. OpenSSL 1.1.1 has breaking API changes, so I’ve built OpenSSL 1.0.2u for starters in order to upgrade
to that version first, but I am building for both RHEL7 and RHEL8. I have a couple of questions that I haven’t found answers for searching the web yet.
Is OpenSSL 1.0.2 compatible with native apps built for RHEL8? Although it might not be ideal can it work on RHEL8? I’ve built it on RHEL8 and I have used the openssl binary to read some cert files with the
x509 sub-command, and it seems to produce the same results on RHEL7 and RHEL8 using the program from within bash shell. That leads me to believe that I should be able to link a native c++ app with openssl 1.0.2u and run that on RHEL8 successfully.
Is OpenSSL 1.1.1 compatible with RHEL7?
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii)
do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank
you. Message Encrypted via TLS connection
|
