Fixed for 2.0 and 2.1. Thanks.

(Understood there are no immediate plans for a release, but if/when we do have
one, the change will be ready)

Change committed to 1.4, 2.0, and master.

Fixed in 1.1.3 - see T1251.

A new release has been made.

commit 9373fd75 fixes this data corruption during encryption and signing.

issue1110 is now used to track the second problems (Outlook crashes).

I found the problem. It is a plain stupid double free bug of an internal fixed
size buffer. Will be fixed soon.

tests/basic.c does now test with unaligned parameters.

See http://bzr.savannah.gnu.org/lh/grub/trunk/grub/revision/368{5,6}

Ok, fixed on 1.4, 2.0, and master.

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: