2

In relation to my quest to understand security (fixes) on deb/Raspbian I keep finding myself in dead ends! :(

For example: Another example happened today.. The openssl package openssl contains two vulnerabilities: CVE-2016-7052 & CVE-2016-6309. But for simplicity let's just focus on the latter (most severe) one. The Debian maintainers promptly responded and patched the package with the fix within 12 hours of the announcement (or at least since I read it), in version: 1.0.1e-2+deb7u20. So far so good (so it seems). But, once back home checking my Raspbian (wheezy) version, and I was surprised (as I have not updated the package, in the last couple of days) to find the installed package to be: 1.0.1e-2+rvt+deb7u21.

So here are my two questions about how they relate:

  1. How is it possible that a newer version seems to be installed already: 1.0.1e-2+rvt+deb7u21 (Raspbian) vs. 1.0.1e-2+deb7u20 (official Debian)?

  2. What does the rvt stand for in 1.0.1e-2 +rvt+deb7u21 (on Rpi).

Could anyone clear this fog for me (I tried Googling but was unable to find asolid - or any tbh. - answers)?

Edit:

  • ad 1: Maybe it got patched by the Raspbian devs?
  • ad 2: This could also explain the "rvt"?
  • Also see my more generic post about how "normal" CVE fixed versions relate, which I posted at the knowledgeable neighbors at 'Information security'. – woosting Sep 26 '16 at 19:55
  • I added an hypothesis. What do you guys/gals think? – woosting Sep 27 '16 at 15:30
  • I think someone out there knows and would be willing to give you the simple answer, but unfortunately you might have to wait forever here for it. However, you likely could find such a person easily enough on a mail list or IRC. Just don't tell them I sent you ;) – goldilocks Sep 27 '16 at 15:32
  • 1
    debian.org/MailingLists/subscribe <- There's no specific list for "packaging" but there are some that are related, and there is an explicit "debian-security" list that is not just announcements, so you could search the archives there and if you can't find an answer, just subscribe and ask. – goldilocks Sep 27 '16 at 15:36
  • Agreed (on the Debian stuff), but I suspect this specific (RVT) thing to be a Raspbian-specific thingy though (hence my hypothesis addition). I am looking into the mailingList thing you pointed out anyway though (if not for all the Debian questions I have)! I'm a bit intimidated though by the "real Debian channels", but I'll see. There's got to be a first time for anyone, right? I'd love a good/active IRC channel too btw. Got any suggestions? (each time I find one and mention "Goldilocks" the chatroom suddenly turns empty though.. No clue why.. :P). – woosting Sep 27 '16 at 15:50
1

How is it possible that a newer version seems to be installed already: 1.0.1e-2+rvt+deb7u21 (Raspbian) vs. 1.0.1e-2+deb7u20 (official Debian)?

The comments on the security tracker entry you linked indicate that the vulnerability was not so much fixed as "not applicable".

1.0.1e-2+deb7u21 was released months before this question was posted but because there are no point releases during lts it was never transferred from the Debian security archive to the main Debian archive. I guess this is why they used 1.0.1e-2+deb7u20 as the "fixed" version in the security tracker.

What does the rvt stand for in 1.0.1e-2+rvt+deb7u21 (on Rpi).

Raspbian normally* uses +rvt in situations where all of the following are true.

  1. The package was previously locally modified in Raspbian.
  2. The package is no longer locally modified in Raspbian.
  3. There is a need to bump the version number to make it higher than previous versions in Raspbian.

In this particular case we patched the openssl package to enable arm assembler optimisations, some time later Debian did the same so we no longer needed to modify the package locally in Raspbian.

Other than the version number, the extra changelog entry and obviously being built in a raspbian environment Raspbian's 1.0.1e-2+rvt+deb7u21 is the same as Debian's 1.0.1e-2+deb7u21

P.S. note that around the time this question was asked version 1.0.1e-2+rvt+deb7u21 was replaced by version 1.0.1t-1+deb7u1 which was in turn replaced in Febuary 2017 by version 1.0.1t-1+deb7u2 . With these versions there was no need to bump the version numbers in Raspbian since in dpkg version ordering 1.0.1t-1+deb7u1 > 1.0.1e-2+rvt+deb7u21 .

* It has also been used in at least one case to bump a version number so it was higher than the version number of a package shipped by the raspberry pi foundation.

  • Ah, so I got confused because I did not take into account Raspbian's own (parallel) development (or maybe better put: independent/local development, seeing chronologically those developments can be shifted). Correct? I seemed to be under the false impression that development was one-way from Debian to Raspbian.. naturally this is not the case; some changes are only local, some get up-streamed, others get down-streamed - in multiple possible combinations. Correct? – woosting Oct 18 '17 at 16:02
  • 1
    Pretty much every change Debian makes will end up in Raspbian through automated (for packages where Raspbian has no local modifications) or semi-automated (for packages where raspbian does have local modifications) processes. Any flow in the other direction is a manual process. – Peter Green Oct 18 '17 at 16:57
  • 1
    It is quite common for Raspbian to make a local modification and then for that local modification to become unnessacery, either because Debian made the same or an eqivilent modification or because circumstances changed. Most of the time when this happens the version number in Debian is higher (in dpkg version ordering) than the version in Raspbian and Raspbian can just pull in the new source package from Debian but occasionally there is a need to bump the version number. – Peter Green Oct 18 '17 at 17:09
3

If you want to focus specifically on CVE-2016-6309, this OpenSSL announcement specifically states:

Fix Use After Free for large message sizes (CVE-2016-6309)

Severity: Critical

This issue only affects OpenSSL 1.1.0a, released on 22nd September 2016.

Since Debian is using OpenSSL 1.0.1e, it is simply not affected.

I don't know what rvt stands for, but from package management point of view 1.0.1e-2+rvt+deb7u21 will be considered newer than 1.0.1e-2+deb7u21, so the former will be installed if both are available.

  • Thanks for pointing that out! This was just a (badly chosen so it seems) example to illustrate my more general question though (I adapted the question title to better reflect what I am trying to figure out). – woosting Sep 27 '16 at 20:21

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.