For debian you can do this with policy-rc.d. Here's one explanation:
A package’s maintainer scripts are supposed to only interface with the init system by means of invoke-rc.d, update-rc.d and the LSB init script headers...
invoke-rc.d will, before taking its action, check whether
/usr/sbin/policy-rc.d is executable, will call it with the respective
service name and the current runlevel number on its command line and
act according to its exit code. For example, a return value of 101
will prevent the planned action from being taken. This includes the
automated start of the service upon package installation as well as
the stop of the service on package removal and reduces the
stop-upgrade-restart ritual during package upgrades to just performing
the upgrade which might leave the old version of the service running
Since you don't want any services to ever start, your policy-rc.d script can be simply
#!/bin/sh
exit 101
This is the technique used by tools like pbuilder and Docker's mkimage-debootstrap.
Unfortunately, this technique does not work with Ubuntu chroots. Packages that integrate with the upstart init system call /usr/sbin/initctl instead of invoke-rc.d during installation, and initctl doesn't consult policy-rc.d. According to upstart's author the workaround is to replace /sbin/initctl with a symlink to /bin/true in a chroot. You can see this in mkimage-debootstrap as well, they do
dpkg-divert --local --rename --add /sbin/initctl
ln -sf /bin/true sbin/initctl
Based on the date displayed by your version of OpenSSL, it seems you are seeing the full version displayed there.
Open SSL 1.0.1 was released on March 14th, 2012. 1.0.1a was released on April 19th of 2012.
So, I'm going to go ahead and assert that openssl version -a
is the proper, cross-distro way to display the full version of OpenSSL that's installed on the system. It seems to work for all the Linux distros I have access to, and is the method suggested in the help.ubuntu.com OpenSSL documentation, as well. Ubuntu LTS 12.04 shipped with vanilla OpenSSL v1.0.1, which is the version that looks like an abbreviated version, on account of not having a letter following it.
Having said that, it appears that there is a major bug in Ubuntu (or how they package OpenSSL), in that openssl version -a
continues to return the original 1.0.1 version from March 14, 2012, regardless of whether or not OpenSSL has been upgraded to any of the newer versions. And, as with most things when it rains, it pours.
Ubuntu is not the only major distro in the habit of backporting updates into OpenSSL (or other packages), rater than relying on the upstream updates and version numbering that everyone recognizes. In the case of OpenSSL, where the letter version numbers represent only bug fix and security updates, this seems nearly incomprehensible, but I have been informed that this may be because of the FIPS-validated plugin major Linux distros ship packaged with OpenSSL. Because of requirements around revalidation that trigger due to any change, even changes that plug security holes, it is version-locked.
For example, on Debian, the fixed version displays a version number of 1.0.1e-2+deb7u5
instead of the upstream version of 1.0.1g
.
As a result, at this time, there is no reliable, portable way to check SSL versions across Linux distributions, because they all use their own backported patches and updates with different version numbering schemes. You will have to look up the fixed version number for each different distribution of Linux you run, and check the installed OpenSSL version against that distribution's specific version numbering to determine if your servers are running a vulnerable version or not.
Best Answer
It seems that
sg3_utils
package is what you're looking for: