Honour http_proxy env variable when fetching gpg keys

[hbog]

http_proxy can be defined as build argument when building the
container behind a proxy.
Since version 2.1 of GnuPG, dirmngr takes care of accessing keyservers,
but dirmngr does not honor http_proxy unless it is configured to do so.
Because of this, building the container behind a firewall fails since the base image
was switched from debian/jessie to debian/stretch.

[tianon]

Same question as docker-library/postgres#472 (comment); would like to know a bit more about why you're rebuilding before committing to maintining this bit (which we won't use on our build servers, especially since we use https://github.com/tianon/pgp-happy-eyeballs to MitM our GPG-key fetching anyhow for increased reliability).

[hbog]

I have built customized base images that contain a few location specific settings, such as our locale. Hence location specific image extensions are done only once in a base image, rather then writing an extension for every type of container. This generates localized images using universal, portable build scripts. I submitted a PR because I can image that there might be other reasons for not using the pre-built artifacts.

[ltangvald]

I do run into the same sort of issue when building the image myself, since we use a proxy at work. The solution I use locally is to add --keyserver-options http-proxy=$http_proxy to the gpg lines. This does require changing two lines, but is there some officially recommended way to handle this? Proxies cause a lot of pain because every piece of Linux software seems to have its own way of handling it :)

[hbog]

@ltangvald setting http-proxy as 'keyserver-option' also works, but this option is deprecated in recent versions of gnupg. (https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html).

[tianon]

@ltangvald have you tried an approach like what we're doing with https://github.com/tianon/pgp-happy-eyeballs (#459)? I think that would allow you to apply the http_proxy directly in that one place, leaving the Dockerfile untouched. 👍

[tianon]

Closing given none of our build environments use a proxy in such an explicit way. There are also some notes in https://github.com/docker-library/faq#openpgp--gnupg-keys-and-verification which could be used to accomplish this without too much overhead (hijacking container DNS to point to a proxy-aware reverse proxy for these requests).