Re: [Xen-devel] Xen Project Security Whitepaper v1 is ready for community review

[Steven Haigh <netwiz@xxxxxxxxx>]

Hi Lars,

I think this is an excellent start.

A specific concern that I have is when we get into a state between releases 
and XSAs where you cannot take the current release and then apply all released 
/ embargo'ed XSA patches.

The current reasoning for this is that XSA patches are developed on top of the 
staging git branches. While this is still acceptable, I believe we need the 
ability to roll a new point release that will allow end users to be up to 
date.

Expecting things to always be built for distribution from the staging git 
branch is somewhat of a hassle - as in the current case of 4.9.1. With 
publicly released XSAs, you cannot begin with a release of 4.9.1 and patch all 
post-released XSAs.

While this does not seem to happen very often - I would estimate around 4-5 
times in the past decade - we should encourage an out-of-schedule point 
release. This can be based off the current state post-XSA of the staging 
branch - but enables reproducable builds at the very least.

Recently, this situation happened with the batch of XSAs before 4.10.1 was 
released, and is currently the case of 4.9.1 + existing XSAs.

This potentially leaves end users in limbo until the next point release rolls 
around - without rebasing off a semi-random git commit (which is not 4.9.1 or 
4.9.2 - but something inbetween) - or backporting massive amounts of commits 
to a release.

As this is a somewhat rare occasion, if only a handful of commits need to be 
cherrypicked, I would see this as fine. If it requires many more, I believe it 
should trigger an out-of-cycle point release.

-- 
Steven Haigh

📧 netwiz@xxxxxxxxx       💻 https://www.crc.id.au
📞 +61 (3) 9001 6090    📱 0412 935 897

On Friday, 18 May 2018 8:13:55 PM AEST Lars Kurth wrote:
> Dear Community Members,
> 
> just under 3 months ago, we started a community consultation titled "Xen
> Security Process Consultation: is there a case to change anything?" (see
> https://lists.xenproject.org/archives/html/xen-announce/2018-02/msg00000.ht
> ml). As promised, I would collate the input - together with further analysis
> trying to genuinely consider the implications of what respondents to the
> consultation have been suggesting - in a white paper. The white paper is
> attached and contains
 
> 1) Baseline: an analysis of our XSAs and how we dealt with XSAs in the
> recent past
 2) Results from the Community Consultation
> 2.1) Feedback received from a community consultation
> 2.2) Analysis
> 3) Recommendations and policy changes - some is quite extensive to try and
> tries to evaluate the impact of policy changes, which would result if we
> implemented solutions to issues highlighted by our users.
 
> The next step is for community members to provide public feedback. If it
> turns out there is a case for changes/improvements, I will condense the
> output of this discussion into a concrete change proposal (or a series
> thereof) to be voted on in the usual way. This may require several
> iterations. Note that the document contains workflow and tools related
> feedback, which I did not anticipate. Some issues highlighted should be
> easy to fix, others will require additional discussion on xen-devel@, such
> as
 * Inconsistent Meta Data and XSA prerequisites
> * Git baseline of patches
> * Release cycle related (issues)
> 
> The document tries to label all discussion items, such that it is easy to
> comment. I normally attach a converted markdown version: however, this is
> unwieldly in this case, because there is a large number of tables and
> images. Thus, I have created a google doc copy which allows anyone with the
> following link
> https://docs.google.com/document/d/1FbGV4ZZB9OU8SI4b9ntnM-l6NaQLND8Yfd9u11V
> 5Q5A/edit?usp=sharing to comment on sections of the document. If you do,
> please make sure you identify yourself in the comment and/or also highlight
> feedback in the e-mail thread discussion that will follow this document.  
> 
> Please also let us know areas of the whitepaper you agree with, as this will
> make it overall easier to identify how much consensus there would be to
> address specific issues and proposals in the document. Otherwise the
> discussion will primarily focus on points of contention, while other areas
> where in fact there may be consensus, will be missed. If there is little or
> no feedback (either positive or negative), we have to assume that people
> are happy with the status quo and that there is only a weak case for
> changes. 
 
> Best Regards
> Lars
> 
> 
>

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel