On 2016-05-13 09:00:59, Antoine Beaupré wrote: > So if we're going to do this painful work, might as well maintain some > qemu interface in wheezy as well. I am not sure I see what additional > cost this would bring: although the attack surface is larger on qemu and > Xen uses only some parts of the Qemu codebase, disclosed vulnerabilities > concern mostly HVM support in Xen, and not the "unused from Xen" qemu > codebase... > > But yeah, this seems exactly stuff that our sponsored Xen support team > should look into. ;)
Did anyone contact the sponsored xen support team yet? How *do* we contact those folks anyways? An almost textbook example of the problems we're talking about here: http://xenbits.xen.org/xsa/advisory-179.html Was marked as EOL in wheezy, but completely ignored the fact that it is a Xen advisory, and that Xen *is* vulnerable! https://security-tracker.debian.org/CVE-2016-3712 https://security-tracker.debian.org/CVE-2016-3710 I would be tempted to mark this as no-dsa in wheezy because in this case, the default video mode is not vulnerable, but what should we do in a case like this? If we do not support Qemu standalone, we probably can't support Qemu in Xen either, which means parts of the Xen functionality is not supported (HVM, for example). How do we inform our users that Xen is supported but HVM is not? Is that a thing we do? For now I've marked the above two as minor issues for both wheezy and jessie. A. -- You Are What You Is - Frank Zappa
