coreutils
[Top][All Lists]
Advanced

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

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


From: Erik Auerswald
Subject: Re: [PATCH 3/7] build: require Automake >= 1.11.6
Date: Fri, 31 Aug 2012 09:47:51 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hi Jim,

On Fri, Aug 31, 2012 at 09:19:19AM +0200, 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?
> 
> First, let's agree on terminology.  Anyone can compile
> the tools on nearly any type of system, assuming they
> start from a distribution tarball.  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.

It has happened that Debian Sid (unstable) did not have new enough
autotools to build coreutils from cloned git sources. That usually stops my
urge to contribute at that time. ;-)

Last time I checked Sid had new enough autotools, but this might well change
during the Wheezy freeze.

> 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.

IMHO that additional hassle might discourage casual contributors.

Anyway, I don't even know _how_ old autotools 1.11.2 is, so I'm not
objecting to this actual requirement. I'd just like to raise awareness
of this aspect.

> 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

Please consider the following patch to that script:

---8<------8<------8<------8<------8<------8<------8<------8<------8<---

--- autotools-install.orig      2012-08-31 09:26:20.000000000 +0200
+++ autotools-install   2012-08-31 09:28:46.000000000 +0200
@@ -22,7 +22,7 @@
 
 Options:
  --prefix=PREFIX    install tools under specified directory
- --skip-check       do not run "make check" (this can save 50+ min)
+ --skip-check       do not run \"make check\" (this can save 50+ min)
  --help             display this help and exit
 
 For example, to install programs into \$HOME/autotools/bin, run this command:
@@ -31,7 +31,7 @@
 
 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"
+minute or two (rather than about an hour if you let all \"make check\"
 tests run) by invoking it like this:
 
   $prog_name --prefix=\$HOME/autotools --skip-check

---8<------8<------8<------8<------8<------8<------8<------8<------8<---

> > 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?

I prefer written build instructions to a script. The script could be
offered as a help on distributions lacking current enough autotools.

Regards,
Erik



reply via email to

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