sending large keys to keyserver push fails with silent hang and "assuan_inquire failed: Too much data for IPC layer"
Closed, ResolvedPublic

Description

Using gnupg 2.1.2 and dirmngr 2.1.2 and libassuan 2.2.0, i try:

   gpg2 --send-keys a4ff2279

this appears to hang indefinitely.

Looking in the dirmngr logs, i see:

2015-02-17 16:02:54 dirmngr[16974.0] DBG: chan_0 <- KS_PUT
2015-02-17 16:02:54 dirmngr[16974.0] DBG: chan_0 -> INQUIRE KEYBLOCK
2015-02-17 16:02:54 dirmngr[16974.0] DBG: chan_0 <- [ 44 20 99 04 25 30 44 04 50
da 2b fb 01 20 00 e6 ...(982 byte(s) skipped) ]
2015-02-17 16:02:54 dirmngr[16974.0] DBG: chan_0 <- [ 44 20 74 a0 10 ab 61 2d 03
2d d6 10 fd 85 ab 01 ...(982 byte(s) skipped) ]
2015-02-17 16:02:54 dirmngr[16974.0] DBG: chan_0 <- [ 44 20 05 02 52 ee cc 42 00
25 30 41 09 10 95 eb ...(982 byte(s) skipped) ]

[...(dozens more lines like this)...]

2015-02-17 16:02:54 dirmngr[16974.0] DBG: chan_0 <- [ 44 20 73 1d 4e 28 71 5e 36
25 30 44 88 66 82 72 ...(982 byte(s) skipped) ]
2015-02-17 16:02:54 dirmngr[16974.0] assuan_inquire failed: Too much data for
IPC layer
2015-02-17 16:02:54 dirmngr[16974.0] command 'KS_PUT' failed: Too much data for
IPC layer
2015-02-17 16:02:54 dirmngr[16974.0] DBG: chan_0 -> ERR 167772433 Too much data
for IPC layer <Dirmngr>
2015-02-17 16:02:54 dirmngr[16974.0] DBG: chan_0 <- [ 44 20 a2 db 1a 21 40 5a 33
67 03 ba 60 1b e2 73 ...(982 byte(s) skipped) ]
2015-02-17 16:02:54 dirmngr[16974.0] DBG: chan_0 -> ERR 167772229 Not
implemented <Dirmngr>
2015-02-17 16:02:54 dirmngr[16974.0] DBG: chan_0 <- [ 44 20 9b 0c 35 d8 70 98 b2
cd d2 3a fc df 44 5a ...(983 byte(s) skipped) ]
2015-02-17 16:02:54 dirmngr[16974.0] DBG: chan_0 -> ERR 167772229 Not
implemented <Dirmngr>
[...(dozens more pairs of lines like this)...]

And gpg2 never returns.

This was originally reported as https://bugs.debian.org/770592, though the
behavior has changed slightly since 2.1.0.

Details

External Link
https://bugs.debian.org/770592
Version
2.1
dkg set Version to 2.2.0.Feb 17 2015, 10:05 PM
dkg added projects: libassuan, Bug Report, Debian.
dkg added a subscriber: dkg.
dkg added a comment.Aug 27 2015, 3:03 PM

with 2.1.7, i see no hang, but i do see failure with certain large certificates,
like 0xB27B944E34884E85:

0 dkg@alice:~$ gpg2 --send 0xB27B944E34884E85
gpg: sending key 0xB27B944E34884E85 to hkps server hkps.pool.sks-keyservers.net
gpg: keyserver send failed: Too much data for IPC layer
gpg: keyserver send failed: Too much data for IPC layer
2 dkg@alice:~$

maybe the boundary is 500KiB? I don't have this problem with my own OpenPGP cert:

0 dkg@alice:~$ gpg2 --export 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 | wc

3126   11384  481051

0 dkg@alice:~$ gpg2 --export 0xB27B944E34884E85 | wc

4310   13779  541937

0 dkg@alice:~$

werner added a subscriber: werner.Aug 27 2015, 3:35 PM

Re-assigning to gnupg. libassuan works correctly, afaics.
When trying to send back Zack's key I had the same problem last week and
increased the limit in dirmngr (84f4c8811fc5bdd78693c4dc289389a8337cc257).
I also mentioned that in a comment to another Debian bug report.

However, their should not be a hang but a proper error diagnostic; it is on my list.

werner added projects: gnupg (gpg21), gnupg.
werner changed Version from 2.2.0 to 2.1.
werner set External Link to https://bugs.debian.org/770592.
werner claimed this task.

Oh well, the hang is indeed a libassuan bug. The assuan_inquire fucntion
stopped reading as soon as a supplied limit was reached and returned to the
caller. The caller (dirmngr), printed an error and sends back an ERR line.
Hwoever, the client kept on sending the remaining lines and thus messed uo the
protocol.

Just fixed it in libassuan (5a52404) by reading up the extra lines before
returing from assuan_inquire.

The limit set by dirmngr is in general useful. Shall we make the limit
configurable at runtime?

dkg added a comment.Aug 31 2015, 12:42 AM

can you explain why the limit is useful? e.g. does it increase efficiency in
some metric? defend against certain classes of attack? something else? sorry
that i don't understand the tradeoff fully.

a runtime configuration would be better than a hard fail, but in either case it
seems like we're asking the user to fiddle with things that they shouldn't have
to think about or understand. is there a way that we can automatically detect
the reason for the failure and make things Just Work for normal users without
opening up the tooling to more problems?

Originally dirmngr was a system wide daemon. Thus a limit made a lot of sense
so that users could not oincrease the memory usage of dirmngr. As a user daemon
this is not too problematic anymore but (in contrast to GNU policy), having
limits is still good to avoid DoS. The packet parser also employs certain
limits, like 2K for a user ID or 16M for an attribute packet.

I assume keyservers also have some limit - or at least they should have one to
help against misuse as cheap storage provider. What about using this limit?

neal added a subscriber: neal.Nov 18 2015, 2:23 PM

Kristian Fiskerstrand told me that the SKS keyservers currently have a 5 MB
limit for parsing incoming header, pre-merge.

As an additional point, the client max body size in nginx defaults to 1 MiB[0].
Currently no checking is done for larger request bodies for inclusion in the
keyserver pools. Apache does not have such a limit by default.

Reference:
[0] http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size

FWIW, with commit 19545e3a from 2015-09-09 I had bumped the limit up to 20MiB.
This should solve all current practical problems.

werner closed this task as Resolved.Nov 30 2015, 4:16 PM