[MPlayer-dev-eng] [PATCH] Do not read codecs.conf files by default

[Diego Biurrun]

On Wed, Jan 17, 2007 at 01:40:37PM +0100, Michael Niedermayer wrote:
> 
> On Wed, Jan 17, 2007 at 08:57:39AM +0100, Diego Biurrun wrote:
> > On Wed, Jan 17, 2007 at 02:02:53AM +0100, Michael Niedermayer wrote:
> > > 
> > > On Wed, Jan 17, 2007 at 12:16:37AM +0100, Diego Biurrun wrote:
> > > > On Mon, Jan 15, 2007 at 11:01:34PM +0100, Reimar Döffinger wrote:
> > > > > On Mon, Jan 15, 2007 at 08:03:33PM +0100, Diego Biurrun wrote:
> > > > > > IMO dynamic codecs.conf loading should be an optional,
> > > > > > disabled-by-default feature that devs can compile-in if they want.
> > > > > 
> > > > > Going that far, as Michael pointed out, would be a bad idea, among the
> > > > > reasons security considerations.
> > > > 
> > > > I'd call this esoteric at best.  If you can edit codecs.conf to try to
> > > > avoid security problems you might as well recompile 
> > > 
> > > and so can you recompile ssh, apache, ... after they based on the same
> > > arguments stop caring about their configuration files
> > 
> > Sure, if there is a security hole you update your packages.  What's so
> > special about this situation?
> 
> well, maybe there is no security fix around? think of binary win32 codecs
> as an example

If you are security paranoid you will surely not use binary codecs, will
you?

> the thing also is to have a minimal set of enabled features for security
> so if one win32 codec is needed all which arent needed could be disabled
> codecs.conf is how id do that ...

You can disable codecs from the command line / config file as well:

vc=-foo,-bar,

Editing codecs.conf is never necessary unless you want to tweak codec
parameters, fiddle with color spaces, add FourCCs.  In other words only
if you are developing MPlayer.  It's easy to recompile or use
-codecs-file in such a case.

> > The "security" argument cuts both ways.  You could slip somebody a
> > codecs.conf file to make them vulnerable ...
> 
> people who would install a random unchecked config file will also install
> a random .bashrc so this argument is meaningless
> 
> 
> > > iam fine with a hard failure but blindly ignoring a config file and
> > > doing something else then whats written in the file is IMO not ok
> > 
> > I think we're having a semantic misunderstanding here.
> > 
> > A configuration file is a file a program reads to get information and
> > adjust parameters according to that information.  Should I commit my
> > patch codecs.conf will simply stop being a configuration file.  So it's
> > not "blindly ignored".
> 
> it doesnt matter why the users condecs.conf is not read anymore, what
> matters is that the user is not aware of the change which could lead
> to security issues

I maintain that this is an esoteric example.  The change would of course
be mentioned in the release notes.  If somebody is paranoid enough to fear
codecs.conf files, reading release notes can be expected.

> the only argument i can see here would be
> "mplayer is a big security risk so we dont care about making it a little
> bigger"

But it's a valid argument IMO.  If you are so paranoid as to be afraid
of your media player then you should take appropriate security measures
so as to never be affected by such a problem, i.e. run MPlayer as a
separate non-privileged user that cannot read your files, in a
chroot/virtual machine/different computer.

> > We had the same situation with per-file configuration files.  They used
> > to be config files, they no longer are.  Now they are "blindly ignored".
> > What is the difference?  IMO none.  MPlayer changed its behavior and no
> > longer reads them by default.  So?
> 
> per file config files arent used for disabling (possibly) insecure codecs

They could, see above.

> > > > or avoid the problematic media.
> > > 
> > > how? check every file with a hexeditor?
> > 
> > No, avoid the specific file types altogether, i.e. not play ASF files,
> > RTSP streams or whatever until you are secure again.
> 
> yes thats what i meant, you need a hexeditor for this
> X.avi can be a asf file, and no `file X.avi` is also not usefull it
> could easily identify a file differently from mplayer

'file X.avi' will tell you what it is if you're paranoid and in this
case you should have more effective security measures in place anyway,
see above.

Diego