When behind a proxy with:
# echo $http_proxy | sed 's/[0-9]/N/g' http://NNN.NNN.NNN.NNN:NNNN/ # cat ~/.gnupg/dirmngr.conf honor-http-proxy
gnupg-2.4.3 can recv-keys fine:
# killall dirmngr 2>/dev/null ; gpg --version | head -n1 ; gpg --keyserver hkps://keys.gentoo.org --recv-keys 39EA32FE8222EEEC gpg (GnuPG) 2.4.3 gpg: key 39EA32FE8222EEEC: "Ulrich Müller <ulm@gentoo.org>" not changed gpg: Total number processed: 1 gpg: unchanged: 1
gnupg 2.4.4 fails:
# killall dirmngr 2>/dev/null ; gpg --version | head -n1 ; gpg --keyserver hkps://keys.gentoo.org --recv-keys 39EA32FE8222EEEC gpg (GnuPG) 2.4.4 gpg: keyserver receive failed: No keyserver available
When I watch the proxy, it is not that 2.4.4 makes no attempt to connect. It's that it doesn't send CONNECT, instead something the proxy server doesn't like:
NNN.NNN.NNN.NNN - - [14/Feb/2024:16:36:19 -0500] "- error:invalid-request HTTP/1.1" 400 3585 397 - "-" "-" NONE_NONE:HIER_NONE
When I sniff this, it's binary goo as soon as the 3WHS completes.
There's mentions of proxy handling changes in the 2.4.4 release notes, but they only talk about Windows systems; this is on Linux.
This might only impact hkps://. I'm having trouble finding an hkp:// server that's still alive, but when I attempt one, I see the client issuing a well-formed GET through the proxy, which of course then times out.