Xen forgets recent patches in new maintenance release The Xen Project has announced a new maintenance release for version 4.6.1 of its hypervisor, but along the way has admitted it forgot to add some recent patches. “Note that …. due to two oversights the fixes for both XSA-155 and XSA-162 have only been partially applied to this release,” says the announcement of the maintenance …
Although it is regrettable that this release has two issues which have not been fully applied, maybe a little perspective is in order. Looking at the release notes it seems that XSA-162 has been applied to the project's QEMU fork, but not to QEMU upstream. Which is of course a different project (albeit a dependency) on Xen. For convenience, the project is shipping upstream QEMU with the source tarball. What this highlights is that managing dependencies across open source projects can be hard, with different projects following different standards and timelines.
XSA-155 is a complex patch with several versions that go across Linux, Xen and QEMU. Linux is not shipped as source within the xen release. As such, to be protected against this bug, an administrator has to do quite a bit of homework to make sure that no bits are missing.
> But the omission will be a trap for the unwary who make less frequent upgrades, or those installing
> the software for the first time. If they dare, given the project's stumbles.
Of course this does not make a nice user experience for people that consume Xen directly. But then, if you consume source code and build it yourself, rather than use a distro where you don't have to think about such things, you probably don't expect the same experience that you would have when using installable binary packages.
This post has been deleted by its author
We'd like to offer a comment from the Xen Project to this story for background on our process and thinking here. We detected the missing patches before the official release, but towards the end of the release process. We then had a discussion whether to make a new release which would have forced us to skip a release number (aka move from 4.6.0 to 4.6.1.1 or 4.6.2) or release 4.6.1 with two security patches which were incomplete, and document what is missing. At this point, we had to decide whether to re-tag (and thus re-number the release) or whether to document any issues. A similar issue happened in 2013, when we released Xen 4.1.6.1 instead of Xen 4.1.6. At that time it became clear that many consumers of Xen have difficulties with a version number that does not fit into the normal version numbering pattern, which led to Xen 4.1.6.1 not being widely used.
Because we documented the missing patches in the release notes and release announcement, nobody who downloads the signed source tarballs from our official download page should be unaware of the missing security patches. In addition, the tarballs from our official download pages are primarily consumed by Linux distros, which will apply the missing patches and any additional security fixes that turn up between Xen 4.6.1 and their own release. Most of our users consume binaries from those distros. The other group of users which consume the tarballs are power users, which are used to applying security patches.
This leaves the question, why we cannot re-spin a release without changing the version number if issues are discovered late during the release process. Firstly, making a release involves both extensive testing and also has a security dimension. Normally, after testing succeeds we create a signed tag in the git tree. This means that there is a secure way of accounting for where the tarball came from. We then rebuild and do additional testing, write the release notes, do some more checking and sign the tarballs. The missing patches were discovered on Thursday, well before the official release on Monday, but after we created the signed tag. Signed tags cannot be removed, as they have to be tamper proof.
There has been some confusion about Xen Project and our security processes because we do things differently than a lot of other projects out there. We handle and document every single security bug that is raised with the project to ensure that even low-severity bugs are fixed and known. Many projects and commercial software products do not do this and only handle bugs with severe security implications in recommended configurations, rather than handling even minor bugs in non-recommended configurations like we do. Essentially, we do go through this process as it makes everyone more secure and provides more control to those that use Xen.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
