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.

The GNU project does not list proprietary software as GPG-Shell

Done in the SVN trunk and to be released with GnuPG 2.0.5.
The option to set the creation date is opnly available through
the unattended key generation; see DETAILS (Creation-Date).
All timestamps used during key generation are now the same. Withy card keys the
current scdaemon needs to be used to achive this for cards.

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

Well, I understand.

I put the status to deferred, as the final decision to keep or remove
gpgme_data_seek will be done when the other deprecated interfaces will be removed.

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

Why are you using gpg2? Me seems that for your application gpg 1.4 is better
suited.

It is hard to tell what exactly failed. This needs some printf debugging.
Start at g10/keyserser.c:keyserver_spawn.

Oh, and here's my current memory usage in case it's useful:

jh@gir:~$ free -m

total       used       free     shared    buffers     cached

Mem: 160 97 62 0 1 33
-/+ buffers/cache: 61 98
Swap: 63 39 24

jh@gir:~$ gpg --refresh --debug 1024
gpg: reading options from `/home/jh/.gnupg/gpg.conf'
gpg: keyserver communications error: general error
<snipped warnings about specific keys>
gpg: refreshing 1099 keys from hkp://subkeys.pgp.net
gpg: keyserver communications error: general error
gpg: keyserver refresh failed: general error
secmem usage: 1408/1408 bytes in 2/2 blocks of pool 1408/32768

Please add the option

--debug 1024

and run again.

Available in 1.4.7

I have sympathy with you, and if gpgme_data_seek were the only user of off_t in
the GPGME API, there would be some force behind your suggestion. However, it
isn't, and I don't think that keeping around multiple interfaces for essentially
the same function is useful in the long run. That said, I have two things that
may help you:

Implemented for gpg2 (SVN). Will also be backported to gpg1 for 1.4.7.

This is indeed useful.

Implemented in Libgcrypt trunk.

I have commited a similar fix to the SVN (-r1214).