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.

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

$