But why is it unreadable? I see Cyrillic letters (gpgconsole.jpg) but this is
not Russian text!

See also T1370

Duplicate of T1370

1.4.5 is pretty old. Please try 1.4.11 and check whether the bug persists.

We always output plain UTF-8 on Windows.

This is on purpose for the GTK version. The authors of the Qt version obviously
think that this is not important.

strange thing is that this works with pinentry-qt

Why do you include openssl and other stuff with -I ?

I don't do that on purpose. I guess it's the build system, that does that.

Screenshot shows the small textfield.

(The height of the passphrase textfield is too small)

tested with gnupg 2.0.18 and pinentry 0.8.0 pinentry-qt4 starts in background
tested with gnupg 2.0.18 and pinentry 0.8.1: pinentry-qt4 starts in foreground
as excepted.

These are the versions in Debian squeeze.
The same happens with gnupg 2.0.17 and pinentry 0.8.0, we have not tested 0.8.1 yet.

We don't have any plans for a new release.

please explain why this is a problem

gnupg 2.0.14 ? You should uodate this before reporting a bug.
pinentry 0.8.1 was released 10 months ago - please test with that one first.

D150: 333_0001-applygnupgdefaults-Avoid-some-unnecessary-stat-calls.patch

Can i get an update on where this patch stands? I'm concerned that people are
actively sniffing around the idea of crafting duplicate short keyids:

Confirmed with different user accounts and window managers (KDE, stumpwm, ...).
The qt3 version works without problems.

Why do you include openssl and other stuff with -I ? Please show the config.log
file.

2.0.18 has been released and fixes this problem

cat(1) is not expecting any input thus you see the broke pipe from the first gpg(1).

Please direct such questions to a mailing list. This is a bug tracker and not a
support forum.

Please direct such questions to a mailing list. This is a bug trcker and not a
support forum.

Please direct such questions to a mailing list. This is a bug trcker and not a
support forum.

I tested this patch, and it does in fact change the behavior as requested.

Running gpg on the file directly:

Can you give me an example of how to call gpgtar? From the incomplete details
output of kleopatra and gpgtar --help
I've put together:
C:\>"\Program Files\GNU\GnuPG\gpgtar.exe" -e --openpgp --skip-crypto --output
test.tar.gpg c:\Users\intevation\Desktop\test_bad

Can you please try to do this from the command line?

Duplicate of T1324

Sorry, after creating this i've noticed that this is a duplicate of issue:
T1324

I think this is fine. I originally wrote the code to send short keyids as pksd
couldn't properly handle long keyids or fingerprints. As pksd is now dead, and
sks properly handles this, I think it is reasonable to send the longest ID
appropriate (send fingerprints if we have them, long keyids if we have them, and
short keyids if we must).

Backported fixes to 1.4. g10/sign.c was not an issue there.

David, what do you think about sending long keyids to the keyservers?

D149: 332_1340.diff

Attached is a proposed patch that should permit passing long keyIDs or full
fingerprints to the keyservers.

Given that the referenced draft was written in 2003, we now have 8 years of
documented expectations that keyservers can do this. The dominant keyserver
implementation today (SKS) can handle this with no trouble.

It may be that these days keyservers can cope with long keyids. However old
keyservers are not able to do that.

this is not a limitation of the keyservers; gpg itself is stripping all but the
short keyid. adding "--keyserver-options debug" to the command shows that in
every case, gpg is requesting the following URL:

Libgcrypt does not support 64 bit Windows yet. In particular do not use it even
if it would build and run fine. MSVC is not a supported build platform anyway.

Also changed for 2.0 - will go into 2.0.18.
Also changed for 1.4.

All implemented for 2.1.