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>
---
The entire security-process.pandoc file can be found here:

https://gitlab.com/xen-project/people/gdunlap/old-governance
---
 security-policy.pandoc | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/security-policy.pandoc b/security-policy.pandoc
index 76c25e1..23b6381 100644
--- a/security-policy.pandoc
+++ b/security-policy.pandoc
@@ -30,6 +30,20 @@ Vulnerabilities reported against other Xen Project teams will be handled on a
 best effort basis by the relevant Project Lead together with the Security
 Response Team.
 
+The Xen Project Security Team will issue XSAs, including patches, for
+all upstream versions of the Xen Project Hypervisor currently under
+security support.
+
+It is often the case that downstreams have a longer product support
+lifecycle than upstream Xen provides.  Downstreams are invited to
+inform the security team of the Xen version and support window of
+these products.  If a security issue is discovered which does not
+affect upstream "security supported" versions, but does (or may)
+affect a supported product containing one of these older versions, the
+downstreams will be informed privately.  If at least one of the
+downstreams chooses to participate in the development of a patch, then
+an XSA will be issued according to our normal process.
+
 Specific process
 ----------------
 
-- 
2.42.0

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

On Fri, Oct 27, 2023 at 3:26 PM George Dunlap <george.dunlap@cloud.com> 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>
> ---
> The entire security-process.pandoc file can be found here:
>
> https://gitlab.com/xen-project/people/gdunlap/old-governance

...and you can see this as a pull request here:

https://gitlab.com/xen-project/people/gdunlap/old-governance/-/merge_requests/1

 -George