GNU bug report logs - #79231
sends non-printable characters to the terminal in error message

Previous Next

To reply to this bug, email your comments to 79231 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vincent Lefevre <vincent <at> vinc17.net>
To: bug-gzip <at> gnu.org
Subject: sends non-printable characters to the terminal in error message
Date: Wed, 13 Aug 2025 16:49:59 +0200

gzip can send non-printable characters to the terminal in its error
message. This is bad because escape sequences and control characters
can have unpredictable consequences in the terminal.

For instance,

$ touch "$(printf "file\e[H\e[c\n\b")"
$ gunzip file*

makes xterm crash with reverseWrap enabled.

Note: The end user is not necessary the cause of such of file name,
which may come from a downloaded archive or from a bug in some
software.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

Message #8 received at 79231 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: 79231 <at> debbugs.gnu.org
Subject: Re: bug#79231: sends non-printable characters to the terminal in
 error message
Date: Wed, 13 Aug 2025 09:08:26 -0700

On 8/13/25 07:49, Vincent Lefevre wrote:
> $ touch "$(printf "file\e[H\e[c\n\b")"
> $ gunzip file*

Not sure it's gzip's job to sanitize file names that the user gave it. 
Pretty much every much program in the universe will output file names 
as-is, if the user tells it the file name explicitly. Why should gzip be 
an exception?

Message #11 received at 79231 <at> debbugs.gnu.org (full text, mbox):

From: Vincent Lefevre <vincent <at> vinc17.net>
To: 79231 <at> debbugs.gnu.org
Subject: Re: sends non-printable characters to the terminal in error message
Date: Wed, 13 Aug 2025 18:16:43 +0200

On 2025-08-13 16:49:59 +0200, Vincent Lefevre wrote:
> gzip can send non-printable characters to the terminal in its error
> message. This is bad because escape sequences and control characters
> can have unpredictable consequences in the terminal.

I forgot to say: this occurs with
  * gzip 1.13 in Debian 13 (trixie);
  * gzip 1.14 under Termux/Android.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

Message #14 received at 79231 <at> debbugs.gnu.org (full text, mbox):

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 79231 <at> debbugs.gnu.org
Subject: Re: bug#79231: sends non-printable characters to the terminal in
 error message
Date: Wed, 13 Aug 2025 18:39:17 +0200

On 2025-08-13 09:08:26 -0700, Paul Eggert wrote:
> On 8/13/25 07:49, Vincent Lefevre wrote:
> > $ touch "$(printf "file\e[H\e[c\n\b")"
> > $ gunzip file*
> 
> Not sure it's gzip's job to sanitize file names that the user gave it.
> Pretty much every much program in the universe will output file names as-is,

Many programs quote non-printable characters, e.g. those from
GNU Coreutils, but also xz (XZ Utils), diff from GNU diffutils,
and find from GNU findutils (I was the one who reported the
issue for find in 2005[*]).

[*] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311384

> if the user tells it the file name explicitly.

Well, it is given from the shell, not by the user explicitly.
But the shell cannot sanitize the file name; otherwise gzip
would not find the file.

So, this would be up to the file system to prevent the creation
of such file names (I don't know what POSIX says on this point,
but POSIX might also require the opposite).

> Why should gzip be an exception?

Not really an exception (see above).

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

Message #17 received at 79231 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: 79231 <at> debbugs.gnu.org
Subject: Re: bug#79231: sends non-printable characters to the terminal in
 error message
Date: Wed, 13 Aug 2025 11:47:29 -0700

On 8/13/25 09:39, Vincent Lefevre wrote:
> Many programs quote non-printable characters, e.g. those from
> GNU Coreutils

Oh, thanks, I didn't know that. I see this was added to coreutils 
several years ago. In that case, patches to do this for gzip would be 
welcome.

Message #20 received at 79231 <at> debbugs.gnu.org (full text, mbox):

From: Collin Funk <collin.funk1 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Vincent Lefevre <vincent <at> vinc17.net>, 79231 <at> debbugs.gnu.org
Subject: Re: bug#79231: sends non-printable characters to the terminal in
 error message
Date: Sat, 16 Aug 2025 19:01:12 -0700

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> On 8/13/25 09:39, Vincent Lefevre wrote:
>> Many programs quote non-printable characters, e.g. those from
>> GNU Coreutils
>
> Oh, thanks, I didn't know that. I see this was added to coreutils
> several years ago. In that case, patches to do this for gzip would be
> welcome.

Is there any reason that gzip doesn't use quote and error from Gnulib?
e.g. to avoid dependencies on locale stuff?

I'm assuming that it is just because no one has cared enough to add it
to gzip, but that feels like the correct solution to this issue.

There are some places where it is a bit more work than adding
quote/quote_n like this:

    fprintf(stderr,"%s: %s/%s: pathname too long\n",
            program_name, dir, entry);

Ideally we could get rid of the MAX_PATH_LEN limitation on file names
(see GNU Coding Standards [1]) and therefore never have to print this
message. But that is more complex than this issue...

Collin

[1] https://www.gnu.org/prep/standards/standards.html#Semantics

Message #23 received at 79231 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Collin Funk <collin.funk1 <at> gmail.com>
Cc: Vincent Lefevre <vincent <at> vinc17.net>, 79231 <at> debbugs.gnu.org
Subject: Re: bug#79231: sends non-printable characters to the terminal in
 error message
Date: Sun, 17 Aug 2025 08:45:32 -0700

On 8/16/25 19:01, Collin Funk wrote:
> Is there any reason that gzip doesn't use quote and error from Gnulib?
> e.g. to avoid dependencies on locale stuff?

Partly that, and partly because it's a symptom of a larger issue: gzip 
was written in a hurry and is poorly structured and people 
understandably don't want to mess with it. Decades ago I toyed with the 
idea of rewriting it from scratch but gave it up as a job not worth doing.

Message #26 received at 79231 <at> debbugs.gnu.org (full text, mbox):

From: Antonio Diaz Diaz <antonio <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Vincent Lefevre <vincent <at> vinc17.net>, 79231 <at> debbugs.gnu.org,
 Collin Funk <collin.funk1 <at> gmail.com>
Subject: Re: bug#79231: sends non-printable characters to the terminal in
 error message
Date: Mon, 18 Aug 2025 01:31:38 +0200

Paul Eggert wrote:
> On 8/16/25 19:01, Collin Funk wrote:
>> Is there any reason that gzip doesn't use quote and error from Gnulib?
>> e.g. to avoid dependencies on locale stuff?
>
> Partly that, and partly because it's a symptom of a larger issue: gzip
> was written in a hurry and is poorly structured and people
> understandably don't want to mess with it.

Maybe an alternative to searching for all the places where gzip would need 
to be patched could be to reject outright any file name containing any 
control char in the range ( ch <= 31 && ch >= 1 ) || ch == 127

If a file with such a name needs to be decompressed, it can be redirected to 
standard input.

POSIX is encouraging implementations to disallow the creation of file names 
containing any bytes that have the encoded value of a <newline> character. 
See https://pubs.opengroup.org/onlinepubs/9799919799/utilities/compress.html 
section CHANGE HISTORY subsection Issue 8.

Since January 2024, GNU ed is rejecting by default file names containing 
control chars and nobody has complained yet.

Best regards,
Antonio.

Message #29 received at 79231 <at> debbugs.gnu.org (full text, mbox):

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Antonio Diaz Diaz <antonio <at> gnu.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 79231 <at> debbugs.gnu.org,
 Collin Funk <collin.funk1 <at> gmail.com>
Subject: Re: bug#79231: sends non-printable characters to the terminal in
 error message
Date: Mon, 18 Aug 2025 01:53:43 +0200

On 2025-08-18 01:31:38 +0200, Antonio Diaz Diaz wrote:
> Since January 2024, GNU ed is rejecting by default file names containing
> control chars and nobody has complained yet.

Perhaps for creation, but not as input, where GNU ed outputs
non-printable characters to the terminal due to the file name in
the error message. So this does not solve the problem. GNU ed is
as buggy as gzip in this respect. I've just reported the bug.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

Message #32 received at 79231 <at> debbugs.gnu.org (full text, mbox):

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Antonio Diaz Diaz <antonio <at> gnu.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 79231 <at> debbugs.gnu.org,
 Collin Funk <collin.funk1 <at> gmail.com>
Subject: Re: bug#79231: sends non-printable characters to the terminal in
 error message
Date: Mon, 18 Aug 2025 01:57:27 +0200

On 2025-08-18 01:53:43 +0200, Vincent Lefevre wrote:
> On 2025-08-18 01:31:38 +0200, Antonio Diaz Diaz wrote:
> > Since January 2024, GNU ed is rejecting by default file names containing
> > control chars and nobody has complained yet.
> 
> Perhaps for creation, but not as input, where GNU ed outputs
> non-printable characters to the terminal due to the file name in
> the error message. So this does not solve the problem. GNU ed is
> as buggy as gzip in this respect. I've just reported the bug.

In short, the only way to avoid the issue in any program would
be to make the Linux kernel to prevent the creation of such
file names in the first place (well, archive utilities would
also need to filter such characters for their output in case
they can appear in archives).

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.