2

Given the real-life example of an announced vulnerability fix, e.g. the latest openssl vulnerability fixes, and a Distro's reported throughput of the fix, e.g. GNU/Linux Debian's response to CVE-2016-6309:

wheezy              1.0.1e-2+deb7u20  fixed
wheezy  (security)  1.0.1t-1+deb7u1   fixed

I have two questions:

  1. Will having installed (a possible future) version 1.0.1e-2+deb7u21 per definition contain the (or better) fix too, it being the younger version (note: I'm using a hypothetical example, u21 does not exist yet, as my question is generic not specific)?
  2. What is the difference between wheezy and wheezy (security) in the specific example (GNU/Linux Debian). Sometimes the "security one" seems to refer to a younger version version, sometimes to an older, I'm lost..

If anyone could shed some light on these one for me.. that would be appreciated!

  • Also if anyone know the answer to my, more specific (but very related!), question I posted in the Raspberrypi stack exchange; Don't hesitate to teach the h* out of me! :P – woosting Sep 26 '16 at 19:52
  • 1
    If you check that page carefully, you'll see a note saying "openssl <not-affected> (Only affects 1.1)" in the end, so in this case "fixed" means we have checked this vulnerability and did nothing about it. – Dmitry Grigoryev Sep 27 '16 at 16:37
  • @DmitryGrigoryev - Thanks for noticing and informing us! I upvoted your comment (but accidentally downvoted, and now it is impossible to upvote again). It is not answering the questions per se, but it was a very informative comment about a related detail that I would otherwise have missed. So thanks! What would you say about what I posted below? – woosting Sep 27 '16 at 20:15
2

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 VVV and RRR? The full naming convention is:

foo_VVV-RRR_AAA.deb

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.1 or 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).

(security) repositories

What 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 RRR part.

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.0001 => vim-8.0.0003 => 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.

  • Thanks for your elaboration on the naming convention. I got that (now / in general). The question is about application convention / assumptions though, given the versions: Should 1.0.1e-2+deb7 u21 (or *.u32 for that matter) to be expected to have included a fix build into the 1.0.1e-2+deb7 u20? – woosting Sep 27 '16 at 14:06
  • 1
    @woosting - Eyup, that is the case. In principle u20 and any package with a higher number should have that fix (unless VVV changes or you change your debian release, in which case a different numbering is used). 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. – grochmal Sep 27 '16 at 14:23
  • Thanks!! I'm still puzzled by about the 2nd subquestion though. Maybe this report is more illustrative: Jessie (security) reports the fix to have landed in 2.19-18+deb8u3 (u3), yet for the normal Jessie this would be 2.19-18+deb8u6 (u6)? Say I install 2.19-18+deb8u5 (u5). Would it have the vulnerability fixed? Or better yet; what (and why) is the difference between Jessie and Jessie (security) in this context (I realize this may be too much of Debian specific question but you seem knowledgeable in the area)? – woosting Sep 27 '16 at 15:55
  • 1
    @woosting - Oh cool. jessie (security) means the package number you get the fix if you have deb http://security.debian.org/ jessie/updates main contrib in sources.list. And plain jessie is the package you get that if you don't have it in sources.list. The security guys backport the security fixes into older versions and therefore there are sometimes discrepancies between the two. Note that depending on how much code is changed "older version" may have different numbering, making some inconsistency. – grochmal Sep 27 '16 at 21:03
  • Ah! So for the example the conservative sysadmin would stay with the 1.0.1e-2+deb7u20 to keep changes minimal (integrational stability?), whereas a lenient one would have http://security.debian.org/ jessie/updates main contrib in its source-list to upgrade to 1.0.1t-1+deb7u1 (a package with more rigorously changed code). @grochmal Thanks for "staying with me here"! Do you want me to "answer my own question", or do you want your credits and do it (if I find your answer in the morning I'll up-vote it, otherwise I'll summarize). – woosting Sep 27 '16 at 21:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.