Thanks for looking at this. However, please do not file separate bug reports
for similar problems. This is just too much overhead. Frankly, I 'd would
appreciate that such audit results are send to the mailing list.

The suggested fix is not suitable because this function or its callers returns
an error code and should just do this. An assert is only to be used to make
sure that nothing unexpected happens. You have shown that this may indeed
happen (by using wrong call args or a malloc failure) and thus this needs more
work. Given that such NULL dereference are not a critical security problems,
this won't be fixed for old Libgcrypt versions as 1.5. Instead I will apply a
fix to master (1.7) and backport it to stable (1.6).

D215: 464_elgamal.patch

D214: 463_dsa.patch

D213: 462_sexp.patch

Updated by 1697.

Fixed with commit 45e3b81. Will go in 1.4.19, release dates not yet known.

D212: 461_md.patch

You shell has no session management, right?

Why do you think this is a memory fault? gpg is waiting for gpg-agent to get
ready. gpg-agent is started on the fly. After a minute or so it should
actually give up and return an error if gpg-agent could not be started.

The passphrase is taken directly from the tty but the input tdata from stdin.
These are different input sources. The passphrase prompt pops up as soon as gpg
needs it.

You won't see the output on the tty becuase the sender used the
--for-your-eyes-only feature. Here is a trick to show it anyway:

  gpg --output -

[Please send firther usage questions to the mailing list and not to the bug
tracker.]

What I am requested to do to see the output on the tty?
I do not understand that I have to close the input since I've already entered
the passphrase...

You need to close the input if you enter the inpout on the tty. On Unix with
Ctrl-D on Windows with Ctrl-Z. You actually did that:

  If I press Ctrl + D it ends with the following message:
  gpg: NOTE: sender requested "for-your-eyes-only"
  gpg: data not saved; use option "--output" to save it

For-your-eyes-only is a PGP feature; if you want to save the output, weel, use
--output FILENAME.

Thanks Werner. I had already done a search among the issues using the world "charset", but the 1373 issue was
not displayed.

However the bug occurs more problematically with passphrases: a secret key passphrase with non ASCII characters
set using GPG 1.4.18 for a given key is considered not valid using GPG v 2.0.26 to deal with the same key and
vice versa.
I think this problem may cause a lot of trouble to users.

The bug also occurs using filenames in which there are characters outside the ASCII block. This occurs also
setting LC_MESSAGES=C or LC_MESSAGES=en_US.UTF-8 (i.e. gpg -vvvv --verify C:\Users\Andrea\Downloads\gpg4win-
2.2.2-beta37_è_.exe.sig -> "gpg: assuming signed data in `C:\\Users\\Andrea\\Downloads\\gpg4win-2.2.2-
beta37_Þ_.exe'" in which are also wrongly displayed double backslashes instead of single) and also with gpg
1.4.18 (but without the double backslashes). Luckily this does not prevent the signature verification. It's
similar to T1409.

Some additional information:

the CHCP command executed at the Windows command prompt reports: "Tabella codici attiva: 850" (active codepage
850);

using the -vvvv option with the --verify command, gpg 2.0.26 and 1.4.18 report: "gpg: using character set
`CP850'".

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.

Reply by email remarked that the vendor suggested to install gpg and use that to
create keys. Thus it seems to be a problem of MoveIT. Reporter asked to close
the bug.

This is known. See the other bug report.

Duplicate of T1373

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

I can confirm that this is fixed with libassuan 2.1.2

your debug output points to the same issue that was fixed recently in gpgol
1.2.1 relating to address lookup in Outlook (part of gpg4win-2.2.2-beta)

Please try this version.

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

$

This is part of the definition of cleartext signatures.

http://tools.ietf.org/html/rfc4880#section-7.1

   Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at
   the end of any line is removed when the cleartext signature is
   generated.

I believe the intend is to avoid signature breakeges when one line ending format
is converted.

Commit b6da2da9 should fix this. At least it fixes a similar bug on Solaris.

GnuPG 2.0.26 (part of Gpg4win 2.2.2-beta37, but the --version command
incorrectly reports Gpg4win 2.2.2-beta33) on MS Windows 7 64 bit SP1 seems to
have the usual annoying bug related to a charset / codepage translation problem
when localized in a language other than english (italian, in my case).

For instance, the character "è" 'LATIN SMALL LETTER E WITH GRAVE' [(U+00E8) |
UTF-8 0xC3 0xA8 (c3a8) | CP850 8a] is wrongly displayed as the character "Þ"
'LATIN CAPITAL LETTER THORN' [(U+00DE) | UTF-8 0xC3 0x9E (c39e) | CP850 e8]

GnuPG 1.4.18 (binary from gnupg.org) does not have the above problem.

My system:
Windows 7 64 bit SP1
Localization: Italy - italian
Command prompt codepage: 850