0

First, I tried downloading the source tarball openssl-1.0.1s.tar.gz from openssl.org and doing a ./config && make install, and although it seems to have completed the process successfully, I don't know where the compiled code went or if it got installed at all, because I still have a very old version of openssl linked in /usr/bin/, sothat didn't seem to work.

[root@E345 openssl]# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

Then, I tried downloading the rpm package and installing with rpm -Uvh and it seemed to install correctly, but with a ton of warnings, and the same exact result as above,

[root@E345 openssl]# rpm -Uvh openssl-1.0.1e-42.el7.9.src.rpm 
Updating / installing...
   1:openssl-1:1.0.1e-42.el7.9        ################################# [100%]
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root

There are about 30 or 40 of those same two warnings.

Again, after installing the rpm, the same output is given:

[root@E345 openssl]# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

What am I doing wrong / misunderstanding?

Edit: accidentally pasted the wrong OpenSSL version from another machine

7
  • Why are you trying to do this?! Apr 11, 2016 at 19:07
  • I'm compiling software that requires openssl with ECDSA. No version of openssl available through yum meets this requirement.
    – bvpx
    Apr 11, 2016 at 19:08
  • Eh? This includes ECDSA, the last time I looked (three seconds ago). Make sure you're up to date, as 1.0.1e-42 isn't the currently distributed version. Apr 11, 2016 at 19:09
  • yum check-update reports no updates available, even before I installed the new version. The system came with 1.0.1e-fips from Feb 2013. The rpm I downloaded, 1.0.1e-42, does include ECDSA, but installing it with rpm -Uvh didn't link the necessary libraries to /usr/bin and /usr/lib64 which is where yum, ssh, and other programs pull from. I ended up compiling openssl-1.0.1l and linking the libraries myself, which seems dangerous and weird, but it works.
    – bvpx
    Apr 11, 2016 at 19:36
  • If you're compiling software, you need openssl-devel. And yes, what you did is dangerous. Now your software has security vulnerabilities that have been fixed for a very long time. Apr 11, 2016 at 19:37

3 Answers 3

1

For what it is worth, it generally is a bad practice to compile custom packages on enterprise-level distribution. Most of the time, you should stick with the default distro packages, or only use trusted repositories.

The problem with compiling custom packages, and to directly use RPMs, is that each update is much more labor intensive and error prone than a simple yum update

1
  • Of course. However, the software I'm compiling requires a minimum version of openssl, and no version of openssl found in yum is compatible.
    – bvpx
    Apr 11, 2016 at 19:07
1

When you install from a tarball, many times the binary is installed in /usr/local. Probably your new openssl binary can be found in /usr/local/bin. Yet it would be easier to just install an rpm.

You installed a source rpm, which contains the sources but not the binaries. You need to look for openssl.x.y.z.rpm (and not openssl.x.y.z.src.rpm).

0

The 'user' warnings are not an issue.

Please do 'rpm -qil openssl' and 'which openssl'

I suspect you have multiple openssl versions installed. 'which openssl' will tell you which one your shell is using, and rpm will show you where the RPM version is installed. You will probably want to remove all but the RPM installation, but since I don't know the state of your system this may be dangerous.

5
  • which openssl returns /usr/bin/openssl, which is the 2013 binary. I think the issue I'm having is that the program I'm compiling links against the 2013 library rather than the 2016 library I installed. How can I find the library that corresponds with /usr/bin/openssl? Also, rpm -qil openssl reports back only the version I installed with rpm in my post above.
    – bvpx
    Apr 11, 2016 at 15:57
  • ldd /usr/bin/openssl will tell you which library it is using. Apr 11, 2016 at 16:07
  • Okay, it's still linking to the old library, it seems. I'm guessing it is the right idea to point the compiler to link to the new .so files that were compiled.
    – bvpx
    Apr 11, 2016 at 16:10
  • Its not clear what your rpm -Uvh did then, I'd expect that it would have in-place updated the binaries. Apr 11, 2016 at 16:24
  • For what it's worth, ldd and linking to the new library (the one I installed by extracting the tarball and ./config && make install) fixed the problem I was having. I'm not sure why /usr/bin/openssl never got replaced, but I'm assuming it's the right idea to simply replace the binary with the one in the bin directory created by my install. Not sure what happened with the rpm, either.
    – bvpx
    Apr 11, 2016 at 16:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .