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

[Michael Niedermayer]

Hi

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


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

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"


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


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


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070117/1d1c2c07/attachment.pgp>