2.0.5 is too old. Feel free to reopne if thatt problems is still in 2.0.19 or
later.

I agree that adding a better message is helpful.
What about something along the lines that says:

"cannot sign with or decrypt with key XYZ"

and explaining:

  "even when trying to decrypt with a different key, 
  the default signature key gets checked."

Certainly it would be much better if decryption would just try to
decrypt with the available keys, no matter of what status the
certificates to this or other keys are. I am worrying most about the
applications that are using Gnupg in this way, they probably will
not be able to either explain this properlto user or offer good
assistance. The reason you give why this is done is only an implementation
artifact and not logical for a user that has learned or tries to learn
about public key cryptography.

I agree that the error message is misleading. What happens is that
gpgsm prepares the keys the decrypt operation and does not distinguish
between decrypt and sign: In all cases where the private keys are
required, gpgsm will check that the configured signing key is usable.

We could remedy this by making this check depend on the intended
usage. However, this is a bit complicated and in any case, your
configuration is wrong. I'd rather say, learn early that your config
files needs an update than to fix the problem.

What about adding a hint "check your config files" to the "can't sign
suing XXX" diagnostics? I don't like to change strings right now. A
diagnostic "please check your configuration (option '%s')" would
generally be useful.

My guess: Whoever wants to use said certificates would add them bey themselves …
I don’t see the need for adding them by default.

Because I was able to verify the origin of these root certifciates. But see the
comments. The German signature law imposes some strict requirements on
qualified signatures; despite that GnuPG is not certified, it is prepared for
such a certification.

To me this is still a bug (why only some more or less random German CAs only?).

Sorry, we can't do anything about it after a release. Delete the com-certs file
and the keys and you are done. Anyway, expired certificates are required in
X.509 - for example in the chain validation model.

It seems this is not important enough to implement an extra filter for this case.

Could be a gpg-agent problem.
If I don't start a gpg-agent and run the export, it will work.
If I start a gpg-agent before, it won't work and pinentry will run amok.

Marcus, not yet so far. I would appreciate a test on your end, as I might not
get to the issue for a while. There should be enough information to reproduce
the issue.

Hi Bernhard,

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 delay. I can not access the kolab tracker (404), has the link
changed? Errors for individual keys in a keylisting are not available in
detail, but only the invalid flag is set. When using an invalid key, a more
detailed reason may be available. There is currently no way to get more
detailed reasons about why a key in a key listing is invalid.

Marcus, can you please have a look at this?

Fixed in GnuPG 2.0.11.

Crash due to a NULL pointer dereference.
Not a Windows specific bug.
Fixed in svn 4935.

Duplicate of T949

It seems that I can close this bug.

When doing an external key listing, gpgsm asks the configured LDAP servers to
return matching certificates. All returned certificates are shown. Given that
there is no common rule on how to search LDAP servers for certain certificate
attributes, Dirmngr uses a very general filter to do the search. This yields
more certifciates than the internal search implemented in GnuPG.

Fixed in my working copy.

Changed in GnuPG trunk 4849.

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:

The issue of the search returning the CAs as well as the certificates actually
searched for is now the separate Issue949.

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

Hi Werner,

A CRL DP is not required, although today most CAs provide one. For that reason,
dirmngr has a list of ldap servers to use as a fallback. For HTTP this is not
possible because there is no standard on the format for CRL http-URLs

Thanks for the information.

Right, there is a little bug. However, it needs some analysis before we can fix
it. The chain validation code is not easy to change.

Since the error message is gone and searching in external keys works, this is no
longer urgent.

The error message is gone. However, the search result sometimes includes
additional certificates, not just the ones the user searched for. These are
then also imported, at least when using kleopatra.

I received your mail today but I probably can't reply to
it before

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

D56: 167_gpgsm-ext-keylist.diff

Not quite correct. The error was probably handled. The actual cause is that we
introduced a new error message in dirmngr. Find attached a patch against the
current gnupg to fix it. Should apply to 2.0.9 as well.

The "not found" from dirmngr stems from the try to get the issuer of the
certificate. You can get the same effect in command line mode when using the
option --with-colons:

Hi Werner,
This issue is important for a critical Kolab issue. So I've raised the priority
a little. I'd like to get at least some feedback, especially what the effort
would be to fix it.