Bug 443589 - RFE: Upgrade gm4
RFE: Upgrade gm4
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: m4 (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Vitezslav Crhonek
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 443958
  Show dependency treegraph
 
Reported: 2008-04-22 08:51 EDT by Ralf Corsepius
Modified: 2008-04-24 08:01 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-23 08:11:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ralf Corsepius 2008-04-22 08:51:45 EDT
Description of problem:
According to Eric Blake <ebb9@byu.net> (upstream) gm4, all versions of gm4 prior
to 1.4.11 suffer from serious bugs, which are not unlikely to break autoconf and
to cause autoconf to generate broken configure scripts.

I would recommend to upgrade m4 on all Fedora and RH releases.

Particularily delicate: The versions of m4 as being shipped with RHEL 4 and
below are such kind of old contemporary autoconf doesn't work on them.
=> Not upgrading m4 on these distros disqualifies RHEL <= 4 
as development environment.
Comment 1 Eric Blake 2008-04-22 14:53:28 EDT
Some clarification: all versions of GNU m4 1.3 through 1.4.10 have at least one
known stack-overflow (arbitrary code execution) bug, fixed in m4 1.4.11, when
the -F option is abused.  Additionally, autoconf 2.62 explicitly requires m4
1.4.5 or greater (because earlier versions can generate corrupt configure
files), but can safely use 1.4.5 (now 21 months old) without tickling the
security bugs present in those older versions, and without generating corrupt
configure files.  Earlier versions of autoconf also require m4 1.4.5 or greater
to avoid corrupt configure files, although the dependency was implicit rather
than explicit:
http://lists.gnu.org/archive/html/bug-autoconf/2006-11/msg00025.html
http://lists.gnu.org/archive/html/autoconf-patches/2007-02/msg00000.html

Therefore, while upgrading to m4 1.4.11 would be nice, it is sufficient for
autoconf's purposes to upgrade only to m4 1.4.5 (or at least backport the
security fixes and the tracing bug fix to an earlier m4), and this should be
done whether or not you upgrade to autoconf 2.62 in the near future, since all
versions of autoconf are vulnerable to the pre-1.4.5 bug.

Meanwhile, on BSD-based platforms, m4 1.4.10 also generates corrupt configure
files; but as RHEL uses glibc and not BSD stdio, this is not an issue for RHEL.
 And eventually, when m4 1.6 is released, it will be incompatible with the stock
autoconf 2.59, although the autoconf team has prepared patches that against 2.59
that will allow it to work with m4 1.6.
http://git.sv.gnu.org/gitweb/?p=autoconf.git;a=shortlog;h=refs/heads/branch-2.59
Comment 2 Vitezslav Crhonek 2008-04-23 08:11:12 EDT
Ralf, thanks for report, Eric, thanks for clarification.

I updated to m4-1.4.11 in rawhide.
I will not do rebase of m4 in older Fedoras - newest Fedora with m4 version
bellow 1.4.5 is Fedora 5.

Ralf, if you're RHEL customer, please contact support to resolve this in RHEL.
(My opinion: RHEL5 - m4-1.4.5 (no changes IMHO), RHEL4 - m4-1.4.1 (maybe
backport security fixes and tracing bug fix?), RHEL3 - m4-1.4.1 (we fix only
hight priority security problems, so no changes IMHO).)

Thanks!
Comment 3 Ralf Corsepius 2008-04-23 08:33:03 EDT
(In reply to comment #2)

> Ralf, if you're RHEL customer, please contact support to resolve this in RHEL.
I am not - I am simply co-leader and maintainer of an opensource project
(http://www.rtems.org) which has supported CentOS4 as one of their development
platforms.

As our development will be based on autoconf-2.62 (which mandates using
gm4-1.4.5), not upgrading RHEL4 (and CentOS4) simply closes out CentOS4 and
RHEL4 from being used as a development platform for your works and will 
force us to discontinue supporting CentOS4/RHEL4.

I had hoped to be able to avoid this step - Your decision however makes it
inevitable.

Comment 4 Vitezslav Crhonek 2008-04-24 04:50:40 EDT
Ralf, I did no decision in RHEL case. Please file a bug against m4 and
particular RHEL version to let product management consider and prioritize your
request. Do the same with autoconf, if you wish new version in RHEL.

Note You need to log in before you can comment on or make changes to this bug.