heads-up: 38 cleanup-maint patches

[Jose E. Marchesi]

I will soon push the following clean-up patches.
It was nearly 400KBuncompressed, so I'm attaching the compressed
version:

Thanks Jim. Much appreciated :)

AC_PREREQ(2.62)
-AM_INIT_AUTOMAKE([1.11.1 parallel-tests])
+AM_INIT_AUTOMAKE([1.11.1 no-dist-gzip dist-xz color-tests parallel-tests])

I would like to continue distributing gzip tarballs along with xz
tarballs.

[Jim Meyering]

Post by Jose E. Marchesi
I will soon push the following clean-up patches.
It was nearly 400KBuncompressed, so I'm attaching the compressed
Thanks Jim. Much appreciated :)
AC_PREREQ(2.62)
-AM_INIT_AUTOMAKE([1.11.1 parallel-tests])
+AM_INIT_AUTOMAKE([1.11.1 no-dist-gzip dist-xz color-tests parallel-tests])
I would like to continue distributing gzip tarballs along with xz
tarballs.

Hi Jose,
Thanks for the review.

Re continuing to distribute gzip-compressed tarballs,
I have to ask "Why?"

My motivation to avoid gzip is partly because there have been
so many CVEs, that I want to discourage gzip use where I can.
I have spent too much time reading its hard-to-maintain code,
and find xz to be far superior both on design/readability, and
on the performance front. Perhaps I resent gzip for taking some
time out of a christmas/new-years vacation to deal with the first
CVE of 2010 :-)

How many people do you know who run gpg --verify
before uncompressing a distribution tarball? Those who skip
that step may be vulnerable to some gzip 0-day. Sure, it's unlikely,
but I have far less confidence in gzip's code than I do in xz's.

Distributing xz-only tarballs has worked fine for 3 years
in other GNU projects: coreutils, grep, diffutils and parted.

If you feel strongly about it, you're welcome to include your
justification in a patch and push it.

Jim

[Jose E. Marchesi]

Re continuing to distribute gzip-compressed tarballs,
I have to ask "Why?"

My only concern is breaking backwards compatibility in the distribution.
Failing to provide .gz tarballs at the usual location _will_ break a
good number of scripts, documents and protocols all around, creating
inconveniences for many users.

I don't feel particularly sanguine about it (xz rocks) but I don't
really think the potential inconveniences are worth the benefits of
distributing xz _only_.

[Jim Meyering]

Post by Jim Meyering
Re continuing to distribute gzip-compressed tarballs,
I have to ask "Why?"
My only concern is breaking backwards compatibility in the distribution.
Failing to provide .gz tarballs at the usual location _will_ break a
good number of scripts, documents and protocols all around, creating
inconveniences for many users.
I don't feel particularly sanguine about it (xz rocks) but I don't
really think the potential inconveniences are worth the benefits of
distributing xz _only_.

While gzip use may be ok, in general, I have been sufficiently exposed
to its internals, and recall too well the massive amount of fall-out from
those CVEs, that I have no qualms about any such minor inconvenience.
Weaning users off of gzip is to avoid the risk/impact (however small) of
a future gzip CVE. People have adapted just fine to downloading
and unpacking coreutils and grep's .tar.xz files for years.
What makes sed different?

[Jose E. Marchesi]

Post by Jim Meyering
Re continuing to distribute gzip-compressed tarballs,
I have to ask "Why?"
My only concern is breaking backwards compatibility in the distribution.
Failing to provide .gz tarballs at the usual location _will_ break a
good number of scripts, documents and protocols all around, creating
inconveniences for many users.
I don't feel particularly sanguine about it (xz rocks) but I don't
really think the potential inconveniences are worth the benefits of
distributing xz _only_.

While gzip use may be ok, in general, I have been sufficiently exposed
to its internals, and recall too well the massive amount of fall-out from
those CVEs, that I have no qualms about any such minor
inconvenience.

I sympathize, but having to re-deliver data-packs and even entire
projects only because a distribution url/location of a third-party
product changed is not funny either. It can be very expensive (as in
money) and frustrating depending on how many scripts or documents have
to be updated, tests and benchmarks re-executed (days, even weeks) and
stupid quality/management protocols followed. Not to mention it can
create delays on the projects and angry managers shouting at you because
of the budge.

The above happened to me several times in my job and man it sucks when
it happens. On the contrary, I never ever triggered a security bug in
gzip, to my knowledge.

Weaning users off of gzip is to avoid the risk/impact (however small) of
a future gzip CVE. People have adapted just fine to downloading
and unpacking coreutils and grep's .tar.xz files for years.
What makes sed different?

Well, they (we) definitely adapted. "Just fine"? Hopefully! :)

[Jim Meyering]

Post by Jim Meyering

Post by Jim Meyering
Re continuing to distribute gzip-compressed tarballs,
I have to ask "Why?"
My only concern is breaking backwards compatibility in the distribution.
Failing to provide .gz tarballs at the usual location _will_ break a
good number of scripts, documents and protocols all around, creating
inconveniences for many users.
I don't feel particularly sanguine about it (xz rocks) but I don't
really think the potential inconveniences are worth the benefits of
distributing xz _only_.

While gzip use may be ok, in general, I have been sufficiently exposed
to its internals, and recall too well the massive amount of fall-out from
those CVEs, that I have no qualms about any such minor
inconvenience.
I sympathize, but having to re-deliver data-packs and even entire
projects only because a distribution url/location of a third-party
product changed is not funny either. It can be very expensive (as in
money) and frustrating depending on how many scripts or documents have
to be updated, tests and benchmarks re-executed (days, even weeks) and
stupid quality/management protocols followed. Not to mention it can
create delays on the projects and angry managers shouting at you because
of the budge.

The URL changes every time, regardless, though admittedly, the
.gz to .xz change will cause a few to adapt. I suspect most get
the link from the announcements.

Post by Jim Meyering
The above happened to me several times in my job and man it sucks when
it happens. On the contrary, I never ever triggered a security bug in
gzip, to my knowledge.

And I hope you never do.
There have been exploitable bugs in many many tools.
That you have not personally noticed an abuse says little:
with a targeted exploit, you would be very unlikely to notice.

Post by Jim Meyering
Weaning users off of gzip is to avoid the risk/impact (however small) of
a future gzip CVE. People have adapted just fine to downloading
and unpacking coreutils and grep's .tar.xz files for years.
What makes sed different?
Well, they (we) definitely adapted. "Just fine"? Hopefully! :)

Thanks.

[Jim Meyering]

Post by Jose E. Marchesi
I will soon push the following clean-up patches.
maint: update bootstrap from gnulib

...

One more, to avoid a gcc warning when building with
--enable-gcc-warnings on modern systems: