This is the same as T1881

Duplicate of T1881

Forgot to resolve this as superseeded.

With gcrypt compiled with -mstackrealign as analyzed in T2085 this problem
is also fixed.

So I'm marking this as a duplicate of T2085.

Duplicate of T2085

I did not test 2.1 on windows 10 but 2.0 from gpg4win.

Let's consolidate issues though. To simplify things I resolve all reports
regarding this to my report where I will report on debugging / fixing this in
issue2085.

Duplicate of T2057

Duplicate of T2058

Duplicate of T2059

Duplicate of T1878

Weel, your patch defeated the code to properly log all output from the ldap
helper and only then cleanup the wrappers. For the actual fix please see T1978.

Fixed with commit 685b782.

Duplicate of T1978

Werner: Can you provide a bit more context? What exactly is full of bugs?

Thank you, patch applied to master and 1.6 branch.

Duplicate of T2001

The main page at bugs.gnupg.org explains that you should ask for updating your
role. I have done that now.

Duplicate of T1931

1793 has been fixed thus we can close this.

Duplicate of T1936

It's fixed in 2.0.18 (as the T1203 was closed).

kbxutil merely dumps the meta data stored in the file and does no parsing at
all. It will never be possible to achieve the same speed: The meta data is only
used to quickly search for certain attributes but not to list them in an
appropriate way. I will thus close this issue.

Just to be clear (it isn't clear to me that these issues are the same),
issue1938 is related to --list-sigs being extremely slow and spending all its
time in kernel mode, while in T1939 I merely wish that doing a keyring dump
with --list-keys was as fast as using kbxutils.

Duplicate of T1938

Duplicate of T739

Ah damn,..
Duplicate of
T1774

sorry.

Duplicate of T1774

Duplicate of T1467

This is a duplicate of T1718

Duplicate of T1718

T1624 is another issue related to this. GPGex
/ Kleopatra file / folder encrypt does not work with non ASCII characters.

I've commited the patch to gpg4win so it will be part of the 2.2.2 release.

Thanks for summing up the other problems. I've added a reference to this issue
to the "Improve encoding handling" point in the backlog:
http://wiki.gnupg.org/Gpg4win/Wishlist

Thanks Andre for the patch!

I managed to build gpg4win with the patch added and I verified that it seems to
solve the problem reported by me and also in Issues 1373 and 1674!

But I'd like to summarize the problems related to the charset / codepage on MS
Windows of which I am aware, as a reminder:

1. incorrect display of GPG 2 output translated into another language (also

reported in Issue 1373 and Issue 1674): fixed by your patch;

2. passphrases (both for secret keys and symmetrical encryption) with non ASCII

characters set using GPG 1.4.18 are considered not valid using GPG 2.0.26 and
vice versa

3. incorrect display of filenames with non ASCII characters (also in Issue 1409)

4. GPG 2.0.26 and 1.4.18 ignore or weirdly comply with --utf8-strings, --no-

utf8-strings or --charset options for utf-8 encoding of encrypted filenames (see
Issue 1409)

5. charset weirdness searching keyserver for some non-ASCII user IDs under non-

UTF-8 locales (see Issue 1514 - although relates to Linux it seems to occur also
on Windows, both CLI and GPA but not Kleopatra)

Hope this will help to improve the great GnuPG :-)

Good anlysis. Thanks.
Feel free to put it as a patch into gpg4win.
I need to look closer at it because we have have the gettext code also in
libgpg-error. You should also send a DCO for GnuPG.

Pretty picture.

D211: 465_0001-Let-wchar_to_native-convert-to-console-codepage.patch

I've taken a look at this. The problem is that the working conversion code in
jnlib/utf8conv.c is not used on Windows but instead jnlib/w32-gettext.c does
it's own conversion to wchar and then back from wchar to the native codepage
which is simpler and should work.

But the conversion back used the wrong codepage. CP_ACP instead of the codepage
retuned by GetConsoleOutputCP. jnlib/utf8conv.c actually had a comment
explaining why it is neccessary to use GetConsoleOutputCP.

With this changed (see attached patch) I get correct output and can verify /
sign files with non-ascii filenames.

I think gnupg master behaves differently though and I don't have a test setup
for this so the patch is only against STABLE.

Werner any objections into including this patch into GnuPG / Gpg4Win?

Duplicate of T1700

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'".

Closing this as a duplicate of T1516

Should be fixed with the current stable GnuPG and GPGME versions.

For the record. This is now optional in pinentry 0.8.4 you can pass
--enable-pinentry-qt4-clipboard to configure to enable clipboard and paste support.

Duplicate of T1547