BBC TV: Click: Free=beer and facebook-flaming

[Graeme West]

On 18 May 2008, at 11:42, Florian Weimer wrote:

> * Ben Finney:
>
>> Florian Weimer <fw at deneb.enyo.de> writes:
>>
>>> * MJ Ray:
>>>
>>>> didn't mention how free (as in freedom) software allows any random
>>>> end-user to check or have it checked.
>>>
>>> How is this different from proprietary software?
>>
>> Either this is obvious, or I'm not understanding the question.
>>
>> Software that doesn't give the user freedom to inspect the source  
>> code
>> and pass it on to others, doesn't allow the user to check the  
>> software
>> themselves or have someone else check it and pass it along to them.
>> This is distinct from free software, which allows all of this.
>
> These days, there's hardly any widely used piece of proprietary  
> software
> for which you can't get the source code.  You can't make  
> modifications,
> and there might be restrictions with whom you can share your results,
> but security reviews based on source code are definitely possible.
>
> It's also not clear if source code availability is that helpful for
> uncovering security bugs.
> _______________________________________________
> Discussion mailing list
> Discussion at fsfeurope.org
> https://mail.fsfeurope.org/mailman/listinfo/discussion


Hi Florian,
I'm not sure about your assertions about security.

> These days, there's hardly any widely used piece of proprietary  
> software
> for which you can't get the source code.

Do you have any evidence to support this view?

All sorts of concerns come into proprietary software companies'  
decisions about access to source code: competition, corporate culture,  
industrial espionage (think Huawei and Cisco) the importance of the  
party seeking source code (Microsoft gives more code to governments,  
than to individual researchers, for example).

Certainly there are a few proprietary software companies who have  
widely open-sourced. But generally speaking one of the defining  
aspects of a proprietary software company is that it doesn't allow  
source code access. Those who do tend to use the restrictive licenses  
that you imply.

Even if you do get full access, it's unlikely that you would actually  
be able to build and run it from source and verify that it's identical  
to the binaries you already have. So you can't actually say anything  
about the security of the binaries you're already running.

> there might be restrictions with whom you can share your results

This rather defeats the point checking for security holes. You might  
miss a bug that someone else will notice. If you can't share that  
information, the bug goes un-patched for you.

Of course, responsible disclosure procedures are needed, but that's  
pretty trivial.

> It's also not clear if source code availability is that helpful for
> uncovering security bugs.

I don't agree with this.

De-compilation is a nasty business, and auditing something as a 'black  
box' closed-source binary allows limited scope for evaluating the  
security of the internal workings of the system. The programme output  
might be correct, but it is difficult to expose - or evaluate -  
internal vulnerabilities.

I think it's possible to make the argument that source code  
availability is neutral for security _overall_ (though I think there  
are other reasons why that's not true), but not that it doesn't help  
uncover security bugs.

That more bugs are found is one of the key advantages of free and open  
source software. That you can patch them yourself - something you  
can't do with the type of 'read-only' licenses for commercial software  
to which you refer, is another key advantage. "Given enough eyeballs,  
all bugs are shallow."


Regards,

Graeme West