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.

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

Sorry, I don't understand this. In case you mean that the current locale is
used for the HTML output: Marc already reported that and it is fixed in SVN; I
also sent a patch.

D50: 154_gpgme-getkey-ambigious.diff

Fixed. See the attached patch or use the current SVN.

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.

Issue857 might be related.

Using the patch svn diff -r 4567:4568
my gpgsm can do encryption again.
Still the duplication stays in the keybox.