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

[Ivan Kalvachev]

2007/1/17, Ivan Kalvachev <ikalvachev at gmail.com>:
> 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'm wrong on this.
as expected it requires "release" to be the first parameter.

there is still something fishy.