Subject: Re: bug#76197: [PROPOSED] gzip: drop support for the GZIP env var

From: Lasse Collin <[email-masked]>
Date: Sun, 23 Feb 2025 13:54:01 +0200

On 2025-02-19 Paul Eggert wrote:
> So I installed the attached patch instead into Savannah master gzip.
> It means gzip will pay attention to -1..-9, --rsyncable, and
> --synchronous

This sounds reasonable. It unambiguously prevents glitches in scripts.
For example, GZIP=-v may seem innocent but it affects --list output too
which some scripts parse. Also, -v undoes -q, and -q affects exit
status. There are safe use cases for GZIP=-v, but losing that feature
shouldn't be a major loss (it would hurt more if -v provided a
real-time progress indicator).

I wonder if -n (--no-name) should be allowed. GZIP=-9n was perhaps the
most common use case I had. It was with pipes, and nowadays -n is the
default for pipes anyway, so it doesn't matter for me.

Hypothetically, someone somewhere might rely on GZIP=-n when
compressing regular files. If -n is silently ignored, a script might
silently start producing .gz files with timestamps and filename
metadata. If someone is worried about that, they possibly have seen the
deprecation warning already and might have modified their script as
well, so the risk should be low. I don't have any examples of such use
cases, I'm just pondering what kind of tiny risks there could be.

Some script might expect the metadata to be stored, and GZIP=-n could
break it. I suspect such use cases are rare nowadays. Preserving the
filename was more important when OSes with short file names were still
in common use. Thus, I think the probability of negative surprises is
low if GZIP=-n is allowed. But I also understand that -n is an option
that affects more than just compression ratio, and that is the reason
why the commit dropped -n from GZIP. I don't have a clear opinion here.

> but will silently ignore everything else in GZIP. The idea is that a
> garbage GZIP value shouldn't disrupt normal operations.

I have mixed feelings about this. I understand that this way garbage in
GZIP cannot break scripts by making gzip fail. Also, if someone has
GZIP=-9n for pipe use, a silently-ignored -n will keep it working like
before, being compatible with both very old and current gzip versions.

On the other hand, it can be confusing that some options, that used to
work, no longer work for no apparent reason. One has to look at the
manual to figure it out. Typos won't be caught either.

How about printing a message to stderr if something is ignored in GZIP?
zstd and lz4 do that with their env vars. Even a vague message like "one
or more arguments in the GZIP environment variable were ignored" would
do if a more specific message is cumbersome to implement.

Such a message can break some special uses that check if something
was written to stderr, but those should be rare enough (they should
unset GZIP). After all, the current deprecation message about GZIP
usage was considered acceptable to add.

> These options shouldn't cause the bigger glitches (and perhaps even
> security hazards) that behavior-oriented options can cause.

I understand well that if everything was allowed in GZIP and someone
actually used that freedom in a wrong way, bad things could happen. What
I don't understand well is how big the risks are in practice. gzip and a
few other tools did or do suppport unrestricted options from env vars
for a long time. I haven't seen any security alerts about them, but that
doesn't mean that they don't or won't exist. I wouldn't add an
unrestricted env var to a new tool, but modifying existing tools always
has backward compatibility concerns.

I'm happy that the important functionality of GZIP is preserved. Thanks!

-- 
Lasse Collin