Sorry, typo in the URL, (there was one "kolab/" too much, but you could have
gotten to it via the main page. :) )
https://www.intevation.de/roundup/kolab/issue3583 (offline s/mime signing
without CRL for secret key gives unkown system error)

Sorry for the late response, only recently a new pinentry got released.
So we will test this on basis of 0.7.6.

Thanks for the change, I will check it out.
Did you consider removing the option --fix-trustdb
if you do not intend to implement it?
I would consider removal to be good, if the warning
is all what people get in the foreseeable future.
The existance of the options assumes that there is code
to do the fixing behind it.

An admin saw this suggestion in front of a user and got annoyed
that the recommendation

"the trustdb is corrupted; please run \"gpg --fix-trustdb\".\n") );

in tdbio_invalid(void) gnupg-2.0.12 did not work.

I have an strace log for the time before the kill, it is quite boring only
4130804 lines of
2951 select(10, [9], NULL, NULL, {0, 0}) = 1 (in [9], left {0, 0})
2951 read(9, ""..., 8192) = 0
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 select(10, [9], NULL, NULL, {0, 0}) = 1 (in [9], left {0, 0})
2951 read(9, ""..., 8192) = 0
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 select(10, [9], NULL, NULL, {0, 0}) = 1 (in [9], left {0, 0})
2951 read(9, ""..., 8192) = 0
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)

New log with svn rev 313 send to Werner on friday. The user had killed dirmngr.
(I am putting the internal reference in the topic.)

Is it possible to write out a message when we hit such a timeout?
Make that timeout configurable nontheless?

D80: 213_pinentry-qt4-wordwrap.diff

There is a patch for qt4, please apply then assing to me for testing.
It is good to see this solved at two places

Werner, thanks for the quick response.
Yes I know that OPTION is generic, the question is what OPTIONs are supported
for a server and this is not mentioned for dirmngr and there is also no mention
of "audit-events" at all. Maybe audit-events is also generic?

Okay, systematically, sending HELP to dirmngr 1.0.2 gives me the following
list:'# NOP\n# CANCEL\n# OPTION\n# BYE\n# AUTH\n# RESET\n# END\n# HELP\n#
OPTION\n# LDAPSERVER\n# ISVALID\n# CHECKCRL\n# CHECKOCSP\n# LOOKUP\n#
LOADCRL\n# LISTCRLS\n# CACHECERT\n# VALIDATE\n# INPUT\n# OUTPUT\nOK\n'

Hmmm the "LDAPSERVER" command is also not mentioned.

Arg, sorry for T1020 (bernhard on Mar 25 2009, 02:54 PM / Roundup) this was a paste and copy fault on my part.
Here again from gnupg 2.0.11 and gpgme 1.1.8 (as noted before):

Thanks for the hint. Interesting enough the result is the opposite.
With gpgme for OpenPGP the no_secret key is _not_ reported,
but
LANGUAGE=C gpgsm --status-fd 2 --decrypt hi.txt.gpg
[GNUPG:] ENC_TO XYAAAAAA 16 0
[GNUPG:] NO_SECKEY XYAAAAAA
[GNUPG:] BEGIN_DECRYPTION
[GNUPG:] DECRYPTION_FAILED
[GNUPG:] END_DECRYPTION

I am also attaching the root key in question for testing.

What is the reason that the "last resort timeout" cannot be configured
to be faster? (Meaning below 5 minutes?)

What can we do about this then? There should be a configuration option
to make this problem go away, right?

Thanks Werner. BH, please test.

Works here. Quite old.

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

D66: 180_gpgsm-fix-option-deletekeys-rev4847.diff

(Assigning to Werner, because the Problem is still there.)

The problem is still there with
Kontact proko2 2.1.12 and gnupg-agent 2.0.9-0kk2 on Debian Sarge.
And Kontact enterprise35 20080826.852422 Etch.

BH,
if the error message is gone, maybe can you split out the other problem
from this issue.

Ludwigs test with 2.0.9 + patch shows that the error message does
not come anymore.
Werner, can you state when you did the change the dirmngr?
(E.g. what is the last released version that worked correclty here?)

Tested with gnupg2 2.0.9-1 from Debian sid and python-pyme 0.7.0-4.

Related to the certificate duplication is the new
issue876(CMS certificate duplication blocks use of gpgme_get_key() )
so all symptoms are not remedied in gpgme 1.1.6 and gnupg 2.0.8 yet.

Volker Dormeyer reports that the problem is also there with
gpg --version

gpg (GnuPG) 1.4.6    
[..]

Note if you want to check if you message has this problem,
try gpg2 on the command line like

Werner,
thanks for the fix.
Just quickly?
In which component did you fix it? Is there an easy way to get a patch?