X-Debbugs-CC: jmm@inutil.org
X-Debbugs-CC: rrs@debian.org
X-Debbugs-CC: frank.mehnert@oracle.com
X-Debbugs-CC: klaus.espenlaub@oracle.com

(please cc people if needed
As Said in many different threads [1 bottom of the mail], Upstream doesn't play in a really fair mode wrt CVEs in the package (it used to, but not for the current CVE list).

This basically makes the package unsuitable for Stable Releases, since "Upgrade to a newer release" is not the correct answer, and
cherry-picking patches without upstream support is just impossible/not easily feasible for such a huge codebase.

I quote a mail from some Vbox upstream developers and Debian folks.

Personal Maintainer opinion:
I do not have anything against Virtualbox neither against Upstream, made by people competent who helped us a lot, and did a great work in merging
patches (also my patches) and providing such a good tool for us, I love the package and I would like to see it in Debian, but since people working for Oracle might risk to get punished for not following the Oracle policy, I think we are not sure we can continue giving a CVE free package for Stable Releases.

So, while Oracle employees tries to find out an Open Source friendly way to cooperate with us, I'm opening this bug, to let the community be aware of the status quo of the package.

I'm aware of the problem. Unfortunately there is an Oracle policy which
forbids us to provide relevant information about security bugs, see
here:

http://www.oracle.com/us/support/assurance/vulnerability-remediation/disclosure/index.html

We are currently trying to find out what's possible to help you but this

will take some more time.



thanks folks for the help, I still hope we can solve it in a good way, to avoid disappear of Virtualbox there :)


cheers!

Gianfranco

Hi Gianfranco,
thanks for your summary.

Although I'm not involved in maintaining virtualbox, still a few
thoughts:

* What would that mean for Jessie updates?
* Isn't that basically the same problem we have with MySQL,
  or even Iceweasel?

So I think the question is either drop, or work with upstream releases,
from which I'd personally prefer.

Even popcon isn't too bad:
https://qa.debian.org/popcon.php?package=virtualbox

Leaving users with the possibility to use upstream packages is also not
very attractive.

Just me few cents :)
Markus

Hi Debian Release Team,


TLTR:


Virtualbox suffers of  many security issues in Debian,
specially because Upstream (Oracle) refuses to give
patches for CVEs, and (you can see in the Debian bug
794466 an analysis of the Oracle policy and discussion)
this makes difficult to handle security uploads in stable
releases.


The only patch they give for a CVE is "upgrade to the
next version of the stable branch", and extracting patches
from the code is not trivial, specially for such a huge package.


My request, based on Markus mail quoted below

(something I pondered already, I was just waiting for somebody
to do the first move), would be to have a sort of permission
to do the updates to newer stable releases in s-p-u.

e.g.


On oldstable, version 4.1.18-dfsg-2+deb7u5 might become 4.1.30

on stable version 4.3.18 might become 4.3.30 and so on.

Oracle at this moment maintains a 4.0.x 4.1.x 4.2.x 4.3.x 5.0.x
branches where security fixes seems to be addressed all.

(virtualbox-ose from o-o-s still needs some pinpoint fixes)


So, even if the debdiff might look scary, we might want to
update at least to the correspondant stable branch
to fix bugs and security issues.

Honestly I *never* found a regression in Virtualbox maintainance
releases, neither in backports, and the huge popcon makes difficult
to just let the package disappear.

I maintain Virtualbox since ~2013 or so, and I can say that the
maintainance branches does not require new dependencies
(at least they never did, the only build-dependencies we added
in maintainance releases were due to packaging bugs that had to
be fixed, not something that upstream added)



Thanks for your attention,

(note: I did not find any reference on google about this sort
of exceptions, please feel free to point me on some documentation,
if adding -release to the bug is not enough, or feel free to reassing
to the best meta package bug)


Gianfranco

Hi Frank and Release Team,


virtualbox-ose is at version 3.2.10, and the last release from [1]
is 3.2.28, and released two months ago.

Does this mean that CVE gets fixed on 3.2.x too?


[1] https://www.virtualbox.org/wiki/Changelog-3.2

thanks,

Gianfranco

You should bring this up with the security team and see whether they are
satisfied that previous upstream releases have been of sufficient quality
for this to be feasible in the future.

Hi Debian Security Team,


(Dear Jonathan, thanks for the heads-up, I tried to avoid cross-posting,
and I thought release was a better place then security, so dropping
-release from the mail cc, let me know if I have to readd it)


I would like to ask you whether is possible to have an exception for
Virtualbox Stable Releases.

To avoid duplication, please read bug #794466 for the discussion and my
personal POV of the story, I tried to be as much verbose as possible,
please do not hesitate to ask anything you want if something is not
clear enough.

(or if you want debdiffs, git diff --stat between versions, changelogs or
whatever).


(below a little snippet of the last two bug messages)


cheers,

Gianfranco



Il Sabato 8 Agosto 2015 23:42, Jonathan Wiltshire <jmw@debian.org> ha scritto:

You should bring this up with the security team and see whether they are
satisfied that previous upstream releases have been of sufficient quality
for this to be feasible in the future.

Not sure about MySQL, but for Iceweasel, is it really like that ?

From what I've known, there were trademark issues which led to the
rebranding.


I'm not sure how they handle vulnerabilities. But their release
strategy is: ESR and Regular releases. Every security fix goes into the
next Regular release, and also the ESR release.

ESR is supported until the next ESR (31 => 38). So usually the Debian
Mozilla team prefers the ESR branch for Debian stable.

With VBox, they don't have an ESR model.

Sorry for being unclear, I meant the usage of upstream releases directly in Debian (security) updates.

I guess they don't call it ESR or long term support, but as Gianfranco pointed out, they seem to support a lot of major releases currently.

The main problem is here, do we want to use their upstream releases? In lack of a proper patch source, the Oracle way...

Cheers
Markus Frosch

challenge for the sec team.


Debian Security Team:

These are what we have currently in Debian:

oldstable: 4.1.18
stable: 4.3.18
testing: 4.3.30



So, to keep the stable version secure in the Oracle way, we'll need to
push it to 4.3.30. Please look at:
https://www.virtualbox.org/wiki/Changelog-4.3 for the 4.3.x changelog.

Similarly, 4.1.x here: https://www.virtualbox.org/wiki/Changelog-4.1

The good thing is that Oracle declares these as "Maintenance release".
So usual sane practise for them too, should be, to only update it with
Security Fixes. Though this has not been the case in the past. There
have been regressions.


But if the security team can agree up with this release model, then the
VBox team could just keep it up-to-date.

Hi,



I would add (as Ben requested)

old-old-stable 3.2.10 --> 3.2.28
(this will fix AFAICS all the CVEs on o-o-stable, but not the latest one)


https://www.virtualbox.org/wiki/Changelog-3.2


I do not recall any regressions there, at least between stable minor releases
(I recall regressions between 4.1.x and 4.3.x)

However the changelogs mentions a couple of them, so must be right :)



Yes, otherwise the points remains:

1) leave the oracle with CVEs in stable releases

or

2) have an exception from Security Team and/or Release Team

or

3) wait and hope Oracle will change the model or make an exception

----


1) means a disappear of VBox from Testing I'm afraid

2) We will continue to provide security new releases, and fix almost all the CVEs around here
(except for one in o-o-stable)
3) this is kind of impossible right now I guess (even if Oracle employees are continuing
to try to have it)


BTW having the "stable maintenance releases" on Debian stable releases, will allow people to be able to rebuild
kernel modules on their own, because usually people upgrade
their kernel while running stable, and virtualbox usually don't compile anymore
with them.

Ubuntu followed a slightly different model, they started embedding in linux kernel
the virtualbox modules, while with Debian we are forced to update virtualbox on stable,
or close the bugs reported with "notfix" (and ask people to run it from testing instead).

So the annoying kernel module rebuilds might be fixed too here :)


cheers,

Gianfranco

Does anyone know what Fedora project's stand is on VBox ?
From what I've checked so far, Fedora does not ship VBox. But I'm not
sure what their reasons are.......

We'll have a security team meeting at DebConf and will discuss
virtualbox as well.

Cheers,
        Moritz

Hi Moritz,


following up on the DebConf discussion,
I did update vbox for wheezy and jessie, on
the respective braches on git (names with the codenames)
targeted -security.

http://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/log/?h=jessie
http://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/log/?h=wheezy

jessie is going from 4.3.18 to 4.3.30, while wheezy is going from 4.1.18 to 4.1.40

builds are also available from DebOMatic
http://debomatic-amd64.debian.net/distribution#oldstable/virtualbox/4.1.40-dfsg-1+deb7u1/lintian
http://debomatic-amd64.debian.net/distribution#stable/virtualbox/4.3.30-dfsg-1+deb8u1/buildlog


I tried to keep changes as minimal as possible, with just some patch refreshing and nothing more.
(and for changelogs, well, please tell me the best way to update it, because I honestly don't know)





I plan to do the same with virtualbox-ose and squeeze if you allow me too. (from 3.2.10 to 3.2.28).

I did some basic testing with both jessie and wheezy in that way.

1) Installed jessie on virtualbox.
2) Installed virtualbox inside the jessie VM (from apt)
3) installed Ubuntu vivid 32 bit in the virtualbox inside the VM
4) updated vbox with the DoM build
5) tested if the VM was still running correctly.

the same for wheezy, and all the testing were successful.

let me know if something is blocking the uploads, or if I can do them by myself (I guess policy and the manual
doesn't allow DD to push on security directly).

I don't know exactly the CVE fixed but at least for 4.1.x and 4.3.x they should be covered ALL of them.

for vbox ose I guess CVE-2015-2594 will be left out, the only one we don't have a targeted patch from upstream.

cheers,

G.

Hi, Virtualbox is finally CVE free in wheezy and jessie.

thanks to all for the support!

cheers,

G.

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Updateing yesterday didn't help

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

Undating

   * What was the outcome of this action?

The virtual machine 'Deppi-505' has terminated unexpectedly during startup with exit code 1 (0x1).

   * What outcome did you expect instead?

Smooth working


*** End of the template - remove these template lines ***

Hi Clemens,

this bug has *nothing* to deal with your bug.

please open a new one.
thanks

Gianfranco

control: reopen -1 thanks
control: found -1 5.0.6-dfsg-1

As per DSA-3699-1, security team thinks virtualbox can't be released with Stretch.

G.

That's sad. I hope you can keep virtualbox in backports for stretch.

Cheers,
Emilio

Stretch.

Thanks for all your work in maintaining VirtuaBox in Debian.

Could you answer the following questions so that I (and others) can make
some decisions about future use of VirtualBox?

1. Will you continue to package VirtualBox for Debian?

2. Do you anticipate making a backports version available for Stretch?

3. Do you recommend migrating existing VirtualBox images to KVM?

Gordon

Migration should be doable. I'm not sure if there are any issues in migration,
but you may give it a shot.


Should you migrate, it may depend on what your core requirements are.

VirtualBox has a much nicer UI integrating all features, very well, into its
Graphical interface.


On the other hand, KVM is the stock in-kernel hypervisor for Linux, which has a
much larger userbase (Oepnstack, RHEV etc) and gets much more testing.


In the past, I've migrated my setups from both ways. Initially, from KMV to
VBox, and then later again from VBox to KVM.

VM disk image conversion was fairly stable. I had no issues during image
conversion.

For config settings, I just noted down the settings and applied the same when
importing it to the other hypervisor. For a large number of VMs, this may not be
optimal.

I did a test migration of a VirtualBox image running Windows 10 to KVM from
virt-manager, and everything worked. However, I don't seem to have the
correct drivers installed (virtio drivers?) to get full resolution support
in my guest Windows system.

I'd still like to know what the plans are for the VirtualBox package in
Debian. I can backport the version in sid to stretch by building it myself,
but at some point, this process may break if maintenance of the package is
dropped.

Gordon

Hi all,


I started a discussion on -backports mail list some days before your email
https://lists.debian.org/debian-backports/2016/12/msg00042.html

Please forward the discussion there, since this seems to be a backport-specific issue :)

G.



On Tue, Dec 13, 2016 at 12:55 AM, Ritesh Raj Sarraf <rrs@debian.org> wrote:

-----BEGIN PGP SIGNED MESSAGE-----

I also migrated a VirtualBox image to KVM, and works nicely. The guest system
is Windows 10. VirtualBox runs on debian jessie, and KVM in debian stretch.

In contrast to Gordon's, my guest's screen resolution is set at the full
capability of my HiDPI screen--2560x1600. A scale factor of 200% (Windows 10
Settings -> Display) allows for perfectly sized texts, icons, and other items.

I believe KVM is just what I need. Considering VirtualBox is unavailable in
stretch, I won't use it any longer.

I use VirtualBox on stable (currently jessie) as part of my strategy for
testing anything that will run in future Debian releases (e.g. stretch).
 It has been extremely useful for this purpose in the past.

How many other developers are working this way, either with VirtualBox
or one of the alternatives?

I recently did a trial of the stretch installer into a Virtualbox VM
(host running jessie) and ran into trouble getting the graphical
desktop, it is discussed in bug 851124[1].  Even if Virtualbox won't
continue being available, it would be helpful to other developers and
testers to find ways to make them aware of such things before they lose
any time on it.

It would also be helpful to have a summary on the wiki about some of the
points raised already in the thread:

- whether or not it will be available as a backport (I was able to run
the sid packages in my stretch VM without rebuilding or modifying them)

- a cheat sheet or conversion guide for the next best thing, whatever
that is, e.g. KVM

Given the convenience of Virtualbox, many users may not have been
tempted to explore KVM or other desktop virtualization solutions before
so it could be helpful to write a quick summary of how it really
compares to the Virtualbox package.  In particular:

- are graphics features and performance equivalent, better or worse?
I've tried setting up KVM once with the pass-through VGA and it never
worked, although that may have been a chipset limitation.  I also
recently introduced the virglrenderer[2] for qemu into Debian.  Those
are both things that Virtualbox doesn't support but they are only useful
to people with the right hardware.  For people without the right
hardware, falling back to a remote-desktop protocol might be a serious
limitation, virtio-gpu might be better but it is not clear that this
will work for a jessie host or even a stretch host just yet:
https://www.kraxel.org/blog/tag/virtio-gpu/
The fact that VirtualBox offers a strong desktop graphics solution is
probably one key reason some people may want to stay on Virtualbox, at
least until the KVM / qemu solutions work more effortlessly.

- how does CPU performance compare, e.g. speed, impact on the host?

- how convenient is it to do the basic things that most people do with
the Virtualbox GUI?  For me, those basic things are typically attaching
and detaching VDI and ISO images and tweaking the network from NAT to
bridge.

- what is the impact of migration on guest operating systems that are
sensitive to perceived hardware change, e.g. for each Windows version?

Having some of these things in one place could help people get on with
other things they are testing.

Regards,

Daniel



1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851124
2. https://virgil3d.github.io/

affects 794466 src:virtualbox-guest-additions-iso
thanks

Hello Daniel,

Used to use/maintain VBox. But moved away after Oracle's attitude towards it.
Pretty happy with KVM/Libvirt right now.

And how do you propose doing that ?
I'm interested to know because I maintain many packages, usually used in the
enterprises, for which I'd only get user testing and bug reports, after the next
stable release. By then, it is already late.

The best I've doing is to handpick users and email them to do some early
testing. Also, blogging sometimes helps. But I'm sure, I'm only reaching a minor
subset of the actual users.

Yes. Would be nice to see that. But creating a wiki means, maintaining its
status. On the other hand, the bug report usually serves as a live status of the
issue.

Hmmm. Mostly what you want is to convert .vbox image into something that qemu
understands. For the rest of the stuff, like Guest VM setting attributes, I
don't think there's a straight way to do it.

Someone needs to do it. And I'd still think that such result (on performance)
won't be comprehensive.

On the features side, yes, it'd be nice to have. VBox really enjoys in the UI
front.
Other than that, KVM has a better edge.

* In-kernel hypervisor. No frequent breakages with newer kernels
* In-kernel hypervisor. Doesn't need external modules (dkms pacakges) to be
built.
* Very good performance with Guest VMs that support Para-Virtualized drivers for
block and net (and maybe graphics too now). For non-para-virtualized guest OS,
performance could suck.
* VBox has a lot better UI than libvirt. But libvirt is much nicer to manager
remote hypervisors.

It is the same, in my opinion. Without the vbox-guest-dkms package, the Guest
VMs run under Full virtualization, and inherit its performance bottlenecks.

Things are simple in libvirt too. But vbox does have a cleaner UI.

I don't know. Last I used was with Windows 7. And it was sensitive.
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

Sorry for the long post, but it does give a walkthrough of how this is
working now in Stretch…


I installed Debian Stretch today using the January 23 weekly
netinstall image. I installed to a VirtualBox guest (the host is
Ubuntu 17.04 Alpha). The install went well except for two issues.

1. I chose to install the GNOME desktop. tasksel had some kind of
error near the end of downloading packages. Maybe some transient
network error. When I re-ran the task, it suggested I install some
virtualbox-ose-something package. The install completed successfully.

2. When I rebooted after install, gdm did not start and my console was
flickering really bad. Along with the console flickering, I could not
reliably enter my password since keypresses were getting dropped. I
tried booting into recovery mode but since I did not set a root
password (I prefer to use sudo), Debian gave me an error about the
root account being locked and after I pressed Enter as prompted, it
continued a normal boot. After about 5 minutes, the flickering
stopped. I guess this is systemd eagerly retrying a failed service
until it reaches its timeout.

journalctl -xb revealed that gdm ""could not find drm kms device". I
couldn't find anything useful by searching for that message on Google.
I then checked to see whether the VirtualBox guest utils were
installed. They weren't. So I had to enable unstable in my apt
sources, then
sudo apt -t unstable install virtualbox-guest-utils virtualbox-guest-x11
sudo reboot

gdm works great now.

Suggestions
=========
3. Something needs to be done about whatever in the installer suggests
installing the virtualbox-ose package. Since I clicked OK, I thought
it *did* install something useful for VirtualBox but I don't think it
did.

4. I have not had the #2 problem with other distros. Ubuntu includes
some minimal VirtualBox-compatible driver as part of its default
kernel. Could Debian do the same so that Debian will actually run on
VirtualBox?

5. As far as the drivers go, if they aren't in a Debian release, then
once someone actually gets Debian running, I guess they'll either just
keep whatever drivers they installed the first time. Or maybe they'll
use VirtualBox's guest additions iso to install the drivers. Neither
way offers automatic update of drivers. I feel this situation is worse
from a security perspective than having a Debian package that is at
least updated on major new Debian releases.

Why can't the Security Team treat VirtualBox like how it's been
treating WebKit1? Still have it in the archives but with a prominent
notice that Debian does not provide security updates.

6. Assuming that VirtualBox won't be in the next stable Debian
release, I guess we need a page like mozilla.debian.net for it?

Thanks,
Jeremy Bicha

This must be from back when VBox had better support model. Given its current
status, we should fix the installer and not support VBox there.

You mean the driver provided by the virtualbox-guest-dkms package ?
The easiest would be if VBox worked on upstreaming that driver. For Debian,
carrying that external driver may not be desirable unless the kernel team's
policy changed in recent past.

Hmmm. This one is a worrisome state. But the iso package is part of non-free.
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

Hello Jeremy,
(and security team)


virtualbox-ose is dead and removed, not sure why/who is pulling it in


exactly


probably that suggestion should be updated to virtualbox-guest-x11


it was nacked by Debian Kernel Team when I asked it


fully agree, but I'm not in the position to revert this change


you might want to ask them :)


not sure what it means, but ok for me!

I still think vbox is superior and I have to wait some minutes to make the screen
stop flickering each time I install a new Debian iso in a VM.

I really think not having it working out-of-the-box in a virtual machine is really
a bad user experience.

G.

The usual expectation is that everything in Debian is covered by
reasonable security support. We need to make some exceptions for
technical reasons (as like in webkit, where it's simply not
feasible to backport). Security support for vbox would be feasible,
but fails entirely due to Oracle's policy. If up for them to fix
that.

Cheers,
        Moritz

*Why you have not reply to my email which I send to you, check you email
and reply to me*

control: affects -1 src:virtualbox-guest-additions-iso
control: found -1 virtualbox-guest-additions-iso/5.1.22-1
control: severity -1 serious

Adding guest-additions-iso package, to kick it out from testing again

G.

Hi,

After a private discussion with Gianfranco, I'm retitling this bug and
downgrading its severity. (Gianfranco agrees, at least on the general
lines of argumentation).

The reasoning is as follows.

Virtualbox did not make it into stretch due to this bug, for good
reasons.

We are at the start of the buster release cycle, and we don't know what
will be the status at the time of the freeze. The situation around
security support should be re-evaluated at the beginning of the buster
freeze, but until then, it sounds like a better plan to maximize user
testing and allow virtualbox to migrate to testing.

Security support for unstable/testing is not a problem because we are
tracking new upstream releases anyway, where issues are being addressed
by upstream. Also, there's a public svn repository to get fixes from if
necessary.

Cheers,

Lucas

Hi,

Could you clarify how you intend to handle security issues for virtualbox in
buster? During a brief discussion on irc, the security team made it clear that
they won't handle that (as the package is in contrib and upstream isn't
cooperating), so it would be up to the maintainers to handle that.

Thanks,

Ivo

Hi,

I'm not a maintainer, but I'm in "To:", so I'll reply anyway, as a heavy
user of Virtualbox (mainly through Vagrant).

I don't know if the security support situation around virtualbox has
improved. I suspect it has not.

The situation we have with stretch, where virtualbox is installable via
stretch-backports, is a good compromise for users in my POV. If the
backports team does not make it a requirement for inclusion in
buster-backports that the package is in testing, I wouldn't mind it
staying out of testing during the buster cycle.

(But again I'm not the maintainer)

Lucas

As said on irc:

1) I don't want to ship the package in Buster if the security team can't handle security updates
2) I don't want security team to handle them, I'll in case provide them the stuff that can be sponsored (as we did in the past).

In case the new micro releases are not ship anymore by upstream, we can declare the security support as finished.


So, my solution is "best effort security updates", but only if security team is ok with this approach.

G.

Nah, it’s an Oracle issue. They did the same with MySQL IIRC, which
has nowadays been replaced by MariaDB as this is untenable with the
reliability promises Debian gives.

That is worded in a way to make the sentence wrong. What they do is
not publish security details, so others cannot even support older
versions *themselves*, which is proactively harmful. AIUI you get a
new release and either take it or not, with no separation of patches.

But this is all irrelevant for backports (setting Reply-To appro‐
priately) as n-backports ship whatever is in (n+1) or, if n+1 is
not yet released, testing, and n-backports-sloppy ship whatever
is in (n+1)-backports, so if anything is “not suitable for a stable
release” it is automatically not suitable for backports, either.

There has been discussion of a “not-backports” thing that could be
the scope for this (codenamed “volatile” although that codename was
not well received), but that is also being discussed elsewhere.

bye,
//mirabilos

control: severity -1 normal

Since buster is already released, let's let the package migrate to
testing and upload to backports as before.

Cheers,
Roger

 I'm not sure backports team will be happy with this...and the lack of upstream cooperation is still an issue.

    Il giovedì 22 agosto 2019, 19:56:46 CEST, Roger Shimizu <rogershimizu@gmail.com> ha scritto:

 control: severity -1 normal

Since buster is already released, let's let the package migrate to
testing and upload to backports as before.

Cheers,
Roger

Il giovedì 22 agosto 2019, 19:56:46 CEST, Roger Shimizu <rogershimizu@gmail.com> ha scritto:

Similarly, please remove 5.2.24 from stretch-backports as it wasn't
released in buster for the same reason it wasn't released in stretch.

Hopefully http://fasttrack.debian.net/ will be officially announced soon
and VirtualBox can be uploaded there.
--
Phil Morrell (emorrp1)

Backports team won't complain if the package is in testing.
And I think release team won't complain now since it's not in freezing stage.

Lack of upstream support usually means we won't have it in stable.
But if user decide to use backports by their own choice, they should
be able to do that.

Cheers,

 Hello Roger,
This looks like a good way of hiding the issue, the problem is that I can't just keep backports up-to-date oncestable is released, because it goes out of testing.I had some chat with ftpmasters and release team, and they both agree on the fact that if the package is not maintainable,letting it migrate is something we shouldn't do...
I hope before next stable to solve this...
(btw comaintainers are welcome :) )

Gianfranco

Hi!

* Gianfranco Costamagna [Fri Aug 23, 2019 at 08:33:09AM +0000]:
[...]

I'm trying to understand the current state of this issue. :)

* Gianfranco Costamagna [Wed Sep 04, 2019 at 10:20:03AM +0000]:

[...]

Any news here? Do you have any plans how to provide Virtualbox for
users of stable/buster?

Thanks for your work on the Virtualbox packaging!

regards
-mika-

 Hello, none for now, but there might be a backport-alike debian new repository without restrictions, I might give it a shot soon

    Il giovedì 26 settembre 2019, 13:36:09 CEST, Michael Prokop <mika@debian.org> ha scritto:

 Hi!

* Gianfranco Costamagna [Fri Aug 23, 2019 at 08:33:09AM +0000]:
[...]

I'm trying to understand the current state of this issue. :)

* Gianfranco Costamagna [Wed Sep 04, 2019 at 10:20:03AM +0000]:

[...]

Any news here? Do you have any plans how to provide Virtualbox for
users of stable/buster?

Thanks for your work on the Virtualbox packaging!

regards
-mika-

Hi Friend,
Have a nice day !
Our Company Supply Biodegradable Sugarcane Bagasse Food Containers with FDA,
EN 13432, OK Compost, BPI certificates.
If any needs in these items please feel free to contact me.
Best  Regards
Ella