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

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

Hi all,

I tried to summarize this thread (also see 
https://lists.xenproject.org/archives/html/xen-devel/2018-05/threads.html#01127),
 CC'ing everyone that contributed or requested to be on the thread.  I also 
moved comments into 
https://docs.google.com/document/d/1FbGV4ZZB9OU8SI4b9ntnM-l6NaQLND8Yfd9u11V5Q5A/edit#
 

2.2.2 A XSA-Reissues
I still need to do some number crunching based on a script I have not written 
yet.

2.2.4. A Too many security supported Xen releases
It seems that the 6 months cycle may be too short. The suggestion was to run a 
similar consultation about release cycle compared to this. Originally, it was 
primarily HW vendors pushing for shorter release cycles. I will bring this up 
at the Summit in a Design Session and report back to the list.

R1) Recommendation: Batching
There seems to be sufficient consensus to spell out batching as an explicit 
option in the security policy, as long as it is not mandatory. I think it also 
makes sense to clarify the "Embargo and Disclosure Schedule" section: it 
affords quite a lot of flexibility to the security team, but it seems that some 
people are interpreting the 1 week for a fix + 2 weeks embargo as fixed, which 
at best means the text is not clear enough.

R2) Recommendation: Workload
It seems that my suggestion to not specifically address this through a 
mechanism in the policy and leave it up to the security team to manage batch 
size has consensus. Assuming we add batching as an explicit option in the 
policy, we should also make this explicit.

R3) Recommendation: Predictability
A few people believe that a more predictable XSA release schedule would help. 
At the same time, there are valid concerns about the security team being 
overloaded. I am wondering whether we should trial batching towards some 
undocumented batch release date for a bit and see what the impact is: the 
policy would allow us to do this. We could also state in the policy that we are 
trialling this.

2.2.3 B. Git baseline of patches
This created quite a bit of discussion and we did learn a few things:
* From the thread, having to cherry pick a small (around 5-6) patches have to 
be cherry-picked for XSAs to apply to tarballs this appears to be seen as OK 
for most users. More patches are a problem
* Recently this issue has become much worse, because some security fixes (or 
pre-requisites for them) have been developed in public and some XSAs required 
significant backporting to be able to be run
* A point release has usually <50% security fixes
* There is no appetite amongst existing point release maintainers to maintain a 
staging branch and an XSA + pre-requisites only branch

In other words, we are at a stale-mate. I see two ways around it
a) Find an additional volunteer to maintain XSA + pre-requisites only branches 
for releases
b) Find some tooling/test based solution which exposes issues applying XSAs on 
the last releases of a staging branch for a point release. This is a little bit 
of a half-baked idea, but it may be worthwhile looking into. 
For example, we could create an OSSTEST, that checks out the last released 
stable branch and applies outstanding XSAs and pre-requisites based on the 
meta-info to it (e.g. via xsatool or a variant thereof). This test would fail, 
if an XSA does not apply, which implies that the pre-requisites are incomplete. 
If all XSAs apply, we can run the full OSSTEST on it. The test could also 
produce a list of git commits from staging that include XSAs and pre-requisites 
that can be applied in order. This should in theory - if doable - help 
downstreams which are struggling with this problem, while flagging up potential 
issues to stable maintainers early. Any thoughts? Would this be workable and if 
so, would it actually help?

Best Regards
Lars

    

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