That is no bug but required by the Assuan protocol:

I put in a patch similar to that (g_malloc0 was now unnecessary, and I left in
the GMALLOC_SIZE macro). Thanks for taking the time to reporrt this.

ping

2.0.12 has been released. Patch for 1.4.9 is available.

I recall that this has been applied; please check and close this bug.

Although it is an application error to assume a certain sigprocmask beyond
what's defined by POSIX, we should be nice and try to kill pth too.

Fixed in my working copy. Thanks.

Right, I did no "make dist" to check this. Fix committed.

I get a build failure. g10/gpgv.c probably misses:

Any news on this one?

Fixed in svn rev 5021. Will be fixed for trunk as well. Patch attached.

D88: 224_bug1058-fix.diff

Thanks for the report, I removed the dead entry. allow-pka-lookup was changed
into a verify option quite a while ago. Fixed in rev 5010:

Right, that was missing.

Don't put too much weight into gpg's exit codes ;-)

Fixed in svn rev 5005. (gpg1 and gpg2)

Thanks Moritz. I'm happy to try this out, but I'd need a binary if possible...

That problem will go away anyway because the next GnuPG version splits the DN at
the slashes and thus lines are way shorter.

Arg, sorry for T1020 (bernhard on Mar 25 2009, 02:54 PM / Roundup) this was a paste and copy fault on my part.
Here again from gnupg 2.0.11 and gpgme 1.1.8 (as noted before):

I am also attaching the root key in question for testing.

2.0.11 released. No further response, thus closing.

Fixed in GnuPG 2.0.11.

Crash due to a NULL pointer dereference.
Not a Windows specific bug.
Fixed in svn 4935.

Thanks Werner. BH, please test.

Support for a couple of strings and their German translation has been added in
svn revision 4919.

Fixed in pinentry svn revission 190.

my$ printf "what do ya want for nothing?" | ./hmac256 Jefe
hmac256: fatal error: self-test failed
my$

The second implementaion hmac code is also used by the hmac256 utiliy we install
since some time. Can you please run this and compare the result? (best with the
hmac256 in libgcrypt/src/):

Sometimes weird things happen :_(.

Out of curiosity, I tried to rebuild the 1350 revision that you linked to below,
and it also worked. I'm not sure what happened, but at least I cannot reproduce
this any more.

I've re-run the 'basic' self test several time, and it works every time (except
for the hmac problem).

I'm relatively certain that it is correct. I created by running 'make dist' on
my machine and transferring the entire libgcrypt-*.tar.gz archive to the Solaris
system and building libgpg-error and the libgcrypt archive there. The system
doesn't have libgpg-error or libgcrypt installed before. The only way I see
them being wrong would be if there is a gdb/gcc problem, which isn't completely
unlikely, the tools on that platform are fairly old (gcc 3.4.4).

Are you sure that the backtrace is really from svn1350? The given line numbers
don't match.

Trivial patch. Closing bug,.

I cannot reproduce this problem anymore. Neither with the test case
script, nor during ssh authentication with several card-reinsertions.

Moritz, this should be fixed in the current SVN of 2.0.10. Would you mind to
test it?

Another fix was needed, please use revision 1365.

It doesn't seem to work:

is the latest snapshot. I'd appreciate if you can test it so that I can close
this bug.

Note: It also works for gpgme_op_decrypt_verify, but the error code
GPG_ERR_NO_DATA needs to be ignored in this case. This is because we didn't get
a DECRYPTION_OKAY status message, and this is semantically the same as for a
signed but not decrypted file. We can consider making this case better in a
major upgrade when we change the ABI anyway, but not now.

Applied to trunk. Unfortunately it didn't made it into 1.1.7.