Re: [PATCH 3/7] build: require Automake >= 1.11.6

[Bernhard Voelker]

On 08/31/2012 09:19 AM, Jim Meyering wrote:
> Bernhard Voelker wrote:
> 
>> On 08/30/2012 02:13 PM, Stefano Lattarini wrote:
>>> Now that we use AM_TESTS_ENVIRONMENT, we should require at least
>>> Automake >= 1.11.2; but since all the Automake version until 1.11.5
>>> are vulnerable to CVE-2012-3386:
>>>
>>>   <https://lists.gnu.org/archive/html/automake/2012-07/msg00023.html>
>>>
>>> it's even better to require 1.11.6.
>>
>> I don't like this idea: I'm personally using OpenSuSE 12.1
>> (which is still the current version) which comes with 1.11.1.
>> To satisfy sc_vulnerable_makefile_CVE-2012-3386, I've patched
>> my /usr/share/automake-1.11/am/distdir.am.
>>
>> So the question I'm putting forward is:
>> shouldn't COREUTILS be at least compileable on the latest
>> version of the major distributions?
> 
> Hi Bernhard,
> 
> First, let's agree on terminology.  Anyone can compile
> the tools on nearly any type of system, assuming they
> start from a distribution tarball.

Ok, that sounds good.

>  I think you are talking
> about a different process: building from git cloned sources.
> That is a different process altogether.
>
> In a sense, I agree that it should be doable on most major
> distributions, but you won't like the qualifying "but".
> I think most major distributions should distribute much
> newer versions of tools like autoconf, automake and gettext.
> They are not like libraries.  I've been lobbying to update
> these tools in older RHEL, with partial success.
>
> I.e., I think upstream development should be tracking the
> latest features of the latest tools.  In particular, while
> autoconf and gettext are not evolving quickly these days,
> automake *is*, and given the big return on investment in
> non-recursive make (more efficient builds, day to day) and
> the prospect of even cleaner/better Makefile.am files with the
> upcoming automake-ng, we would be remiss not to take advantage
> of contributions like those from Stefano.
>
> However, even if your distribution chooses not to support this
> aspect of development, you can easily work around that deficiency
> by building all of the latest tools yourself and installing
> them in a private "bin" directory early in your shell's search path.

Sorry, maybe I was a bit angry yesterday, because my git environment
didn't work anymore. Another problem was README-prereq, because the
version number of autoconf needed is not 2.62 but at least 2.64
- from coreutils' point of view ...but automake required even 2.68.

Finally, automake didn't install cleanly because it complained about
the missing symlink from ~/coreutils/deps/share/aclocal to
aclocal-1.11, urgh.

After finally getting autoconf+autmake working (and running bootstrap
etc in coreutils), a `make syntax-check` failed because of the
renaming of the test scripts.
The attached patch silenced the syntax-check (although I'm not sure if
I fixed sc_long_lines in the right way).


> This script automates the process for you, downloading all of the
> latest tarballs, checking signatures (on all bug pkg-check, which
> appears to have none), building, optionally running make check,
> and installing:
> 
>   http://people.redhat.com/meyering/autotools-install

Cool!

> If you run it, be sure to heed this advice in its --help output:
> 
>     If you've already verified that your system/environment can build working
>     versions of these tools, you can make this script complete in just a
>     minute or two (rather than about an hour if you let all make check
>     tests run) by invoking it like this:
> 
>         autotools-install --prefix=$HOME/autotools --skip-check
> 
> 
>> I think a check like sc_vulnerable_makefile_CVE-2012-3386
>> is enough.
>>
>> BTW: If you insist on this patch, then you also have to adapt
>> README-prereq.
> 
> Good point.  Thanks.  I'm tempted to remove the build instructions from
> README-prereq, and instead to include my autotools-install script under
> script and referencing it.  WDYT?

+1


> I'd have to change autotools-install to add xz, and possibly to remove
> (or make optional) libtool and pkg-config, since those packages are not
> needed to build coreutils.
> 

Have a nice day,
Berny

fix-syntax-check.patch
Description: Text Data