Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

[Matt Wilson <msw@xxxxxxxxx>]

On Tue, Oct 21, 2014 at 01:32:46PM +0100, Ian Campbell wrote:
> On Thu, 2014-10-09 at 00:06 +0100, Ian Jackson wrote:
> > 
> >   Please provide URLs which are accessible and legible on mobile phone
> >   browsers, which do not require cookies enabled to load, and which
> >   are useable with text mode browsers, browsers which do not execute
> >   Javascript, and with screen readers and other accessibility
> >   software.  If the member of the Xen Project Security Team who
> >   processes your application finds that their usual web browser does
> >   not display the required information, when presented with the URLs
> >   in your email, your application might be delayed or even rejected.
> 
> While I appreciate where you are coming from I don't think it is the
> place of this policy to rail against the crapitude of the modern web and
> try and enforce our own standards on things (much as I would like too).
> 
> I don't think it is unreasonable to expect that members of the security
> team who typically run a browser with this crud disabled (which includes
> myself) would load up their special sandboxed/throwaway browser with a
> default config when faced with this sort of thing.
> 
> That said, the bits about accessibility seem less unreasonable, on the
> basis that its not beyond the realms of possibility that someone
> processing an application might not have the option of turning off a
> screenreader etc.

Due to travel last week for LinuxCon EU and Linux Plumbers Conference
I've not been able to put together a reply to all the points raised a
the start of this thread.

On this point in particular, back in 2012 [1] I suggested that all
membership requests should be discussed in public on a community email
list like xen-devel, or another email list to avoid noise. The Xen
Project Security Team shouldn't have to evaluate petitions for
membership while managing an embargoed issue. I brought this up again
in 2013 [2] regarding the Coverity process.

This process works quite well for the distros email list, where
requests for membership requests are discussion on oss-security (a
public list). Protecting embargoed details should be our primary
concern here, and every time we increase the distribution of this
information we are increasing the risk it will leak. This deserves a
rigorous public debate, not a decision made under fire or undue
pressure.

--msw

[1] http://lists.xenproject.org/archives/html/xen-devel/2012-07/msg00122.html
[2] http://lists.xenproject.org/archives/html/xen-devel/2013-08/msg03085.html

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel