That is quite possible. pkcs#12 is a stupid and baroque data format worse than
the usual X.509 stuff. There are dozens of variants.

i dont quite understand/agree with the last few comments, but i guess it doesnt
matter that much since the code now uses AC_PATH_TOOL which is all i wanted ;)

Oh, and it's amd64.

I mean the J flag from malloc(3), which is in effect by default on -CURRENT:

J       Each byte of new memory allocated by malloc(), realloc(), or
        reallocf() will be initialized to 0xa5.  All memory returned by
        free(), realloc(), or reallocf() will be initialized to 0x5a.
        This is intended for debugging and will impact performance nega‐
        tively.

Marcus, can you please look at it?

What do you mean by malloc debugging? The libgcrypt configure option
--enable-m-guard or some FreeBSD feature? The libgcrypt option does not always
work. If it is a FreeBSD feature, libpth might be the culprit. What system?
If it is a kernel feature will I be able to test it using 8.0 on ia32?

Fixed with with commit d0a9b8a

Okay, using AC_PATH_TOOL to implement AM_PATH_GPG_ERROR makes sense.
I changed libgpg-error and updated the macro in libgcrypt master.

The idea for a search path for a cross-build environment is not sane. If you
have a cross-build environment then it is easy to set it up correclty. If your
environment is already broken, gcrypt-config could only help by printing an
additional warning, but it will never be bulletproof.

Oh well, we use an old copy of gpg-zip.1 from Debian for 1.4. I replaced it
with a texinfo generated file from master. Commit 75d62be.

Well, not a functional bug. I'll fix it in master.

Thanks. I solved it slighly different by skipping the cache check completely.
Fix is in gnupg 1.5 because dirmngr is now a part of gnupt, proper.

i'm not requesting you install HOST prefixed wrappers. that would actually be
worse since people setting up cross-compile environments already generically
take care of this issue.

Please try a decent version of GPGME before entering an entry into the BTS.

Please ask on the gnupg-users ML or consult with a support company; see
http://gnupg.org/service.html

Please provide a proper test case which is independent of the
distribution. Do not report distribution specific problems to an
upstream package. Thanks.

The compiler folks are breaking all assumptions C hackers used for decades :-(
The benefit is a little performace improvement which might be outweighted by the
bugs introduced due to the code changes required to to use gcc specific stuff or
even memcpy everything forth and back.

Libraries are a part of the application. Hiding all details of a
library is simply not possible. You suggestion does not work either;
because switching the thread system is not possible: Either you are
using thread system A or thread system B; A can't switch to B, because
it does not know about B's internals.

FWIW, I started to work on another random backend which uses /dev/random
directly. It is not yet finished, though.

FIPS requires anyway a specific machine and a specific built binary.

Already fixed, will be in 1.5.0

I don't agree. Your program might install HOST-prefixed tools, our programs
don't thus I can't see that as a but. You need to pass the correct
--with-gpg-error-prefix option. The GnuPG related software does this for 10
years or so.

The manual clearly states:

Using SMTP with GpgOL and Exchange seems to be work:
http://lists.wald.intevation.org/pipermail/gpg4win-users-en/2010-December/000572.html

Thanks for having fixed it for master. It's OK so, because a comment to Issue
1236 shows me a workaround (--allow-freeform-uid) until the next release.

Fixed for master (2.1) with commit 71e7a16.

I did not have a chance to test 2.0.17 or the patch yet, but for the archive:
I just have an instance of gpg-agent, which does not allow ttys matching
"/dev/pts/??", i.e. two digits. On three-digit-ttys it works. Maybe the
behaviour depends on the length of tty when the gpg-agent was started first or
something similar.

While working on a different part of the code, I found a bug in a function also
used by the ssh code. You may want to apply this patch:

Also fixed in the old dirmngr, svn 347

Fixed in commit 62842cc for gnupg master (2.1)

Hello,
I have been checking on the status of this bug report once a week. Unfortunately
no progress was reported.

Hmmm, I'll do a test tomorrow.

FWIW, pth_connect is part of the regular interface.

It is okay for one request to take a long time or possibly even to block.
But it is not okay, if other, simultaniously made requests are blocked to wait
for this slow request. Especially if those parallel requests could be answered
easily and quickly, like ping.

If you ask to download a large CRL and the server is slow it takes time. If you
download a webpage with a lager image and the server is slow it takes time. The
solution is to cancel the request.

To me this, issue makes dirmngr unsuitable as a system service
and it currently allows denail of service attacks on gpgsm based email
applications.

Fwiw, the name of the new thread implementation will be npth.