Incorrect software versioning in official packages causes consternation and confusion for system administrators when installing or updating dependencies via package managers. This article seeks to raise awareness for this issue by demonstrating how false version self-identification of software embedded in official packages leads to confusion. When a program self-reports its version information incorrectly, and that program is a dependency for other programs or functions, it may impact the behavior of those upstream programs. Furthermore, system administrators may make decisions based on false versioning information, potentially creating unnecessary work and/or prompting sysadmins to manually affect other software based on the false information they have received. Regardless of your viewpoint on the potential negative impacts, incorrect versioning is certainly not a positive outcome.
This is a sister article to Clear as Mud: OpenSSL and Ubuntu's Versioning System
Poor Version Reporting Practices Create Confusion
As programs are created and updated, a best practice in software development is to assign unique version numbers to each iteration. However, whether or not a program reports that version number accurately when queried depends on the programmer. It appears the latter step is not occurring with some Ubuntu packages.
Even though the underlying code is occasionally patched and updated, it appears the version numbering system inside the code is not. At the very least, the portion of code where such programs self-report their version information is not being updated, resulting in incorrect version reporting to users. OpenSSL is a good example of this phenomenon.
To prove my point, below are two (2) versions of OpenSSL that demonstrate this problematic behavior in Ubuntu 16.04. The reported major version is correct, but in both cases the minor version is not.
Reported Version 1.0.2g | Actual Version 1.0.2p
OpenSSL package version 1.0.2g-1ubuntu4.13 installs OpenSSL version 1.0.2p, but Ubuntu reports incorrectly as 1.0.2g.
OpenSSL pushed changes into minor version update v1.0.2p:
And corresponding update in Ubuntu package change log:
Astute readers will notice the Ubuntu patch details shown above precede the OpenSSL minor version patch by two (2) months, which is interesting. You can see the CVE (Common Vulnerabilities and Exposures) references patched in the Ubuntu package and the OpenSSL update are the same. Even though the date of the Ubuntu patch precedes the OpenSSL patch, the fact remains Ubuntu's patches continue to mirror OpenSSL's global patches. Yet, Ubuntu continues to (incorrectly) report the pre-patch minor version of OpenSSL when queried.
To wit, after installation, OpenSSL falsely reports version 1.0.2g
Reported Version 1.0.2g | Actual Version 1.0.2r
The same problem is observed in a later patch, indicating this was not an isolated oversight.
OpenSSL pushes changes into a minor version update v1.0.2r:
Updating OpenSSL to 1.0.2r, note the installer package version changes. The changelog indicates OpenSSL bug fixes were added.
After installing a new version, one would expect the version reported by OpenSSL in Ubuntu to also update. Alas, OpenSSL is still falsely reporting version 1.0.2g. Even after a reboot, the incorrect version number is still reported when prompting the process to self-report.
Minor Versions Matter Too
Naturally, the major version of a software program is most crucial. However, in many cases, minor versions are significant as well; particularly with regards to security updates. When a program's self-reported version number is not aligned with its version number as indicated in the source code, this causes the user to believe their installed code is different from what it is. This defeats the entire point of versioning to begin with.
Here are examples of problems that can occur in upstream programs when their dependencies report incorrect version information:
- Automated installers apply incorrect program versions or features
- System administrators manually apply wrong software update or upgrade
- Features in other programs are disabled that shouldn't be
- Automated installation methods fail
- Unnecessary program updates are triggered, when the program is already up-to-date
Bad versioning information creates an environment where the risk of automated installers behaving incorrectly is heightened. Diligent system administrators may be misled, potentially installing the wrong version of other programs. Installers may inadvertently skip features, believing a program dependency doesn't exist. Incorrect versioning data in dependency programs delivers bad data to upstream programs and processes. Those programs or their installers could make branching decisions based on that bad data, potentially resulting in muted functions or removing functional support entirely, which ostensibly should have been included or activated. Likewise, the opposite may occur. For example, program updates may attempt to update or upgrade a dependency, not realizing the update has already been performed due to incorrect version reporting.
Why Accurate Versions Are Important
Confused about which version of OpenSSL you have installed on your Ubuntu server? Or should install? Which one is "current" and how to get it?
Ubuntu's install package naming system begets confusion because it is divided into roughly three (3) types of naming conventions:
- Install package names (e.g. openssl 1.0.2g-1ubuntu4.15 in s390x)
- Binary package name (e.g. openssl_1.0.2g-1ubuntu4_amd64)
- Core program version number (e.g. OpenSSL 1.0.2g)
That might not seem so complicated or a big deal. However, if you dig into these versions and examine the programs in the install packages more closely, you find that the version numbers don't always correlate between what the program claims is its version number, compared to the features it supports. What if I told you there were 15 different releases of binaries over several years, and all of them report identical version number of OpenSSL after installation? How does that help the end user to understand which version of OpenSSL they have? It doesn't. It implies that different sets of binaries installed over three (3) years after the first one are the same code, yet as I've just proven, they are not the same. This is a poor versioning practice, and a disservice to the end user.