[vlc-devel] vlc: svn commit r24342 (funman)

Rafaël Carré funman at videolan.org
Thu Jan 17 14:50:05 CET 2008


Le Wed, 16 Jan 2008 20:45:01 +0200,
Rémi Denis-Courmont <rdenis at simphalempin.com> a écrit :

> Le Wednesday 16 January 2008 20:18:01 Rafaël Carré, vous avez écrit :
> > > I don't want hackers to:
> > > - up the volume and explode my ears or otherwise change my audio
> > > HW settings,
> >
> > I hope you don't run flash.
> 
> So Flash does it, lets do it too. Come on, this is not a primary
> school backyard.

I just don't consider putting the volume to the max (2 times the normal
setting) harmful

> > > - change the CDDB server so they can learn what CDDA I am playing,
> >
> > But they know already, since they control VLC, no ?
> 
> Maybe there is a Javascript API that I haven't heard of, which can
> access the CD drive, but for some reason, I doubt it.

My point is since a webpage launched the vlc instance, it can play
whatever it wants.

> > > - change the record filter path!!! (arbitrary file overwrite
> > > anyone?),
> >
> >         if( asprintf( &p_sys->psz_file, "%s %d-%d-%d
> > %.2dh%.2dm%.2ds.%s", ( psz_name != NULL ) ? psz_name : "Unknown",
> >                       l.tm_mday, l.tm_mon+1, l.tm_year+1900,
> >                       l.tm_hour, l.tm_min, l.tm_sec,
> >                       p_sys->psz_ext ) == -1 )
> >
> > Oh my god it can overwrite such named files !
> 
> Should the thing be allowed to store large files anywhere (as in, on
> any partition, inside any directory)? Plus having a restrictive
> filename does not mean the problem is not there, won't be published
> on bugtraq, and won't give VLC its (deserved) reputation as one of
> the least secure media player.

I just didn't consider this feature harmful. What I checked is that it
wouldn't be able to overwrite system files.

> > > - change the TLS settings (nevermind it was supposed to be
> > > secure),
> >
> > again, they do control VLC
> 
> If this is the starting hypothesis, I wonder why I bothered
> implementing the safe flag at all, and why you bothered committing
> this crap. If you don't know or understand the x509/TLS trust model,
> it's not my fault. But it all comes down to this very simple issue:
> why flag options you obviously don't understand as safe? And why
> claim you did review them also?

Again, since the items played by VLC are controlled by the webpage
running the plugin instance, I didn't consider changing the
certificates used to authentify the item played was harmful.

I did think before putting this flag, maybe I was wrong doing so.

> > > Every second setting seems wrong to me.
> >
> > Thanks you so much for respecting my work, you lazy bastard.
> 
> Thank you so much for ensuring that VLC gets kicked out of every
> open-source operating system distributions.

The trunk is public, so everyone can check the different commits before
it gets released.

> And for the record, I may be a bastard, but that is not a topic for a
> public mailing opensource list. As for being lazy, considering the
> amount of ungrateful clean up work that I have done for this project,
> I would disagree.
> 

I wouldn't call lazy someone who does work on his free time, I call you
lazy on this particular point of whitelisting the input options.


Since damienf started doing it (his own way) I will just let that issue
to people more experimented than I.

-- 
Rafaël Carré
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20080117/49282faa/attachment.sig>


More information about the vlc-devel mailing list