 |
Thank you for the report. You appear to be reporting a bug on an issue pertaining to your application and custom compiled openssl and openssh libraries, and its interactions with your system. Unfortunately in this case, we cannot assist nor debug your issue because you are compiling custom libraries and software of packages we already ship. We can only support the packages that we build and ship to our users. My recommendation is to use the distribution provided packages and find a way to have your application use the system libraries. |
 |
I am not reporting a bug with any custom application. This issue is debugged. It is caused by patches applied the the krb5/openssl libraries on the operating system. Users should be able to use their own openssl libraries with their applications on an Enterprise Linux without losing the ability to use basic glibc calls to lookup user information. There are lots of workarounds. But its fair to expect that your existing RHEL 7 compatible application that provided additional library support runs under rockylinux8. You are REQUIRED need to patch to at least up to these patches from SRPM to make a functional openssl. $ ls -1 patches/ openssl-1.1.1-evp-kdf.patch openssl-1.1.1-fips.patch openssl-1.1.1-krb5-kdf.patch openssl-1.1.1-ssh-kdf.patch |
 |
Thank you for following up on this issue. I understand your concerns regarding the interaction between custom-compiled libraries and the patches in our distributed packages. However, Enterprise Linux systems are designed with a specific set of integrated libraries, and our support aligns with the use of these system-provided components. The behavior you're experiencing stems from the use of custom versions of libraries such as OpenSSL, which introduces incompatibilities with the system's patched versions. It is standard practice in Enterprise Linux environments to rely on system libraries to ensure compatibility and support. Transitioning software between major versions, like RHEL 7 to Rocky Linux 8, often involves changes that aren't backward compatible on a binary level. This is reflective of the different system architecture and security enhancements made over the years. We recommend utilizing the system-provided versions of OpenSSL to maintain stable and supported operations. If specific functionality from your custom versions is needed, we suggest exploring adjustments to align with the system's library compatibility. We appreciate the effort and the technical challenges involved in managing library dependencies across different enterprise environments. Although our team is unable to support non-standard configurations, the community forums or mailing lists can be valuable resources for finding potential solutions or workarounds shared by other users. If you have any further questions or need assistance with supported configurations, please let us know. We're here to help where we can. Thank you for your understanding. |
|
|
This was the first EPEL release that did not change the soname https://git.rockylinux.org/staging/src-rhel/rpms/openssl/-/blob/c8/SPECS/openssl.spec?ref_type=heads#L12 Seems like it was know that the symbol changes would be an issue but the same so version was used. Whats the point in having multiple RHEL flavors? Doesnt seem like support is a selling point. |
|
|
Go ahead and close this. I had low expectations for any resolution, but figured it would at least try to bring attention to the problems that can be created by the distribution adding symbols to standard libraries. Who would possibly still be using NIS in 2025 and porting forward openssl built on older glibc? Hopefully adding symbols isnt something we see more of in future releases, but I guess we will have to see what redhat/centos do. LD_PRELOAD=/usr/lib64/libcrypto.so is probably the best solution for other people who cant build their own krb5 to avoid this problem. |
- Anonymous
