Re: heads-up: 38 cleanup-maint patches

[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_.
    
    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! :)