Page MenuHome GnuPG
Create Task
Maniphest T2376

Dirmgnr: LDAPv3 only Server leads to error
Closed, ResolvedPublic
Actions

Description

To reproduce:
Import attached chain.

gpgsm -r 0xFA397E26 -e

This will fail with:
gpgsm: can't encrypt to '0xFA397E26': No CRL known

Debug output:
2016-06-03 09:39:30 dirmngr[2207.0] fetching CRL from
'ldap://ca.intevation.org/cn=Email%20CA%202013,o=Intevation%20GmbH,c=DE?certificateRevocationList'
...
2016-06-03 09:39:31 dirmngr[2207.0] crl_fetch via DP failed: No data

Which is weird in itself as both

ldapsearch -L -x -h ca.intevation.org -b "cn=EMail CA 2013,o=Intevation
GmbH,c=DE" certificateRevocationList

and

ldapsearch -L -x -h ca.intevation.org -b "cn=Root CA 2010,o=Intevation
GmbH,c=DE" certificateRevocationList

return a certificateRevocationList.

But more problematic is that afterwards dirmngr keeps active, does not respond
to kill signals and keeps writing:

2016-06-03 09:49:40 dirmngr[2207.0] waiting for processes to terminate failed:
No child processes
2016-06-03 09:49:40 dirmngr[2207.0] waiting for ldap wrapper 2212 failed: No
child processes
2016-06-03 09:49:40 dirmngr[2207.0] waiting for processes to terminate failed:
No child processes
2016-06-03 09:49:40 dirmngr[2207.0] waiting for ldap wrapper 2211 failed: No
child processes
2016-06-03 09:49:40 dirmngr[2207.0] waiting for processes to terminate failed:
No child processes
2016-06-03 09:49:40 dirmngr[2207.0] waiting for ldap wrapper 2210 failed: No
child processes
2016-06-03 09:49:40 dirmngr[2207.0] ldap worker stati:
2016-06-03 09:49:40 dirmngr[2207.0] c=0x00007fba5c002e40 pid=2212/2212
rdr=0x0000000000000000 ctrl=0x0000000000000000/0 la=18446744073709551615 rdy=0
2016-06-03 09:49:40 dirmngr[2207.0] c=0x00007fba5c002b40 pid=2211/2211
rdr=0x0000000000000000 ctrl=0x0000000000000000/0 la=18446744073709551615 rdy=0
2016-06-03 09:49:40 dirmngr[2207.0] c=0x00007fba5c002a70 pid=2210/2210
rdr=0x0000000000000000 ctrl=0x0000000000000000/0 la=18446744073709551615 rdy=0

Every two seconds in the log.

Details

Version
master

Related Objects

Event Timeline

aheinecke added a subscriber: aheinecke.Jun 3 2016, 9:51 AM

843_aheinecke-2016.pem7 KBDownload

aheinecke set Version to master.Jun 3 2016, 9:51 AM
aheinecke added projects: dirmngr, gnupg (gpg21), Bug Report.
bernhard added a subscriber: bernhard.Jun 13 2016, 4:22 PM

@aheincke an myself observed different behaviour on two ldap server versions
(openldap).
Our new openldap server fails for old dirmngr 1.1.0 Version: 1.1.0+r347-0kk2
and 2.1.11 and master.

Internall we can still access the old ldap server for testing purposes.

Next step see on the wire what the differences could be.

bernhard assigned this task to aheinecke.Jun 13 2016, 4:22 PM
• werner added a project: gnupg.Jun 13 2016, 4:28 PM
• werner removed a project: gnupg (gpg21).
aheinecke added a comment.Jun 14 2016, 7:36 PM

I've analyzed the Problem dirmngr_ldap failed with a Protocol Error which was
hidden because the error output used errno instead of the ldap error.

Attached patch fixes the error output.

The Protocol error was because:
"historical protocol version requested, use LDAPv3 instead"

I'm not sure if dirmngr should try LDAPv3 first and fall back to LDAPv2 but the
Patch I'll attach in the next message adds a fallback to LDAPv3 if the ldap_bind
with the default protocol leads to a protocol error.

The endless activity / failing to notice that the dirmngr_ldap has already died
after the failure I leave for someone else (another issue I guess) as I've
already failed to fix this once :-)

aheinecke added a comment.Jun 14 2016, 7:36 PM

D374: 848_0001-dirmngr-Print-ldap-error-if-bind-fails.patch

aheinecke renamed this task from Dirmgnr: Error on CRL check and endless activity afterwards to Dirmgnr: LDAPv3 only Server leads to error.Jun 14 2016, 7:36 PM
aheinecke reassigned this task from aheinecke to • werner.
aheinecke added a subscriber: • werner.

D373: 849_0002-dirmngr-Try-ldap-protocol-V3-as-fallback.patch

• werner added a comment.Jun 14 2016, 8:54 PM

Thanks. I applied the two patches.

bernhard added a comment.Jun 15 2016, 10:58 AM

Hi,
without having checked it, I think that dirmngr should try ldapv3 first.
The 2.1 versions for sure. For the others, a fallback should be good enough.
(Would it help if I go digging into specs somewhat to back that up?)

aheinecke added a comment.Jun 15 2016, 11:15 AM

Thanks for applying them.

@bernhard
I did not change it to LDAPv3 first to be conservative regarding maximum
compatibility with the least regression risk. And because I don't have a v2 Only
server available against which I could test.

Afaik LDAPv2 vs. v3 is pretty much irrelevant for the calls Dirmngr does.

Imo once OpenLDAP client libraries change behavior to use V3 by default this
should be enough for dirmngr.

aheinecke closed this task as Resolved.Jun 15 2016, 11:15 AM
aheinecke added a project: Unreleased.
• werner removed a project: Unreleased.Jul 14 2016, 7:11 PM