From LWN:
From the NVD entries:
CVE-2016-5501: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect confidentiality,
integrity, and availability via vectors related to Core, a different
vulnerability than CVE-2016-5538.
CVE-2016-5538: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect confidentiality,
integrity, and availability via vectors related to Core, a different
vulnerability than CVE-2016-5501.
CVE-2016-5605: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.1.4 in Oracle Virtualization allows remote
attackers to affect confidentiality and integrity via vectors related
to VRDE.
CVE-2016-5608: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect availability via vectors
related to Core, a different vulnerability than CVE-2016-5613.
CVE-2016-5610: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect confidentiality,
integrity, and availability via vectors related to Core.
CVE-2016-5611: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect confidentiality via
vectors related to Core.
CVE-2016-5613: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect availability via vectors
related to Core, a different vulnerability than CVE-2016-5608.
As of systemd 231, the LD_LIBRARY_PATH fix applied in the installPhase of rkt's
build was no longer valid, causing rkt to fail to work. This patch changes the
path to point to the new location of libsystemd, which is in ${systemd.lib}.
This introduces VirtualBox version 5.1.6 along with a few refactored
stuff, notably:
* Kernel modules and user space applications are now separate
derivations.
* If config.pulseaudio doesn't exist in nixpkgs config, the default is
now to build with PulseAudio modules.
* A new updater to keep VirtualBox up to date.
All subtests in nixos/tests/virtualbox.nix succeed on my machine and
VirtualBox was reported to be working by @DamienCassou (although with
unrelated audio problems for another fix/branch) and @calbrecht.
Upstream changelog without bug numbers:
* GUI: fixed issue with opening '.vbox' files and it's aliases
* GUI: keyboard grabbing fixes
* GUI: fix for passing through Ctrl + mouse-click
* GUI: fixed automatic deletion of extension pack files
* USB: fixed showing unknown device instead of the manufacturer or
product description under certain circumstances
* XHCI: another fix for a hanging guest under certain conditions, this
time for Windows 7 guests
* Serial: fixed high CPU usage with certain USB to serial converters
on Linux hosts
* Storage: fixed attaching stream optimized VMDK images
* Storage: reject image variants which are unsupported by the backend
* Storage: fixed loading saved states created with VirtualBox 5.0.10
and older when using a SCSI controller
* Storage: fixed broken NVMe emulation if the host I/O cache setting
is enabled
* Storage: fixed using multiple NVMe controllers if ICH9 is used
* NVMe: fixed a crash during reset which could happen under certain
circumstances
* Audio: fixed microphone input (5.1.2 regression)
* Audio: fixed crashes under certain conditions (5.1.0 regression)
* Audio: fixed recording with the ALSA backend (5.1 regression)
* Audio: fixed stream access mode with OSS backend (5.1 regression,
thanks to Jung-uk Kim)
* E1000: do also return masked bits when reading the ICR register,
this fixes booting from iPXE (5.1.2 regression)
* BIOS: fixed 4bpp scanline calculation
* API: relax the check for the version attribute in OVF/OVA appliances
* Windows hosts: fixed crashes when terminating the VM selector or
other VBox COM clients
* Linux Installer: fixed path to the documentation in .rpm packages
(5.1.0 regression)
* Linux Installer: fixed the vboxdrv.sh script to prevent an SELinux
complaint
* Linux hosts: don't use 32-bit legacy capabilities
* Linux Additions: Linux 4.8 fix for the kernel display driver
* Linux Additions: don't load the kernel modules provided by the Linux
distribution but load the kernel modules from the
official Guest Additions package instead
* Linux Additions: fix dynamic resizing problems in recent Linux
guests
* User Manual: fixed error in the VBoxManage chapter for the
getextradata enumerate example
The full upstream changelog with bug numbers can be found at:
https://www.virtualbox.org/wiki/Changelog-5.1#v6
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
In 294281596833b8d83ba90c03b792d31b868f46d7, the dependencies for Qt 5
were passed using buildEnv with all the development binaries, headers
and libs. Unfortunately, the build output references that environment
which also increases the size of the runtime closure.
The upstream makefile assumes a common Qt 5 library path, but that's not
the case within Nix, because we have separate paths for the Qt 5
modules.
We now patch the makefile to recognize PATH_QT5_X11_EXTRAS_{LIB,INC} so
that we can pass in the relevant paths from Qt5X11Extras.
In summary, the closure size goes down to 525559600 bytes (501 MB)
instead of 863035544 bytes (823 MB) with vbox-qt5-env.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Putting the kernel modules into the same output path as the main
VirtualBox derivation causes all of VirtualBox to be rebuilt on every
single kernel update.
The build process of VirtualBox already outputs the kernel module source
along with the generated files for the configuration of the main
VirtualBox package. We put this into a different output called "modsrc"
which we re-use from linuxPackages.virtualbox, which is now only
containing the resulting kernel modules without the main user space
implementation.
This not only has the advantage of decluttering the Nix expression for
the user space portions but also gets rid of the need to nuke references
and the need to patch out "depmod -a".
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We now no longer need to update VirtualBox manually, which has a few
advantages. Along with making it just easier to update this also makes
the update procedure way less error-prone, for example if people forget
to bump the extension pack revision or to update the guest additions.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Just a small updater which should fetch the latest sha256sums from the
upstream site and check whether the current version is the latest one.
The output is in a JSON file in the same directory, which then will be
used by the Nix expressions to fetch the upstream files.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
See #11567.
Furthermore, it renames pythonPackages.dbus to pythonPackages.dbus-
python as that's the name upstream uses.
There is a small rebuild but I couldn't figure out the actual cause.
The following parameters are now available:
* hardeningDisable
To disable specific hardening flags
* hardeningEnable
To enable specific hardening flags
Only the cc-wrapper supports this right now, but these may be reused by
other wrappers, builders or setup hooks.
cc-wrapper supports the following flags:
* fortify
* stackprotector
* pie (disabled by default)
* pic
* strictoverflow
* format
* relro
* bindnow
Updates VirtualBox from version 5.0.12 to 5.0.14.
Upstream changes are (without bug IDs):
* GUI: properly limit the number of VCPUs to the number of physical cores
on Mac OS X
* Audio: fixed a bug which prevented loading a saved state of a saved
guests with HDA emulation (5.0.12 regression)
* Audio: don't crash if the backend is unable to initialize
* Audio: fixed audio capture on Mac OS X
* Storage: fixed a possible crash when attaching the same ISO image
multiple times to the same VM
* BIOS: properly report if two floppy drives are attached
* USB: fixed a problem with filters which would not capture the device
under certain circumstances (5.0.10 regression)
* ExtPack: black-list Extension Packs older than 4.3.30 due to
incompatible changes not being properly handled in the past
* Windows hosts: fixed a regression which caused robocopy to fail
* Linux hosts: properly create the /sbin/rcvboxdrv symbolic link (5.0.12
regression)
* Mac OS X hosts: several fixes for USB on El Capitan
* Linux Additions: fixes for Linux 4.5
Full upstream changelog with bug IDs can be found at:
https://www.virtualbox.org/wiki/Changelog
The reason I was reluctant to merge this before were these symbol lookup
errors:
vboxsf: Unknown symbol VBoxGuest_RTMemTmpFree (err 0)
vboxsf: Unknown symbol VBoxGuestIDCCall (err 0)
vboxsf: Unknown symbol VBoxGuest_RTSemFastMutexRequest (err 0)
vboxsf: Unknown symbol VBoxGuest_RTSemFastMutexRelease (err 0)
vboxsf: Unknown symbol VBoxGuest_RTLogRelGetDefaultInstanceEx (err 0)
vboxsf: Unknown symbol VBoxGuest_RTErrConvertToErrno (err 0)
vboxsf: Unknown symbol VBoxGuest_RTSemFastMutexCreate (err 0)
vboxsf: Unknown symbol VBoxGuest_RTSemFastMutexDestroy (err 0)
vboxsf: Unknown symbol VBoxGuest_RTMemContFree (err 0)
vboxsf: Unknown symbol VBoxGuest_RTSemMutexRelease (err 0)
vboxsf: Unknown symbol VBoxGuestIDCOpen (err 0)
vboxsf: Unknown symbol VBoxGuest_RTAssertShouldPanic (err 0)
vboxsf: Unknown symbol VBoxGuest_RTMemContAlloc (err 0)
vboxsf: Unknown symbol VBoxGuest_RTSemMutexRequest (err 0)
vboxsf: Unknown symbol VBoxGuest_RTSemMutexCreate (err 0)
vboxsf: Unknown symbol VBoxGuest_RTMemTmpAllocTag (err 0)
vboxsf: Unknown symbol VBoxGuest_RTSemMutexDestroy (err 0)
vboxsf: Unknown symbol VBoxGuest_RTAssertMsg1Weak (err 0)
vboxsf: Unknown symbol VBoxGuestIDCClose (err 0)
vboxsf: Unknown symbol VBoxGuest_RTAssertMsg2Weak (err 0)
However, after testing it against 5.0.12, the same errors occur there as
well, so it is likely related to our VM tests.
This makes pythonPackages.sqlalchemy the most up to date revision (it
was called sqlalchemy_1_0 before), and maintains the various “legacy”
versions available as pythonPackages.sqlalchemyX for X in {7,8,9}.
All derivations that required `sqlalchemy_1_0` now require `sqlalchemy`
while those that required `sqlalchemy` now require `sqlalchemy7`.
The derivations are not changed, only the attribute names they are
bound to.
