Page MenuHome GnuPG
Create Task
Maniphest T3105

libdns does not work on Fedora builds
Closed, ResolvedPublic
Actions

Description

The bundled-in libdns for some reason does not work on Fedora builds. That is any connection to keyservers fail with
error creating socket: Address family not supported by protocol

Here is the dirmngr debug output:

dirmngr --server --keyserver hkp://pgp.mit.edu --homedir /root/.gnupg --debug-all

dirmngr[16996]: reading options from '/root/.gnupg/dirmngr.conf'
dirmngr[16996]: enabled debug flags: x509 crypto memory cache memstat hashing ipc dns network lookup extprog
dirmngr[16996]: error opening '/root/.gnupg/dirmngr_ldapservers.conf': No such file or directory
dirmngr[16996.0]: permanently loaded certificates: 159
dirmngr[16996.0]: runtime cached certificates: 0
dirmngr[16996.0]: trusted certificates: 159 (158,0,0,1)
dirmngr[16996.0]: DBG: chan_4 -> # Home: /root/.gnupg

Home: /root/.gnupg

dirmngr[16996.0]: DBG: chan_4 -> # Config: /root/.gnupg/dirmngr.conf

Config: /root/.gnupg/dirmngr.conf

dirmngr[16996.0]: DBG: chan_4 -> OK Dirmngr 2.1.20 at your service
OK Dirmngr 2.1.20 at your service
KS_GET -- 0x6C6ACD6417B3ACB1
dirmngr[16996.0]: DBG: chan_4 <- KS_GET -- 0x6C6ACD6417B3ACB1
dirmngr[16996.0]: DBG: dns: libdns initialized
dirmngr[16996.0]: DBG: dns: getsrv(_pgpkey-http._tcp.keys.gnupg.net) -> 0 records
dirmngr[16996.0]: DBG: dns: resolve_dns_name(keys.gnupg.net): Success
dirmngr[16996.0]: number of system provided CAs: 172
dirmngr[16996.0]: DBG: http.c:connect_server: trying name='keys.gnupg.net' port=11371
dirmngr[16996.0]: DBG: dns: resolve_dns_name(keys.gnupg.net): Success
dirmngr[16996.0]: error creating socket: Address family not supported by protocol
dirmngr[16996.0]: error connecting to 'http://keys.gnupg.net:11371': Address family not supported by protocol
dirmngr[16996.0]: DBG: dns: getsrv(_pgpkey-http._tcp.pgp.mit.edu) -> 0 records
dirmngr[16996.0]: DBG: dns: resolve_dns_name(pgp.mit.edu): Success
dirmngr[16996.0]: DBG: http.c:connect_server: trying name='pgp.mit.edu' port=11371
dirmngr[16996.0]: DBG: dns: resolve_dns_name(pgp.mit.edu): Success
dirmngr[16996.0]: error creating socket: Address family not supported by protocol
dirmngr[16996.0]: error connecting to 'http://pgp.mit.edu:11371': Address family not supported by protocol
dirmngr[16996.0]: command 'KS_GET' failed: Address family not supported by protocol
dirmngr[16996.0]: DBG: chan_4 -> ERR 167804933 Address family not supported by protocol <Dirmngr>
ERR 167804933 Address family not supported by protocol <Dirmngr>

It seems the name resolution does not work at all and the error message is confusing.

With the standard resolver all works well:

dirmngr --server --homedir /root/.gnupg --debug-all --standard-resolver

dirmngr[17163]: reading options from '/root/.gnupg/dirmngr.conf'
dirmngr[17163]: enabled debug flags: x509 crypto memory cache memstat hashing ipc dns network lookup extprog
dirmngr[17163]: error opening '/root/.gnupg/dirmngr_ldapservers.conf': No such file or directory
dirmngr[17163.0]: permanently loaded certificates: 159
dirmngr[17163.0]: runtime cached certificates: 0
dirmngr[17163.0]: trusted certificates: 159 (158,0,0,1)
dirmngr[17163.0]: DBG: chan_4 -> # Home: /root/.gnupg

Home: /root/.gnupg

dirmngr[17163.0]: DBG: chan_4 -> # Config: /root/.gnupg/dirmngr.conf

Config: /root/.gnupg/dirmngr.conf

dirmngr[17163.0]: DBG: chan_4 -> OK Dirmngr 2.1.20 at your service
OK Dirmngr 2.1.20 at your service
KS_GET -- 0x6C6ACD6417B3ACB1
dirmngr[17163.0]: DBG: chan_4 <- KS_GET -- 0x6C6ACD6417B3ACB1
dirmngr[17163.0]: DBG: dns: getsrv(_pgpkey-http._tcp.keys.gnupg.net) -> 0 records
dirmngr[17163.0]: DBG: dns: resolve_dns_name(keys.gnupg.net): Success
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '216.66.15.2'
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '198.128.3.63'
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '94.142.242.225'
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '46.4.212.178'
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '37.191.236.118'
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '37.59.213.225'
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '66.114.139.158'
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '85.93.216.115'
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '2.70.146.91'
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '185.95.216.79'
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '[2606:1c00:2802::b]'
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '[2001:bc8:4700:2300::10:f15]'
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '[2001:470:1:116::6]'
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '[2001:41d0:1:ac90::1]'
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '[2604:5800:0:70:223:8bff:febd:83b9]'
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '[2610:81:3001:53::231]'
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '[2a01:4f8:190:816b:1::3]'
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '[2a01:4f8:160:2409::1]'
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '[2a01:4a0:59:1000:223:9eff:fe00:100f]'
dirmngr[17163.0]: DBG: dns: resolve_dns_addr(): Success
dirmngr[17163.0]: resolve_dns_addr for 'keys.gnupg.net': '[2a02:168:4a01::37]'
dirmngr[17163.0]: number of system provided CAs: 172
dirmngr[17163.0]: DBG: http.c:connect_server: trying name='2a02:168:4a01::37' port=11371
dirmngr[17163.0]: DBG: dns: resolve_dns_name(2a02:168:4a01::37): Success
dirmngr[17163.0]: DBG: http.c:1777:socket_new: object 0x00007fab395662f0 for fd 7 created
dirmngr[17163.0]: DBG: http.c:request:
dirmngr[17163.0]: DBG: >> GET /pks/lookup?op=get&options=mr&search=0x6C6ACD6417B3ACB1 HTTP/1.0\r\n
dirmngr[17163.0]: DBG: >> Host: pool.sks-keyservers.net:11371\r\n
dirmngr[17163.0]: DBG: http.c:request-header:
dirmngr[17163.0]: DBG: >> \r\n
dirmngr[17163.0]: DBG: chan_4 -> S SOURCE http://[2a02:168:4a01::37]:11371
...

I can try to investigate further if you can point me where to look at.

Revisions and Commits

rG GnuPG
rG247932f367f8 dirmngr: Fix aliasing problem in dns.c.

Related Objects

Event Timeline

t8m created this task.Apr 24 2017, 5:45 PM
t8m created this object in space S1 Public.
• gniibe claimed this task.Apr 25 2017, 5:26 AM
• gniibe triaged this task as Normal priority.
• gniibe added a subscriber: • gniibe.

What is your architecture of the machine?
If it is related to the alignment of memory, I put a change: rG892b33bb2c57: dirmngr: Fix alignment of ADDR.
It will be in 2.1.21.

• gniibe added projects: gnupg (gpg20), dirmngr.Apr 25 2017, 9:14 AM
• gniibe edited projects, added gnupg (gpg21); removed gnupg (gpg20).
t8m added a comment.Apr 25 2017, 10:17 AM

The machine is x86_64 qemu-kvm virtual on x86_64 host.

Unfortunately the alignment patches (I've included also the http.c patch) did not help.

t8m added a comment.Apr 25 2017, 10:31 AM

This is what I see in gdb after the host resolution is called:

print *aibuf
$3 = {next = 0x555556200a10, family = 0, socktype = 1, protocol = 0,

addrlen = 0, addr = {{ss_family = 0, 
    __ss_padding = '\000' <repeats 42 times>, "\200\363b-\005", '\000' <repeats 31 times>, "P\f VUU\000\000Т\"VUU", '\000' <repeats 25 times>, 
    __ss_align = 160}}}

Note the zeros for family, ss_family - the following ai items are similar.

• gniibe added a comment.Apr 25 2017, 1:05 PM

I suspect compiler optimization.
If you are with debugger, please check the function dns_ai_setent in dns.c.
When type==DNS_T_A, it sets sin_family = AF_INET. But it does some violent memory access for modern C.
Then, the value is accessed through saddr->sa_family.
I wonder if (*ent)->ai_family is correctly set here.

t8m added a comment.Apr 25 2017, 1:37 PM

You're right this function is the culprit. The

gnupg-libdns-aliasing.patch2 KBDownload
patch corrects it and fully fixes it for me.

• gniibe added a commit: rG247932f367f8: dirmngr: Fix aliasing problem in dns.c..Apr 25 2017, 2:04 PM
• gniibe added a project: In Progress.Apr 25 2017, 2:06 PM

Thanks for your confirmation. I pushed the commit.

• gniibe closed this task as Resolved.May 16 2017, 1:24 AM

Fixed in 2.1.21.