gnupg --fetch-key problems

[Björn Jacke]

Hello Werner,
Hello gnupg  community,

I recently implemented WKD and stumbled over a couple of pitfalls with
that. One problem was that after implementing it and watching the server
logs I noticed that a number of WKD related http requests were refused
with HTTP 403. The User-agent string of those requests was empty/not
existing. Taking a closer look at it reveled, that those requests were
refused because it were HTTP 1.0 requests. That site's load balancer is
rejecting HTTP 1.0 requests usually because those requests are mostly
coming from bad robots these days and legit clients use at lease HTTP
1.1. It turned out that gnupg --fetch-key is actually making those HTTP
1.0 requests without user agent string. A rule that forbids HTTP 1.0
requests is not uncommon these days. In order to make gpg users'
experience better I suggest that gnupg should not use HTTP 1.0 but at
least HTTP 1.1 and also send a user agent header. Actually I think it
would be best if gnupg would use libcurl for that. The web server
protocols a becoming more and more complex and even HTTP 1.1 might not
be good enough for some sites now or in the near future. I guess gnupg
doesn't want to implement a valid HTTP 2.0 or QUIC client in the future.
Using libcurl would be a simple solution. Also the portability and
quality of libcurl is excellent. What do you think?

Best regards
Björn

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200830/a7a4a3bb/attachment.sig>