Re: Debian-specific Autoconf patches

[Ralf Wildenhues]

Hi Paul,

* Paul Eggert wrote on Sat, May 27, 2006 at 12:33:22AM CEST:
> 
> Getting the 'eval' stuff under control ought to be fairly high
> priority, as otherwise arbitrary shell commands might be executed
> inadvertently.

Well, some instances of this bug are almost a decade old.

> +** AC_TRY_COMMAND, AC_TRY_EVAL
> +  These never-documented macros have been marked with a comment
> +  saying that they may be removed in a future release.

Do you intend to then replace them with something safer?
(It may be useful to give this hint, so they don't come
complaining that we are killing interfaces without replacement;
also, it then becomes clear that such a replacement is not here
yet.)

> --- lib/autoconf/general.m4   22 May 2006 15:54:09 -0000      1.919
> +++ lib/autoconf/general.m4   26 May 2006 22:28:18 -0000
> @@ -1145,7 +1145,6 @@ m4_define([_AC_INIT_PREPARE],
>  ac_configure_args=
>  ac_configure_args0=
>  ac_configure_args1=
> -ac_sep=
>  ac_must_keep_next=false
>  for ac_pass in 1 2
>  do
> @@ -1184,9 +1183,7 @@ dnl exit don't matter.
>         -* ) ac_must_keep_next=true ;;
>       esac
>        fi
> -      ac_configure_args="$ac_configure_args$ac_sep'$ac_arg'"
> -      # Get rid of the leading space.
> -      ac_sep=" "
> +      ac_configure_args="$ac_configure_args '$ac_arg'"
>        ;;
>      esac
>    done

This code has a backwards compatibility problem.  Not the change you
just made, but the changes from sometime longer ago (partially from
before 2.59).  What is the problem?  ac_configure_args contains a list
of single-quoted args now, and did not before.

This breaks third-party macros that use ac_configure_args (e.g., to
simulate a AC_CONFIG_SUBDIRS with slightly different semantics) and
still assume the single quotes to be absent.  Interestingly, Autoconf
2.59 has this bug itself (in _AC_OUTPUT_SUBDIRS)!

The quoting apparatus of 2.59 had already bit-rotted: this snippet show
the breakage:

|     case $ac_arg in
[...]
| dnl If you change this globbing pattern, test it on an old shell --
| dnl it's sensitive.  Putting any kind of quote in it causes syntax errors.
|   [  *" "*|*"   "*|*[\[\]\~\#\$\^\&\*\(\)\{\}\\\|\;\<\>\?\"\']*)]
|       ac_arg=`echo "$ac_arg" | sed "s/'/'\\\\\\\\''/g"` ;;
|     esac
|     case $ac_pass in
|     1) ac_configure_args0="$ac_configure_args0 '$ac_arg'" ;;

The logic is wrong here, and not what was intended: the single-quote
_escaping_ is only necessary if the arg contains a single quote.  But in
earlier times, the _enclosing_ in single quotes was intended to be done
only if the argument matches that ugly long pattern.  Which actually
made sense (see 2.50 which had this better).

But of course that did not expose the rare matching error that a
  configure --config-cache=ou\ ch

would have given you, namely that you have to have to use this kind of
costruction...

> --- lib/autoconf/status.m4    23 May 2006 23:30:57 -0000      1.108
> +++ lib/autoconf/status.m4    26 May 2006 22:28:18 -0000
> @@ -930,7 +930,7 @@ if test "$no_recursion" != yes; then
>    # Remove --cache-file and --srcdir arguments so they do not pile up.
>    ac_sub_configure_args=
>    ac_prev=
> -  eval set x "$ac_configure_args"
> +  eval "set x $ac_configure_args"
>    shift
>    for ac_arg
>    do

...instead of this:

  for ac_arg in $ac_configure_args

which was common (and wrong!) and used up to 2.59.

I'm not sure about the best way to solve this: one possibility is to
document the "we single-quote all arguments now" strategy, and tell
people to use eval to access $ac_configure_args if they have to.  This
is a viable way, and makes their macros work with 2.59, and makes them
safe for weird arguments now.  The danger is that we may eventually come
up with another way of quoting that suits us better, and then we have
another incompatibility...

The other way would be to resurrect the "we only enclose the arguments
in single-quotes if they actually contain special characters", like so:

   case $ac_arg in
[  *" "*|*"   "*|*[\[\]\~\#\$\^\&\*\(\)\{\}\\\|\;\<\>\?\"\']*)]
     ac_arg=\'$ac_arg\' ;;
   *)
     ac_arg=$ac_arg ;;
   esac

This would make many older macros work (again), but of course work only
with safe configure arguments (and faile in the rare case).

In any case, the current documentation doesn't reflect these changes,
whenever they happened.

What do you think?

> @@ -1213,7 +1217,7 @@ ac_cs_version="\\
>  m4_ifset([AC_PACKAGE_NAME], [AC_PACKAGE_NAME ])config.status[]dnl
>  m4_ifset([AC_PACKAGE_VERSION], [ AC_PACKAGE_VERSION])
>  configured by $[0], generated by m4_PACKAGE_STRING,
> -  with options \\"`echo "$ac_configure_args" | sed 
> 's/[[\\""\`\$]]/\\\\&/g'`\\"
> +  with options \\"`echo "$ac_configure_args" | sed 's/^ / /; 
> s/[[\\""\`\$]]/\\\\&/g'`\\"

The first `s' verb in that sed script looks like a no-op to me.

Cheers,
Ralf