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

Diego Biurrun diego at biurrun.de
Wed Jan 17 08:57:39 CET 2007


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?

The "security" argument cuts both ways.  You could slip somebody a
codecs.conf file to make them vulnerable ...

> 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".

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?

> > 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.

Diego




More information about the MPlayer-dev-eng mailing list