[vlc-devel] vlc: svn commit r24345 (damienf)

[Rémi Denis-Courmont]

Le Thursday 17 January 2008 00:01:33 Damien Fouilleul, vous avez écrit :
> outside of the list i've already blacklisted, do you know of any such
> 'combinations'.  I'm not sure what you really mean with your web
> server example, please give a concrete example.

There are example in the other thread. That pretty much shows how much 
blacklisting has already failed. It simply cannot work.

> > With blacklisting, we are 99,9% sure that someone will find yet
> > another harmful combination after then next release, especially as we
> > start  adding new options and forget thinking about their security
> > implications. 
>
> What you really are advocating is that some developers are more
> 'enlightened' than others, and that basically until some code has been
> approved by a 'committee'  it is considered unsafe, etc...

No, what I am pointing out, is that nobody will ever review the whole sets of 
options properly, and the only way to achieve some level of security is to 
disable everything, except for options that have EXPLICITLY been considered.

> i've nothing against code review, but its scope definitely spans
> beyond option definition and use, one can write code which is quite
> unsafe and and make use of no option.

We surely have many exploitable bugs in the various parsers. I fail to see why 
we should ignore known or very likely problems just because we will be 
missing others.

> VLC quality is refined and improved by the fact that the code is open
> source,

And hence more vulnerable to analysis by malign people.

> anyone can review it and make comments and provide patches to  
> improve its usefulness, security, etc...

First anyone being allowed is not at all the same as anyone being able to.

Second, it is fairly clear that VLC is NOT undergoing decent review, whether 
security-wise or not.

> for me this is a good enough approach to code review and it has been proven
> to be quite successful,


> Linux is a testament to that. 

Linux has a large bunch of experienced hackers that are *paid* *full-time* to 
debug and test it.

VLC does not even have a paid developper (merely some part-time consultant), 
and not even a testing framework...

> Whitelisting solves nothing, it's just a pessimistic approach as you'd
> rather sacrifice functionality for an alleged sense of security.
> Basically, it's just paranoia.

We have professionnal users, and their IT department may well be paranoid. And 
then we have open-source distros, and they tend to be a lot more paranoid 
than the average Windows downloader.

That's a part of our user base we just cannot ignore, as an open-source 
project.

> I'm not saying that my approach is the ultimate solution to security,
> unfortunately, there is no such solution. It's just an improvement on
> what is currently in place, and provides IMHO a balanced trade-off
> between usability, security and code complexity.

How does allowing options that nobody will ever and/or should ever use, ever 
enhance usability? Meuuh has even given a list of the options which Free 
needs.

> If you think you got a better solution, please be my guest ....

I just think blacklisting leaves the problem wide open, and I was not the only 
one last time we discussed this.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20080117/809ba02a/attachment.sig>