TL;DR: In principle
u20 and any package with a higher number should not be vulnerable (hell,
u1 and any higher should not be vulnerable since the upstream version of the package does not change and
u1 is not vulnerable). That is, unless
VVV (the upstream version, see below) changes or you change your Debian release, in which case a different numbering is used (see below for an elaborate explanation of version conventions). That is true in 99.9% of cases, but developers make mistakes and sometimes later changes awaken old vulnerabilities. Yet, that is quite rare and in such a case a new CVE is raised.
Debian package naming convention
Heh, you will probably find this frustrating but the Debian FAQ explains the version part of the package as:
The VVV component is the version number specified by the upstream developer. There are no standards in place here, so the version number may have formats as different as "19990513" and "1.3.8pre1".
The RRR component is the Debian revision number, and is specified by the Debian developer (or an individual user if he chooses to build the package himself). This number corresponds to the revision level of the Debian package, thus, a new revision level usually signifies changes in the Debian Makefile (debian/rules), the Debian control file (debian/control), the installation or removal scripts (debian/p*), or in the configuration files used with the package.
But wait, what are those
RRR? The full naming convention is:
AAA is simple, it is the architecture.
VVV comes from the upstream developer, i.e. from the openssl developers in your case (e.g.
1.0.1t, see here).
Last comes the
RRR which is left to the person packaging the
.deb, and it really be anything. On the other hand Debian packagers normally follow the debian version (
deb7 for wheezy,
deb8 for jessie) plus some update number. The update number does not need to be sequential, it just need to be higher than the previous one. This is likely because a packager will have failed test builds of his packages*.
In summary, there is nothing that links the
.deb version string and the CVEs it includes. You do need to go and read the release notes. Moreover, often you need to read the release notes of the packager and of the upstream developer (the packager will often include a link to th release notes of the upstream developer).
wheezy (security) means instead of plain
wheezy is that your Debian has the
security repository installed as one of the repositories for
apt. This is normally performed with:
deb http://security.debian.org/ wheezy/updates main contrib
The guys at security.debian.org work on CVEs and produce all those CVE reports in the debian security tracker. They update packages for old and new Debian versions as needed for the security purposes. Using your example CVE: openssl in
jessie is pretty new, in
jessie (security) is newer, in
wheezy (security) is new, but
wheezy still uses a rather old version.
This allows sysadmins that use
wheezy to get security updates without the need to upgrade to
jessie. Debian is incredibly robust and stable, and there are sysadmins that may wish not to update their packages with security updates fearing that code changes will make things fail (they simply do not enable the security repositories).
Now, the security guys will update an older package if it is needed, they prefer backporting the package. Yet, sometimes it is needed to update
VVV, for example the openssl at
wheezy (security) is at
1.0.1t whilst on
wheezy is at
1.0.1e, likely because of this CVE.
Therefore, we can say that
wheezy (security) is more dangerous in terms of backward compatibility then plain
wheezy but safer than upgrading to
jessie. As far as I am aware if you use just plain
wheezy or plain
jessie (you only have the
stable repository in
sources.list) you will never receive a
VVV update through
apt, you will only get updates to the
Note that thanks to the fact that it is a different set of people that work on the
(security) repositories and the normal repositories, funny things happen. Here is a CVE in which the (security) package is vulnerable but the normal one isn't, in this case it is fine because
VVV is the same and
RRR of the non-security package is higher and will be selected by
apt as the newest update available.
Related / References:
* I cannot tell specifically for Debian but one recent packaging adventure I watched was Vim 8. The upstream developer patches came very fast and the testing repository of Arch had:
vim-8.0.0005. The last one,
vim-8.0.0005, was moved into the
extra public repository. Therefore packagers often jump release numbers because the package is updated before it is allowed to leave the testing package repositories.