I just fixed a couple of card reader problems in GIT master. I assume that
theses fixes will also solve your problem.

There is no version 2.1 of GPA.
Please tell us more details.

Fixed in commit 1ce38d7

I ran a test and it returned 65534.

We need to look into Pth to find a portable way for finding the used values for
--with=fdsetsize and use that as an upper limit.

I think the long loop in "t-exechelp" where it is uses the hard limit of
2147483647 in AIX 6.1 might be addressed so that it uses a reasonable
number (i.e. FD_SETSIZE) as a maximum. I don't know if using NPTH would
address that.

I am not sure whether I want to fix that. The problem is a Pth problem and we
will soon drop the requirement for Pth in favor of our new NPTH. NPTH uses
native threads (e.g. pthreads) but provides an API and semantics simialar to Pth.

I am currently working on the DNS code in master. I changed the default buffer
size to cope with that large keys. For the other branches the option

Ooops. The key is there but it is longer than the limit we use. I will check
whether we can return a proper error code in this case.

One of the problems is that there is no such key in the DNS anymore. Simon has a
preferred keyserver attribute in his key which points to a DNS record. I'll ask
him what happened to this DNS record.

I'll setup a testing enviroment soon again and keep you informed!

Okay, fixed in master commit ea9df94. Goes into 2.1 Thanks.

I don't quite understand your point here. In any case GpgOL is not abale to
send encrypted mail via Exchange.

IDEA warnings pop up ofthe enough, so that a special treatmeant is justified.

Now problem got even worse. My 2.0.18 agent can not unlock my old SSH keys, nor
can it add new SSH keys.

A test program compiled with MinGW under Windows gives the same result - CP866.
I used just 'gcc console.c' and ran a.exe in MinGW Shell.

thanks for your answer, ill give it a try with a newer version.

I copied some text output from console to Notepad.exe (standard Windows program).
Look first line in gpg-consoleoutput-unicode.txt

Rather strange error:

According to libiconv documentation, it recognizes CP866 as legal charset name.
http://www.gnu.org/s/libiconv/

Ok, I wrote a small test program in Visual C:

We use what the system tells us. See jnlib/utf8conv.c:set_native_charset . An
alias for CP866 might be missing. We don't switch the console charset but use
libiconv to translate between charsets.

I wrote a small test program for .Net to see what is console charset:

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: