Fwd: MRE request: virtualbox

[Tyler Hicks]

I looked back through the logs and we did give an ACK:

  01-09-2015 07:33:34 <mdeslaur> LocutusOfBorg1: I think a MRE for VirtualBox makes sense
  01-09-2015 07:33:42 <mdeslaur> LocutusOfBorg1: so ACK from the security team

That said, I just learned that asking the Tech Board for an MRE is no
longer needed if the SRU team decides that a number of conditions are
met:

  https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases

If the update fixes security issues, it'll need to go through the
security sponsoring process instead of the SRU process. The security
sponsoring process is documented here:

  https://wiki.ubuntu.com/SecurityTeam/SponsorsQueue#Notes_for_Contributors

Hope that helps!

Tyler

On 2015-10-29 19:03:55, Gianfranco Costamagna wrote:
> Hi again folks, I forgot to mention.
> 
> Some weeks ago (september or october), I asked the same in
> #ubuntu-hardened irc channel, because I guess this is mainly a
> security problem.
> 
> I got an ack from them on irc, but unfortunately (bad me) I discovered
> that irclogs [1] doesn't save -hardened irc conversations.
> 
> So I'm ccing the security team again, because I guess (and I hope)
> they should give their input on this matter too :)
> 
> 
> [1] http://irclogs.ubuntu.com/2015/10/29/
> 
> thanks,
> 
> G.
> 
> -------- Forwarded Message --------
> Subject: MRE request: virtualbox
> Date: Thu, 29 Oct 2015 18:50:22 +0100
> From: Gianfranco Costamagna <costamagnagianfranco at yahoo.it>
> To: technical-board at lists.ubuntu.com
> 
> 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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20151029/cbb0ae44/attachment.pgp>