[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 3/7] build: require Automake >= 1.11.6
From: |
Bernhard Voelker |
Subject: |
Re: [PATCH 3/7] build: require Automake >= 1.11.6 |
Date: |
Fri, 31 Aug 2012 09:44:37 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 |
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
- [PATCH 4/7] tests: avoid use of '-T' in shebang line to enable perl taint mode, (continued)
- [PATCH 7/7] tests: get rid of the 'shell-or-perl' auxiliary script, Stefano Lattarini, 2012/08/30
- [PATCH 3/7] build: require Automake >= 1.11.6, Stefano Lattarini, 2012/08/30
- Re: [PATCH 3/7] build: require Automake >= 1.11.6, Jim Meyering, 2012/08/30
- Re: [PATCH 3/7] build: require Automake >= 1.11.6, Bernhard Voelker, 2012/08/30
- Re: [PATCH 3/7] build: require Automake >= 1.11.6, Jim Meyering, 2012/08/31
- Re: [PATCH 3/7] build: require Automake >= 1.11.6,
Bernhard Voelker <=
- Re: [PATCH 3/7] build: require Automake >= 1.11.6, Stefano Lattarini, 2012/08/31
- Re: [PATCH 3/7] build: require Automake >= 1.11.6, Jim Meyering, 2012/08/31
- Re: [PATCH 3/7] build: require Automake >= 1.11.6, Bernhard Voelker, 2012/08/31
- Re: [PATCH 3/7] build: require Automake >= 1.11.6, Jim Meyering, 2012/08/31
- Re: [PATCH 3/7] build: require Automake >= 1.11.6, Bernhard Voelker, 2012/08/31
- Re: [PATCH 3/7] build: require Automake >= 1.11.6, Erik Auerswald, 2012/08/31
- Re: [PATCH 3/7] build: require Automake >= 1.11.6, Jim Meyering, 2012/08/31
[PATCH 5/7] tests: detect missing perl at configure runtime, Stefano Lattarini, 2012/08/30
[PATCH 6/7] tests: add .sh and .pl suffixes to shell and perl tests, respectively, Stefano Lattarini, 2012/08/30