On 2025-02-10 Paul Eggert wrote:
> The GZIP environment variable is too hazardous.
I looked at old mailing list threads to understand why the GZIP
environment variable was deprecated in the first place. The discussion
about deprecating the GZIP environment variable was a decade ago, so I
understand if commenting it now won't make a difference anymore. Take
this post as a final "are you sure" before you proceed, not as a start
of a new long discussion.
It seems that the story starts in grep where GREP_OPTIONS was creating
real-world problems.[1] GREP_OPTIONS was deprecated and then removed
completely. Trouble-free uses of GREP_OPTIONS were fairly limited
(perhaps --color=auto might have been such), so removing it seemed
reasonable. Specifically, it was unacceptable that many scripts would
need to unset GREP_OPTIONS.
In gzip, bug#20104 [2] refers to troubles caused by GREP_OPTIONS. The
thread doesn't mention or reference any real-world problems with GZIP
though. There are scripts that need to unset GZIP, but most scripts have
no reason to do that. I'm not saying that GZIP can never cause trouble,
I'm only saying it's less common than it was with GREP_OPTIONS.
gzip hasn't allowed arbitrary options in GZIP for years, which prevents
people from doing the silliest things. While it was a good change, I
suspect it didn't matter much in practice that --decompress or --suffix
were allowed in GZIP. If people do things that are *obviously* silly,
they can expect silly results.
Among reasonable use cases, one person had used GZIP to set the default
compression level.[3] GZIP=--synchronous could be a sensible use case
too but that option isn't allowed in GZIP.
For me, the use case for GZIP (and also TAR_OPTIONS) is injecting extra
options in specific situations without a need to modify any files. That
is, I don't keep those set all the time. Injecting options this way
is a bit hacky but it's convenient too. If something breaks in these
situations, it's obviously my own fault because I'm *effectively*
modifying the scripts that run gzip and tar.
The gzip manual suggests writing a wrapper script and putting it in
PATH. I'm not sure how it's an improvement:
- Options are being injected to the gzip command line just like
they are with the GZIP environment variable.
- A few special scripts might know about the GZIP environment
variable and be able to unset it. They are less likely to
know that they should alter PATH to avoid extra gzip options.
I don't see security benefits in removing GZIP, but I wonder if I'm
missing something. As far as I understand, if an attacker can modify
arbitrary env vars, the situation is already bad. Some apps store
untrusted content in env vars but in those cases the names of the env
vars aren't under attacker's control. (In contrast, attacker controlled
filenames can become an attack vector if one extracts an untrusted
archive for examination, thus fixing CVE-2022-1271 in zgrep and xzgrep
mattered.)
zgrep, zdiff, and zcmp read the env vars GREP, DIFF, and CMP. These
allow injecting arbitrary commands (not just command line options).
zgrep's man page documents GREP. It's not marked as deprecated. It's
not very common to run zgrep or zdiff from other scripts, so *if* these
environment variables can cause problems, they won't occur as often as
they could with GZIP. To be clear, I think it's fine that these scripts
read those environment variables.
Several compression tools read command line options from environment
variables. At least in xz the feature was inspired by gzip.
- pigz: GZIP, PIGZ
- bzip2: BZIP2, BZIP
- lzop: LZOP
- xz: XZ_DEFAULTS, XZ_OPT
- zip: ZIPOPT
zstd and lz4 read environment variables but don't parse them as command
line options.
While I have found GZIP convenient now and then, removing the feature
won't matter much to me personally. However, the removal makes gzip one
of the few compression tools that don't support setting even the
compression level via an environment variable.
[1] https://lists.gnu.org/archive/html/bug-grep/2014-05/msg00107.html
[2] https://lists.gnu.org/archive/html/bug-gzip/2015-03/msg00001.html
[3] https://lists.gnu.org/archive/html/bug-gzip/2017-02/msg00019.html
--
Lasse Collin
