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

[Ivan Kalvachev]

2007/1/17, Diego Biurrun <diego at biurrun.de>:
> On Wed, Jan 17, 2007 at 03:34:06PM +0200, Ivan Kalvachev wrote:
> > 2007/1/17, Diego Biurrun <diego at biurrun.de>:
> > >On Wed, Jan 17, 2007 at 12:11:36AM +0200, Ivan Kalvachev wrote:
> > >> 2007/1/16, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> > >> >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.
> > >> >A possible consideration would be to change codecs.conf in the sources
> > >> >so that it would not load without manual modification by the user,
> > >> >a I-know-what-I-am-doing similar to the lavf bframes thing...
> > >>
> > >> There is already "release 20061022" parameter in the codecs.conf.
> > >> If the release number is older than the one in the build-in
> > >> codecs.conf then MPlayer should exit with error (saying "Update or
> > >> Delete").
> > >>
> > >> Of course the problem is that this release parameter is not updated on
> > >> every commit.
> > >> I hope we could use the svn system for that. ( if there are no $date
> > >> like macros, then probably via pre/post-commit scripts).
> > >>
> > >> I guess this would handle all cases of users stupidity and developers
> > >> memory leaks.
> > >
> > >It does not, look at the bug report that inspired this patch.
> >
> > I still don't understand what the problem is.
> > Why the user had codecs.conf with removed driver entry?
> > It can't be because codecs.conf is old, as "rv3040" is (probably)
> > older than "rv40".
>
> No.
>
> > Then, where have this codecs.conf  came from?
> >
> > Diego, I personally think you are trying to fix symptoms, without
> > finding the root of the problem.
> >
> > If this codecs.conf is put there by debian (or any other) package,
> > they won't have any problems installing default .mplayer/config with
> > "codecs-file=/some/obscure/codecs.conf".
> >
> > And of course this would mean not only that this patch would be
> > useless, but that now we much check BOTH .mplayer/codecs.conf and
> > .mplayer/config when looking at obscure codecs problems... (e.g. old
> > releases still lurking around:).
>
> Nonsense.  Please read the bug report before making wild assumptions and
> jumping to conclusions.

Are you not reading my mails anymore? Look above.

Above, you are claiming that checking codecs.conf "release" parameter
would not help in the case of _this_ bugreport. It is only natural for
me to assume that the bug is not caused by old codecs.conf, as
"release" is created to catch old versions.

My proposal was MPlayer to refuse to start until user removes or
update its copy of codecs.conf. This would help not only in case of
very old mplayer version, but also in case of developer who forgot his
copy after experimenting. The only thing that is really necessary for
this to work is to always have valid date in the current svn
codecs.conf.

Actually it seems that it is bug in codec-cfg.c ; If the "release" is
smaller than the build-in one, then parser will return error without
parsing the codecs.conf, this way ignoring it.
However the release value is not remembered and if codecs.conf is old
enough to don't have "release" parameter, it will never think there is
something wrong.

I'll send patch later.