Thanks. Available in SVN rev 189.

Admin PIN via pinpad are enabled since 2.0.9.

Works fine for me with gpgme_op_verify, which actually runs the gpgme -o command
as you gave it. Did you rewind the output data object before trying to
read the data?

Marcus: Can you please check whether we can easily add this to gpgme_op_decrypt?

I am sorry, but we won't add such a feature for these reasons:

Fixed in my working copy.

Background info: My e-mail program is currently calling gpg via fork() and
exec() and is thus very GnuPG version dependent. It does not create such
messages, but can display them. Trying to get rid of the version dependency,
I've tried to switch to GPGME and stumbled about a test message I've received
years ago. Unfortunately the header lines do not mention what mail program was
used for sending.

Use
--trust-model always

I was not aware that such OpenPGP messages are actually used. We need to see how
to implement that.

Checking the text from T960 (wk on Oct 13 2008, 10:45 AM / Roundup):
I think the text is a significant improvement.

Okay, I change the man page to read:

Closing.

I like the idea, but I'd implement it slightly differently (nothing major -
there are a few unnecessary #includes, and I'd rather protect pct_expando in
pct_expando rather than rely on the caller to submit sane arguments).

I'm happy to assign copyright for this patch to the FSF, if that's needed.

awaiting backport to 1.4.

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: