On Thu, Apr 12, 2018 at 9:30 AM, Laszlo Papp <lp...@kde.org> wrote:
> On Wed, Apr 11, 2018 at 8:09 PM, Werner Koch <w...@gnupg.org> wrote:
>> On Tue, 10 Apr 2018 17:19, lp...@kde.org said:
>> > Proxy request sent, awaiting response... 200 OK
>> > Length: 58162 (57K) [application/pgp-keys]
>> Okay that works. Now we need to see why dirmngr has a different idea.
>> When we first talked on IRC, someone else reported that he had no
>> problems with that configuration - but it might not be fully the same.
>> Thus I need to try replicating the problem myself - will take some time,
>> Do you have the envvar http_proxy set? If so you also need to have
>> in your dirmngr.conf.
> That is an interesting idea as one would think that the environment
> variables would be respected by default rather than opting in.
> honor-http-proxy did not work, but --http-proxy host[:port] did. Thank you
> for pointing me to this direction.
> This makes me think that dirmngr does not understand the environment
> variable by default, given that it does not work "by default" and when I
> try to reinforce this with honor-http-proxy. Is this information lost when
> gpg launches dirmngr? If so, should it not be retained?
> Is there a command line option for gpg, like for sudo (-E) and similar
> software applications, to pass on all the environment variables properly if
> this is the issue?
> gpg is also used in my docker build process, so the best would be to
> respect the environment variable by default. Are there any objections to
> that? If so, what exactly?
It looks like if I run dirmngr manually, as follows, with honor-http-proxy,
But when it is run as dirmngr --supervised, gpg does not seem to work until
the http-proxy is specified in the config explicitly.
>> # Please read: Daniel Ellsberg - The Doomsday Machine #
>> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
>> Gnupg-users mailing list
Gnupg-users mailing list