[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug#370282: Worth mentioning that Gnome needs a fix for newer Autoco

From: Loïc Minier
Subject: Re: Bug#370282: Worth mentioning that Gnome needs a fix for newer Autoconf?
Date: Mon, 5 Jun 2006 10:51:03 +0200

On Sun, Jun 04, 2006, Paul Eggert wrote:
> Well, the general topic is already in NEWS.  I doubt whether the
> Autoconf maintainers can keep track of which versions of which other
> packages will run into problems with the datarootdir change (not to
> mention half a dozen similar changes :-).

 (Yes, but NEWS doesn't pop up automatically on Debian upgrades.  My bug
 report was incorrect in this respect and should have requested a
 warning in NEWS.Debian that end-users / end-developers should read NEWS
 because of important changes.)

> First, Autoconf is supposed to warn about the suspicious usage of
> datadir without defining datarootdir.  Did the warning not work for
> you?  If so, can you show us how to reproduce the problem easily?

 Autoconf first warned of the non-handling of datarootdir in my
 Makefiles when I tried to only update ./configure, and didn't complain
 anymore when I updated **/Makefile.in, but the problem lies in a m4
 macro which runs at configure time, and has nothing to do with
 datarootdir in Makefiles IMO.

> Second, that promiscuous 'eval' can lead to trouble.  First, it
> assumes that exactly one level of indirection will be right, which is
> not portable to future versions of Autoconf.  Second, if localedir
> contains special characters they can cause arbitrary shell code to be
> executed.

 I can only agree with you and cry of despair to see dangerous "eval"
 calls like the one I pointed out.  You reach the same conclusion than I
 do, and that is that the macro was completely broken in the first

> Something like this code (which I haven't tested) would be safer:
> for i in . . . . . . . . . . . . X; do
>   test $i = X && AC_MSG_ERROR([too many levels of indirection in localedir])
>   case $localedir in
>     *'"'* | *'`'* | *'\'* | *'$('*)
>       AC_MSG_ERROR([invalid character sequence in localedir]);;
>     *\$*) eval "localedir=\"$localedir\"" ||
>       AC_MSG_ERROR([invalid variable in localedir]);;
>     *) break;;
>   esac
> done

 This looks like a workaround to me and could help for the interim where
 I want that macro to continue working while we sort out all Makefile.am
 from various software relying on the macro to use a future-proof method
 of passing a directory.

> Kind of a hassle, huh?  But this sort of hassle is inevitable once you
> start using 'eval' with uncontrolled input.

 Agreed, thanks for the snipset.

Loïc Minier <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]