Re: Automake and whitespace in pwd

[Jim Meyering]

Ralf Wildenhues <address@hidden> wrote:
> Hello Jim,
>
> * Jim Meyering wrote on Tue, Nov 25, 2008 at 10:59:36AM CET:
>>
>> I think it's a fine idea to disallow bogus (and potentially dangerous)
>> absolute names in automake's sanity.m4, but the existing code is not
>> sufficient.
>
> Agreed.
>
>> To demonstrate (as non-root), create a directory named 'a;$(halt);'
>> cd into it, unpack an automake/autoconf-using tarball, then run
>> "$PWD/configure".
>
> OK, let's improve the situation here.  I agree that whitespace in
> $srcdir does not work, same with some other special characters.
> However, I dislike forbidding whitespace in `pwd`, I don't want to
> needlessly make Automake less useful for some legitimate uses.

Hi Ralf,

Nice patch.

On one hand, I like the idea of accommodating the rare srcdir `pwd` that
contains white space.  On the other hand, since so many Makefile.am files
are unprepared for the resulting names, I wonder if it's better to protect
the users, and give Makefile.am writers a way to guarantee that "bad"
`pwd` won't leak into places like $(top_srcdir).  This started with my
auditing some Makefile.am files, adding quotes to protect against uses
of potentially-tainted variables like $(top_srcdir).  I found that many
uses needed additional quoting.  In addition, while single quoting was
usually enough to protect them, sometimes I had to use double quotes,
or a mix, to accommodate $$() and $$i-style shell constructs.  Relying on
that sort of correctness is fragile, in that there's nothing to actively
prevent regressions, unless you write build tests that exercise each
and every Makefile rule in the offending scenario.

What do you think of adding an automake option that would let the package
maintainer specify that s/he does not want to expose package users to
the risk of malfunction due to a tainted srcdir name?

This feels like a package-level policy question, after all.
Maintaining correctly-quoted Makefiles is hard enough without
having to worry about such embedded white space.
Sure, any package maintainer can add a few lines to configure.ac
to make start-up code examine $srcdir and fail upon irregularity,
but if automake were to make this easy, I'd be much more likely
to use it than if it means copying around a custom .m4 file or
repeating a short snippet of code in each package's configure.ac.

That said, this patch looks fine.  "make check" passed
and it did the right thing in a couple of manual test scenarios.

Jim

P.S. Would you please re-post your latest parallelizing-tests patches?
I missed that functionality when running automake's lengthy,
single-threaded "make check" on a quad-core system.

> diff --git a/NEWS b/NEWS
> index 27f8368..2721e69 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -138,6 +138,13 @@ New in 1.10a:
>
>    - The `missing' script works better with versioned tool names.
>
> +  - The Automake macros and rules cope better with whitespace in the
> +    current directory name, as long as the relative path to `configure'
> +    does not contain whitespace.  To this end, the values of `$(MISSING)'
> +    and `$(install_sh)' may contain suitable quoting, and their expansion
> +    might need `eval'uation if used outside of a makefile.  These
> +    undocumented variables may be used in several documented macros.

Want to mention that the sanity test now rejects `pwd`
containing unsafe bytes?

   - Automake's early configure-time sanity check now diagnoses an
     unsafe absolute source directory name and makes configure fail.