As a good GNU citizen I spent some time on it and implemented PBES2 in
minip12.c. This is in master and I don't intend to backport it to 2.0.x.

Frankly, I'd prefer if gnutls would use the gnupg infrastructure instead of
duplicating everything. If they have time to add their new key derivation
feature to minip12.c; I will be glad to apply such a patch.

I appreciate that PKCS#12 is stupid and baroque, but if the goal is
interoperability with other software, it seems like other GNU tools would be a
reasonable target at least :)

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 ;)

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.

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.

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.

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.

That must be a problem of the FreeBSD ports. GnupG comes with a man page. On
my system I can do

man gpg

for th1 1.4 GnuPG and

man gpg2

for the 2.x gpg. Please report to freebsd.

FreeBSD 8.1 release :

man gpg

No manual entry for gpg

Huh? "man gpg" "man gpgsm" "man gpg-agent" ... all work perfectly for me.
For ages.

GPG needs to to run trial decryptions with all available secret keys; there is
no specific order for this. This can be improved by ordering the packets so
that those with known keys are tried first and only then the wildcard keys. The
wildcards could also be more optimized. This is a actually long standing wish
by myself but I didn't found the time to implement it. Instead I implemented
the --skip-hidden-recipients in 2.1.

This is just a warning.

Use the pdf version.
An info file will be installed with gnupg.

Hello Werner,

Hallo Werner!

For the given use case you should ask the former employee to revoke the uid.
And in case you can't contact him, the signers may revoke their signatures
(--edit-key, "revsig").

Werner, please note: this issue is kkc.

It is unofficial and the FAQ is outdated anyway.

OpenPGP!
Marcus means, we need a similar pinentry message which ask for correctness of
fingerprint of the certificate which the user want to certified (like the
pinentry if you enabled allow-mark-trusted option for S/MIME).

OpenPGP or CMS?

EDIT: The NO_SECKEY comes from a second key for which I do not have the private
key. But all I get after pressing cancel is BAD_PASSPHRASE, which could happen
as well if the user really got it right on the second try.

Hmmm... I am talking about GnuPG 1.4.10 here. I am not getting anything like
this. I am, however, using gpg-agent from gpg2.

Actually there is a queue. However it needs a redesign to check again right
before the passpharse dialog comes up. I think this is a real bug.

What about this:

That's a fair point. However it's just not there in glibc (at least I couldn't
find it). But if that's the only offending part the first two hunks could just
be skipped.

Does not look pretty.
I ask myself why glib does not implement its own printf functions to get rid of
such macros. I recently changed the gnupg code base to use the estream printf
functions which now allows us to use modern printf format specifiers. That is
much nicer than cluttering the code with casts or macros.

Applied. Thanks.

Hi Werner,
the G_* stuff is from GLIB/GTK+ so for a GTK+ object it's what somebody would
expect. If you want to stay close to the rest of the pinentry coding style I'm
or course fine with that.