Page MenuHome GnuPG
Create Task
Maniphest T1693

Spurious "Enter new filename" prompt
Closed, InvalidPublic
Actions

Description

This occurs on Linux Mint 17 with GnuPG 1.4.16.

I downloaded these files:

    coreutils-8.23.tar.xz
    coreutils-8.23.tar.xz.sig

from

    ftp://ftp.gnu.org/gnu/coreutils/

Intending to check the signature, I ran

    gpg coreutils-8.23.tar.xz

rather than

    gpg coreutils-8.23.tar.xz.sig

(that part was user error on my part). I received the following prompt:

    gpg: coreutils-8.23.tar.xz: unknown suffix
    Enter new filename [...]:

where the "..." denotes a long string of non-printable characters.

I see two problems here (possibly this should be split into two
bug reports).

  1. GnuPG incorrectly detected what it thought was a file name in the coreutils-8.23.tar.xz file. It may not be possible to correct this completely, since any random file may contain what looks like GnuPG-specific metadata, but it would be nice if it were better at determining whether that metadata is valid or not.
  1. The suggested file name it printed included non-printing characters. *Some* of the non-printable characters were translated to hexadecimal, but others were passed through unmodified. The problem is in the make_printable_string() function in util/miscutil.c -- it assumes that bytes in the range 0x20..0x7f and 0xa1..0xff are printable, and others are not. This is valid for Latin-1, but not for UTF-8 (and I happen to be using the "en_US.UTF-8" locale).

I see that the newest GnuPG sources cloned from the Git repo
have changed the make_printable_string() function so it calls
sanitize_buffer(). I haven't tried this version, but a quick look
at the source indicates that it probably still has problems; it seems
to assume that all bytes in the ranges 0.20..0x7e and 0x80..0xff are
printable. The logic probably needs to be sensitive to the locale.

I can imagine that a carefully crafted input file that causes gpg to
print special characters that are meaningful to a terminal emulator
might even create a security problem, but I haven't spent any time
exploring that possibility.

Feel free to contact me if you need more information, but you should
be able to reproduce the problem on your end.

Details

Version
1.4.16

Event Timeline

kst added projects: gnupg, Bug Report.Aug 18 2014, 12:05 AM
kst set Version to 1.4.16.
kst added a subscriber: kst.
kst added a comment.Aug 18 2014, 5:06 PM

Some more information: Short initial subsets of the file
coreutils-8.23.tar.xz trigger the same or similar problems. For
very short subsets of the file, gpg produces no output (it shold
print an error message). The spurious "Enter new filename" prompt
appears somewhere between 48 and 64 bytes.

$ head -32c coreutils-8.23.tar.xz > 32
$ hexdump 32
0000000 37fd 587a 005a 0400 d6e6 46b4 0002 0121
0000010 001a 0000 90cc e933 6ce3 ef96 5dff 3100
0000020
$ gpg 32
$ head -48c coreutils-8.23.tar.xz > 48
$ hexdump 48
0000000 37fd 587a 005a 0400 d6e6 46b4 0002 0121
0000010 001a 0000 90cc e933 6ce3 ef96 5dff 3100
0000020 ca9b e8aa 0f7a 28a3 4208 1a16 97ba 7216
0000030
$ gpg 48
$ head -64c coreutils-8.23.tar.xz > 64
$ hexdump 64
0000000 37fd 587a 005a 0400 d6e6 46b4 0002 0121
0000010 001a 0000 90cc e933 6ce3 ef96 5dff 3100
0000020 ca9b e8aa 0f7a 28a3 4208 1a16 97ba 7216
0000030 f620 af37 083f 507d cb31 ed1d 0575 39a7
0000040
$ gpg 64
gpg: 64: unknown suffix
Enter new filename [...]:
gpg: Interrupt caught ... exiting

$

• werner added a subscriber: • werner.Aug 18 2014, 9:18 PM

gpg ask you to enter the correct filename. If you don't want that interactive
mode, use --batch.

• werner closed this task as Invalid.Aug 18 2014, 9:18 PM
• werner removed a project: Bug Report.
kst added a comment.Aug 18 2014, 9:44 PM

I disagree with this resolution.

Yes, it asks me to enter the "correct" file name, but:

  • There is no correct file name, since the input file does not contain valid data (I incorrectly gave gpg a bad file name; gpg failed to diagnose the error).
  • The default file name it suggested is garbage. If I type <enter>, it actually creates an empty file with that name.
  • The make_printable_string() function behaves incorrectly, producing a string that contains non-printable characters. (I'll submit a separate bug report for this if you like.)
  • The behavior differs between a 64-byte prefix of coreutils-8.23.tar.xz and, for example, a file containing just 64 null bytes. In the latter case, it correctly prints an error message. I suggest that it should diagnose the incorrect input in both cases.
• werner added a comment.Aug 29 2014, 11:55 AM

If you use gpg without a command option, gpg tries to figure out what
to do. Now if that file looks like an OpenPGP packet, gpg assumes it
is one and tries to decrypt and verify it.

If you want to verify a signature you need to run gpg with the proper
command, i.e.

  gpg --verify FILENAME

Thus this is clearly a usage error.

Right, some Unicode characters may mess up the output, this is a well
known problem and iirc there is another bug report on this.

Please continue a discussion at the gnupg-users mailing list.

• werner added a project: Not A Bug.May 11 2015, 8:44 PM