Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop

[Phil Pennock]

On 2013-03-02 at 11:27 -0500, David Shaw wrote:
> I think this is sufficiently obscure (an old version of GPG2 that still has the shutdown() code, built with curl-shim, talking to a keyserver that is behind a nginx proxy, which has to have a particular configuration) that it is not worth putting in a special case for.  Change any of the above requirements and it no longer happens.  Especially since GPG2 will now come without the shutdown() code anyway, I don't see any benefit in special-casing this.

The point I've failed to be clear about is that the behaviour of GnuPG
here is the same whenever a transfer is interrupted.  The only thing
special right now is we have a way of reproducibly forcing a transfer
interruption.  The changes will mean that we'll no longer be able to
reproducibly force a transfer interruption.  The behaviour of GnuPG when
it encounters an interrupted transfer will remain the same.

> Note it's also not a case of just signatures missing.  It's part of the *key* that's missing.  If things were cut off in the midst of the signature block, then that implies you're missing the subkeys as well.  Worse, say things were cut off so that you got a subkey, its binding signature, but then the revocation for that subkey was cut off.

Yes.  That's why I think it's bad and worth having better diagnostics.

> As I see it, the real problem here is that there are only two cases in the keyserver code: got a key, and didn't get a key.  "Didn't get a key" is reported to the user as "key not found" due to the old pks server which returned HTTP 200 even for key not found, so there was no reliable way to tell the difference between failure and not-found.  I vaguely recall that someone was enhancing sks so that it returned a proper 404 for key-not-found.  If that has happened, then I can can add code to GPG to have the proper three states: got a key, failed to get a complete key (where you may be left with part of a key), and key not found.  That should resolve the problem with informing the user.
> 
> A quick check of a few sks servers show that keys2.kfwebs.net does properly return a 404 for an unknown key.  pgp.mit.edu returns a 500, but this is also running an older version of sks, possibly before the 404 was added.

You're welcome.  :)

I added the improved HTTP error code logic, basically because I saw
incorrect codes and thought it needed fixing.  I was not aware that this
had been causing operational issues and work-arounds.

Are there any other behaviours of SKS that are currently causing GnuPG
issues?  We can try to get those fixed.

For backwards compatibility, surely the three states can be told apart
by:
 missing: Did not get a "-----BEGIN PGP PUBLIC KEY BLOCK-----" line
 incomplete: Got that line, but did not get a
             "-----END PGP PUBLIC KEY BLOCK-----" line
 found: Got both lines

-Phil