[Sks-devel] pool.sks-keyservers.net issues

[Doug Barton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Wow, what a thorough analysis, thanks Phil. :)  FWIW, I did see those
Expect: headers you describe in my debug output, and obviously if this
issue only affects certain servers it would explain why I was only
seeing it intermittently.

I should have added before, I'm on Ubuntu 12.10, and gpg2 comes built
with libcurl.

Doug


On 03/01/2013 12:04 AM, Phil Pennock wrote:
| Short version: bad interaction of GnuPG, cURL and Apache.  Can probably
| be worked around in Apache config, can definitely be worked around in
| GnuPG code, should aim to get both done.
|
| On 2013-02-28 at 10:01 -0800, Doug Barton wrote:
|> 2001:470:1f09:5e7::2	worked
|> 2001:470:1f0a:5d7::2	failed
|
|> In any case thanks for clarifying the cause of the error ... it's just
|> hard to debug without putting those options in first obviously, and
|> with those options the output is very noisy.
|
| 417 is not load-related, Kristian's goofed.
|
| 417 _only_ happens when the client sends "Expect: 100-continue", in an
| HTTP/1.1 request, and a reverse proxy (or forward-proxy) knows that the
| backend is HTTP/1.0 only.
|
| GnuPG will use such a header with a _POST_ request, ie when _sending_
| keys; that expectation is a POST optimisation, and it's coming from
| cURL.
|
| In this case, the failing server is keys.wuschelpuschel.org, which is
| running GnuKS behind Apache.  Since SKS/GnuKS only support HTTP/1.0,
| Apache has been "correctly" configured, per standards.  nginx doesn't
| support returning 417, so this is only seen with Apache-fronted
| keyservers.
|
| I see nothing in RFC2616 which explains how 1.1 clients speaking to 1.1
| proxies with 1.0 origin servers should handle this.  Presumably, they
| should retry.
|
| Can someone running SKS/GnuKS behind Apache please use:
|    gpg -v --keyserver-options verbose,debug --keyserver THEIRS
- --send-key WHATEVER
| and confirm that they see this (as I do, reliably and reproducibly) and
| then try:
|
|    <IfModule mod_headers.c>
|    RequestHeader unset Expect early
|    </IfModule>
|
| I suspect that just ripping the header out of the request and pretending
| it's not there will let things "work".
|
|
| GnuPG developers: with GnuPG 2.0.19, in keyserver/gpgkeys_hkp.c main(),
| around line 783, I added an empty "Expect:" header to force cURL to not
| send that header, and it worked.  I could then send a key to
| keys.wuschelpuschel.org.
|
| ----------------------------8< cut here >8------------------------------
|    headers=curl_slist_append(headers,"Pragma: no-cache");
|    if(headers)
|      headers=curl_slist_append(headers,"Cache-Control: no-cache");
| /* Added this next bit: */
|    if(headers)
|      headers=curl_slist_append(headers,"Expect:");
| ----------------------------8< cut here >8------------------------------
|
|
| So: I know GnuPG can work around it, that will take a while to work
| around.  If we can get someone using Apache to confirm that the above
| fix works for them, we can push people to include it.
|
| Kristian: I suggest that a pool check might try an HTTP/1.1 POST with an
| Expect: header and exclude from the main pools any server where this
| fails.
|
| (Similarly, need to figure out what to do about nginx/FreeBSD/KQUEUE for
|   GnuPG curl-shim ... harder to deterministically detect.  For myself, I
|   might suck it up and rebuild without KQUEUE support.)
|
| Regards,
| -Phil
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iQEcBAEBCAAGBQJRMGsCAAoJEFzGhvEaGryEoDkH/jCg+lTVCRM0l1Gb+8LWcxhO
2Y2tZo4lL1ndjC+SA+VEpwvWk1j/nxmOM0/JuWYHOLJmHb2SbkCSCBh+zKmdFhUD
WVam/1Or4yTMr81P5HTnkqXK7dtvO8WykAufYwtzCChDmgSur01D6s/hl2TJvE2/
tc312aUMoWaUQas/wwZxPaDDtuuuku0tDP66V38vWG/M/MPSR+m1SN9+1CgkJ9AA
X4/YAFOacy1KaTVuGn92GDiSo/qAY34bf14U82RV90rPSY0YUPxlREQ6kRnFIlgS
oYAapEOf2VfNSzCiYZ0PHl2MS35G1ca6i7FJJJQUWv9v4d27fTuc4CntwPYZliM=
=7JXm
-----END PGP SIGNATURE-----