3

Recently, to deal with newly revealed SSL bugs I upgraded my pure Debian distribution. OpenSSL reports a version number of 1.0.1e which is not the latest, however, I am told that it is ok, because the reported build time produced by:

openssl version -b

is June 4, 2014. So, even though the "version" is older, I am assured that Debian somehow "patched" the vulnerabilities, so I don't actually need 1.0.1h as security posts claim, because my 1.0.1e is patched.

I guess I don't understand this. Can anybody explain what the heck is going on? How am I supposed to know that the vulnerabilities are patched if it says 1.0.1e, not 1.0.1h as it should? Why doesn't Debian just freaking put 1.0.1h in the distribution? I do not get this.

Tyler Durden
  • 5,631
  • When doing apt-get source openssl you'll notice that the package maintainer has applied one or multiple patches. Relevant is that the vulnerability is fixed, not what the number reported is. But I agree it's confusing. – 0xC0000022L Jun 05 '14 at 20:04
  • 1
    I have noticed this type of behavior when getting patches from large vendor supported linux systems (red hat). But they do put a sub-sub version number. – mdpc Jun 05 '14 at 20:12
  • I wouldn't rely on the build time, instead look at the Debian package versions and/or changelogs. – plugwash Dec 16 '15 at 14:53

1 Answers1

3

You are probably looking at Debian stable, which keeps package versions stable by definition. Whatever version of openssl that a particular release of stable shipped with is the one it will stay with. For security fixes, the Debian maintainers backport the upstream security patches to the stable version instead of upgrading the stable version. If you want the latest upstream version of everything, then you will need the unstable branch.

From the Debian security team FAQ:

Q: Why are you fiddling with an old version of that package?

The most important guideline when making a new package that fixes a security problem is to make as few changes as possible. Our users and developers are relying on the exact behaviour of a release once it is made, so any change we make can possibly break someone's system. This is especially true in case of libraries: make sure you never change the Application Program Interface (API) or Application Binary Interface (ABI), no matter how small the change is.

This means that moving to a new upstream version is not a good solution, instead the relevant changes should be backported. Generally upstream maintainers are willing to help if needed, if not the Debian security team might be able to help.

In some cases it is not possible to backport a security fix, for example when large amounts of source code need to be modified or rewritten. If that happens it might be necessary to move to a new upstream version, but this has to be coordinated with the security team beforehand.

Community
  • 1
jw013
  • 51,212