David: What about this patch?
dkg: We might need a copyright assignment - David will decide.

We are anyway going for GnuPG-2 on Windows. With the gpg-agent framework, there
is no more need for application specific passphrase entries. Thus I close this
bug and wait until it gets a new life in Pinentry ;-).

Smartcard support has greatly been enhacned and several bugs fixed. This
feature would thus be more or less useless.

We might implement something along with planned changes in gpgme. No concrete
schedule, thus I close this request.

We have a lot of changes in the current development version. Please check that
one out or wait until we do a new release.

No, we don't want to do that. If you do not like this use the option:
--allow-freeform-uid

Should eventually be implemented.

Okay. Removed from SVN trunk. For GnuPG 2.0.10 this option is obsolete and
fixed listing mode is used by default. It does not harm to use it, though. We
won't change it for 1.x.

The problem with the TP-robot and probably the alternatives is that it makes it
to easy for the translator. I have made the experience that the translators
just translate what's there without knowing the software they are translating.
And often without access to the source. That might work with standard software
but for software like GnuPG this can lead to a desaster. We have at times
debated over the English wording and thus the tranmslation of many things needs
thinking on how to express this. My hope is that without an automated system
the translators check there translation against the actual use of the strings
and perhaps ask if they don't understand. Some did this in the past and it
helped too clarify misunderstandings.

I sent the user a notice and asked him to check his work against the latest
gnupg version. However, the report is 3 years old and I don't know, if the user
will react. If hre does, I will forward the result to this item.

Applied. Note that gnupg1 uses the same texi source as gnupg2. Thus the update
sshould show up in gpg 1.4 with the next release (unless I forget to sync them).

No, it can't be. The exit status is not sufficient to convey all required
information. IF you want that you need to use gpgv along with a keyring of
trusted keys.

That one seems to be 1.4.1 which is completely outdated.

I noticed that you filed several feature requests. It is better to take such
things to the mailing list gnupg-devel@gnupg.org.

It does with --with-colons --fixed-list-mode:

That is not easy to do because we cache the key signature status for performance
reasons. Thus for a proper output you would need to used --no-sig-cache;
without that the output does not reflect reality. A GUI can more easily check
for a revoked signature key because it will not be used in batch mode. I'll
make a not e in the documentation for --check-sigs.

I can see that:

gpg show's that the key has been revoked without giving a reason. The user
should do his own conclusion. There is no policy enforment on gpg.

If some extra output from libgcrypt-config is helpful for you, just let me know
and it will be added. But please use the mailing list for such a discussion.

We have never used pkg-config. That there has never been a build dependecy on it.

Assuming you're talking about an extra dependency for building gcrypt, it would
be easy to build and install the *.pc without using the autoconf macros that
come with pkg-config. That said, everyone has pkg-config these days--apparently
gcrypt had a build-dependency on it and nobody even noticed (IIRC it was being
build, just not installed)? That's a decent indicator that nobody would mind, IMHO.

I applied the patch. Thanks!

FYI, I sent some information to the gpa-dev list as well, not sure if it
arrived. They were all CC’ed to the debian bug report though.

This has been implmemented with 2.0.8rc1. 2.08 will be release later the week.

-----BEGIN PGP SIGNED MESSAGE-----

I don't understand your the disadvantage point. You can use --pinentry-program
in gpg-agent.conf to use your pinentry wrapper.

I was first thinking about

default-key-x $GPG_DEFAULT_KEY

with GPG_DEFAULT_KEY being an envvar. However your suggestion aslo makes sense.

I need to see how this can be implemented in a compatible way.  Probably a new

option

default-key-list

needs to be used.

Changing the Admin PIN using the keypad as not been enabled on purpose. In case
soemthing goes wrong you may easily brick the card. It will be enabled as soon
as we have more experience with the keypad readers.