Re: [PATCH] security-process.pandoc: Statement on issuing XSAs for older versions of Xen

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

[-- Attachment #1: Type: text/plain, Size: 1731 bytes --]

On Fri, Oct 27, 2023 at 03:26:02PM +0100, George Dunlap wrote:
> We recently had a situation where a security issue was discovered
> which only affected versions of Xen out of security support from an
> upstream perspective.  However, many downstreams (including XenServer
> and SUSE) still had supported products based on the versions affected.
> 
> Specify what the security team will do in this situation in the
> future.  As always, the goal here is to be fair and helpful, without
> adding to the workload of the security team.  Inviting downstreams to
> list versions and ranges, as well as expecting them to be involved in
> the patch, gives organizations without representation in the security
> team the opportunity to decide to engage in the security process.  At
> the same time, it puts he onus of determining which products and which
> versions might be affected, as well as the core work of creating and
> testing a patch, on downstreams.
> 
> Signed-off-by: George Dunlap <george.dunlap@cloud.com>

Hi George,

This is interesting proposal, indeed it looks fair, given XenServer and
SUSE basically have this option already. In practice, I'm not sure how
useful that would be for Qubes OS, given we don't consider DoS-only bugs
security issues needing coordinated disclosure. It feels like infoleak
or privesc bugs are either found earlier or affect newer versions too
and in both cases they fall into standard security support anyway. But
that very well might be just an impression due to no such policy
earlier. 

In any case, in Qubes OS we support Xen 4.17 and 4.14 - the latter only
for about 6 months more.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]