MRE request: virtualbox

[Gianfranco Costamagna]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I would like to apply for a micro release exception for Virtualbox

Upstream:

  - Micro releases happen from low-volume stable branches,
    approximately once every two months.

  - Stable branches are supported with bug fixes for some years
(normally 5 years + 6 months or more).

  - Upstream commits are reviewed by members of the Virtualbox Server
    Engineering team.

  - All commits to stable branches are evaluated wrt. potential
    regressions and signed off by the Virtualbox team.

  - Unit tests and regression tests are run on multiple platforms per
    push to the source code repository. In addition, there are more
    extensive test suites run daily and weekly.

  - Each micro release receives extensive testing between code freeze
    and release. This includes the full functional test suite,
    performance regression testing, load and stress testing and
    compatibility and upgrade testing from previous micro and
    minor/major releases.

  - Tests are run on all supported platforms (currently amd64 and i386).

Upstream update policy (from upstream developers, not from Oracle compan
y)

For VBox 4.x, the support period was 5 years. As VBox 4.0 was released
in December 2010, the official support for VBox 4.x (including 4.3)
will end in December 2015. For VBox 4.3 we will probably extend the
period for a few month. With VBox 5.x, the support period is still 5
years but once VBox 5.1.x is released, users have to switch from 5.0
to 5.1 within a certain period. There will be a grace period of
approx. 6 month but after that,
There will be no further updates for 5.0.x. So within the 5 years it
will happen that 5.1.x replaces 5.0.x at some time and there will be
no further updates to 5.0 when 5.1.0 is released + approx 6 months.
Btw, disclaimer: This is not an official Oracle statement (I'm not
allowed to do that) but you can take these statements serious.

In Debian/Ubuntu:

  - Upstream generally refuses to give CVE targeted fixes [1], so this
leaves virtualbox in stable releases generally vulnerable, e.g. to
CVE-2015-2594

  [1]
http://www.oracle.com/us/support/assurance/vulnerability-remediation/dis
closure/index.html

- - Usually newer kernels means a bad experience for users, since the
kernel drivers are rebuilt at each kernel update, and leads to
failures like [2] and [3]

[2] https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1457776
[3] https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1457780

This is actually mitigated since Vivid releases, because of:

  * Re-work the packaging to account for the kernel modules being
shipped in
    the master kernel packages, removing the need for dkms (LP: #1434579
):
    - Make the dkms package provide a virtual package matching what the
      kernel packages provide to indicate that they ship the dkms module
s.
    - Add an alternate dep from the utils package to the virtual driver.
    - Make the x11 driver package associate with the VGA controller
PCI ID.
 -- Adam Conrad <adconrad at ubuntu.com>   Wed, 22 Apr 2015 10:01:25 +0100


so actually having that change will make the problem disappear when an
official -lts kernel is used, and updating vbox will make the problem
disappear also for custom kernels
(unless they are RC kernels, of course)

Additional notes by Gianfranco Costamagna (Debian Developer and
Virtualbox Maintainer)

as stated in Debian bug 794466 I will (ask for) upload in security
pockets the new micro releases, and wait for feedbacks (on top of the
testing I do locally at each upload, including creating a clean target
environment, doing upgrade testing and checking if VM still starts
correctly).

After that I will do the same testing for Ubuntu supported releases,
and actively monitor bugs for regression that I'll try to promptly fix
whenever a regression is found.

AFAICS I have never saw a regression in my yearly vbox maintenance on
micro releases, but in case I'm sure upstream will help us in fixing
them, because they actively monitor for regressions and bugs on all
the tracker they have (including vbox-dev mail list and vbox forum,
other than the ticket system)

Debian already accepted my request of targeted MRE fixes, so we have a
CVE-free virtualbox in jessie/wheezy/ oldstable (partially, because
the support of virtualbox-ose has ended this year).

Another MRE for Debian is ongoing right now (4.3.32 and 4.1.42) with
fixes for CVE-2015-4896 and CVE-2015-4813

thanks a lot for considering,

Gianfranco Costamagna <locutusofborg at debian.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWMlxeAAoJEPNPCXROn13Z2icP/iou1LiUGwGlq/D/9EqaDwIO
U0V9jPP2+ePYko9Lvl6ib+eb/vziPcGK8U1+X9js9luntxu5TaZfhpcppC4BHbQ1
QE/4mrAddDozf4SJsvQaR5YwrCRRwit8TpyNsYrAezMP3b1r3h5awRhJAzJ6RKHu
DOVne7zNsmEveXn/oUw+UZRkqIySATIqPJLD251HuSRj36WBPcBCsQYgrXnr7Y27
XLt7mUNHcYaIGj1ZRv3BwD0CiY5+ZVvbXiiTrWP7khT640iKGNuLzTwnPcgWz9f+
uB7IdzZRiFf57mvV/tzwkkhVqMI9J4nS8nsgTCacc1R5yW+4eesv3wVVkE7L9E8R
Np7mI1Nlpd1/YBpqhbuqP25vrBI3odk5C6FynjQVtts1l541Wn+2kqwC3hX1rsnO
HUXj7UP/uehb2NPC+BFmpwX78dlNOVIe7nrEiINBcyQ5QVE/xTTBeJGN62L/zWsk
jfVAVLaHHMf6wo8Ly5EI5/l6AZRCHM2OcGWp6p6P+Rqa0pjwhpjhLaSneuVAeUqH
VOcDFVE9BmRhIkovsFgCBEa8kjEylXVwKJhx8WmDzPrdp/7qzH/7qOEsIRXPEjG6
ivKNcunTFWSNGwtOaYcOf2DcHox1UokwVu7xU0s+Ftx5DqX5QAG52mJ5LjPlsVCC
oA88Sz+8k5LyVJPs1D+t
=aEP8
-----END PGP SIGNATURE-----