Except the for doubled listing, is there any other potential drawback?

I really want to try, but I cannot compile 2.1.2 due to T1862.

Duplicate of T1644

Okay, I changed your role so that you can comment on T1644.

It is very unlikely that we are going to fix that in 2.0, thus be prepared to
move to 2.1.

Can you please try with 2.1.2 ?

Sorry, the fix does not remove the bug:

[/home/permail/RHEL5/devel/gpgfamily/bin/gpgsm] [--no-greeting] [--yes]
[--auto-issuer-key-retrieve] [--batch] [--no-tty] [--homedir]
[/home/p/perske/.perMail/gnupghome] [--base64] [--detach] [--local-user]
[&7CF2C58D823C0ED461ED6B1FD13F9E96B6F7C436] [--status-fd] [8] [--output]
[/index/permail/RHEL5/devel/sso/work/pgp.89542620000040ef.out] [--sign]
[/index/permail/RHEL5/devel/sso/work/pgp.89542620000040ef.dat]
(using a self-written pinentry replacement)

gpgsm: note: non-critical certificate policy not allowed
dirmngr[25485.0]: permanently loaded certificates: 0
dirmngr[25485.0]: runtime cached certificates: 0
dirmngr[25485.0]: no CRL available for issuer id
A52EFAEFBC86EF98C5E9AA92B3ECEC4101080F0A
gpgsm: certificate not found: Ambiguous name
dirmngr[25485.0]: assuan_inquire(SENDCERT) failed: IPC call has been cancelled
dirmngr[25485.0]: error fetching certificate by subject: No data
dirmngr[25485.0]: crl_parse_insert failed: Missing certificate
dirmngr[25485.0]: crl_cache_insert via DP failed: Missing certificate
dirmngr[25485.0]: command ISVALID failed: Missing certificate
gpgsm: certificate
#1700BFBB98F74B/1.2.840.113549.1.9.1=#636140756E692D6D75656E737465722E6465,CN=Zertifizierungsstelle
Universitaet Muenster - G02,O=Universitaet Muenster,C=DE
gpgsm: checking the CRL failed: Not found
gpgsm: can't sign using `&7CF2C58D823C0ED461ED6B1FD13F9E96B6F7C436': Not found

Currently used versions:

dirmngr-1.1.1.tar.bz2
dirmngr-1.1.1-pth-fix.patch
gnupg-1.4.17.tar.bz2
gnupg-2.0.24.tar.bz2
libassuan-2.1.1.tar.bz2
libgcrypt-1.6.1.tar.bz2
libgpg-error-1.13.tar.bz2
libksba-1.3.0.tar.bz2
pinentry-0.8.3.tar.bz2
pth-2.0.7.tar.gz
(my own) pinentry.c

The assuan_inquire(SENDCERT) above requests a certificate by distinguished name,
not by authority key identifier (see T1644 (perske on May 23 2014, 07:05 PM / Roundup)), thus it does not matter that the
certificates re-issued by the DFN-PKI kept their authority key identifiers; the
problem is triggered by (correctly) keeping the Distinguished Name.

(I did not yet analyze your bugfix.)

Fixed in 2.0.23.

Too much changed in the last 3 years, it does not make sense to follow up on
this bug. Feel free to re-open if you can replicate it with current releases.

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.