[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [qubes-devel] Re: Critique of the Xen Security Process


On 11/10/2015 05:52 AM, Lars Kurth wrote:
Hi everyone,

firstly I wanted to thank everyone for raising this issue. I wanted to point out that we are not talking about a security process here, but the development process. Or more accurately the cost of writing more secure code and the relative importance of security compared to features. And of course the recent increase of relative importance of "built-in security as a feature" since Snowden.

On 9 Nov 2015, at 16:31, Franz <169101@xxxxxxxxx <mailto:169101@xxxxxxxxx>> wrote:

    (Please note that all of the above are my personal views, i.e. I'm
    explicitly not speaking on behalf of the project.)

It seems positions are antithetic with no possible compromise in view. Sadly this is a general problem of FOSS software: developers tend to do what they like and not what users request. And who can blame developers for that? After all they are working as volunteers so they deserve to do what they like. No possible compromise.

I don't think this is a fair statement: more than 95% of developers working on Xen are employees of large organisations. And they follow the priorities that their employers set. The same is true in Linux and for comparable projects and of course for proprietary software developers. Blaming open source developers, is simply wrong and not constructive.

Nevertheless, Xen is a creature of interfaces that purport to uphold contracts. These (software engineering, not legal) contracts are explicitly security-themed... the software is promising to isolate processes from each other and protect against privilege escalation. The Xen project itself asserts that it is focused on the security benefits of the hypervisor (to the point of invoking "microkernel" in Xen's description), not mere administrative convenience.

What seems to be missing from the defense of Xen project so far in this thread is a level of acknowledgement of this very important aspect of twenty-first century software development: Can you honor what your interfaces communicate to your audience? Its true that some FOSS projects do not care for modern methodologies (which are greatly about concept and mindset), but should Xen be that way?

Should Xen project also be a blanket absolution of "blame"? And is the corporate status of some of its contributors a proper justification for being blame-less (perhaps we can think of them like members of 'The Borg')? I think not.

This is the trap that FOSS projects most commonly fall into: 'We are free to publish because of liberty, but you are not free to criticize.' Its odd when you think about it. This is the squandering of user motivation and valuable feedback.

In fact, throughout 2014 and 2015, the project has received complaints from several large vendors that the Xen Project today is too rigorous with code reviews compared to Linux, KVM...

Famous last words before a Heartbleed-scale media circus ensues?

I can certainly raise this suggestion with the Advisory Board and see whether we can make some funds available. However, the board has already invested nearly 50% of its entire budget in Test Infrastructure and is planning to continue to spend in this area at roughly this proportion of the projects budget. However, we do not have huge amounts of funds: thus, what we could do with bounties would necessarily be limited.

I personally also looked at other ways to change the cost-benefit equation. One example is the Feature Maturity Lifecycle (see http://lists.xen.org/archives/html/xen-devel/2015-11/msg00609.html & http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01992.html) which aims to use better classification to change behaviour of contributors.

I do hope, that this discussion can remain constructive. De-motivating the good work many of our developers (and in particular code reviewers) are doing, is really not helpful in this context.

It does seem to me that the suggestion of a Long-Term Support (LTS) release is a constructive one, among the other suggestions that Joanna made. The FML you cite is interesting, but seems to be aimed squarely at developers. You are bound to get better results if the expectations of users change along with developers, so LTS releases may be the better idea.

Best Regards

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.