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

[Chris Laprise <tasket@openmailbox.org>]

Hello...

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@gmail.com 
>> <mailto:169101@gmail.com>> 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
> Lars
>
>