On Wed, Aug 17, 2022 at 12:16 PM Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Wednesday, August 17, 2022 2:11 PM +0530 Vijay Maidarkar vmaidarkar@gmail.com wrote:
Hi, please keep replies on the list.
Find below answers.
Where is it installed? $ which openssl
/usr/local/bin/openssl
$ ldd /usr/local/bin/openssl linux-vdso.so.1 => (0x00007fff931e6000) libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f7f7a570000) libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f7f7a087000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f7f79e83000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7f79c67000) libc.so.6 => /lib64/libc.so.6 (0x00007f7f79899000) /lib64/ld-linux-x86-64.so.2 (0x00007f7f7a802000)
How was it installed? I've downloaded the archive & done compilation from below cmds.
$ ./config $ make $ make install
There are other options you should be using for OpenSSL. At minimum, you probably want enable-ec_nistp_64_gcc_128 on x86_64. Also see https://wiki.openssl.org/index.php/Compilation_and_Installation#Configure_Op... .
So, you built it yourself so there will be no development package. I'm not sure why you built such an ancient version of OpenSSL (you listed OpenSSL 1.1.1g when 1.1.1q is the most recent), since it's vulnerable to multiple critical CVEs.
I'd strongly advise using the packages from EPEL if you insist on staying on CentOS7 (which is near end of life).
If you are going to use your own OpenSSL build, I can't emphasize enough the importance of using a current release. Since you're doing this in an unpackaged way, maintenance is going to be a nightmare.
Since you've built it yourself into its own location, you have to tell the configure script where to find the development headers, like:
CPPFLAGS="/usr/local/include" LDFLAGS="-L/usr/local/lib -Wl,-rpath,/usr/local/lib" ./configure ...
+1 for the RPATH.
Linux (and other OSes) have a (mis)feature of building against one version of a library, and runtime linking against another version of the library. Be sure to specify the RPATH to avoid the bug.
(If you want to see the effects of linking against the wrong library at runtime, see https://www.openwall.com/lists/oss-security/2020/07/20/1).
Nowadays on Linux you should specify a RUNPATH, not a RPATH. The RUNPATH allows LD_LIBRARY overrides to search paths. It is recommended by the folks who write the runtime loaders. The options you need are:
* -Wl,-rpath,<lib path> (enables RPATH) * -Wl,--enable-new-dtags (enables RUNPATH)
Jeff
--On Wednesday, August 17, 2022 1:31 PM -0400 Jeffrey Walton noloader@gmail.com wrote:
Nowadays on Linux you should specify a RUNPATH, not a RPATH. The RUNPATH allows LD_LIBRARY overrides to search paths. It is recommended by the folks who write the runtime loaders. The options you need are:
- -Wl,-rpath,<lib path> (enables RPATH)
- -Wl,--enable-new-dtags (enables RUNPATH)
If building into a custom (non-OS) location, you definitely want to avoid --enable-new-dtags, as the builds then use the local system libraries and not the libraries you built, causing mayhem.
Regards, Quanah
openldap-technical@openldap.org