Re: dirmngr timeout
OK, so I have now solved this issue by running the following commands in docker prior to running gpg: install -dm700 ~/.gnupg; echo honor-http-proxy > ~/.gnupg/dirmngr.conf On Thu, Apr 19, 2018 at 11:04 AM, Laszlo Papp wrote: > Adding the list back. > > On Thu, Apr 19, 2018 at 9:31 AM, Laszlo Papp wrote: > >> >> >> On Wed, Apr 18, 2018 at 9:02 PM, Daniel Kahn Gillmor < >> d...@fifthhorseman.net> wrote: >> >>> Hi Laszlo-- >>> >>> I'm afraid we don't know the details of how your docker instance is set >>> up; which versions of which packages you have installed inside docker >>> vs. outside of docker, what's bind-mounted, what the networking >>> constraints are in place. this makes debugging remotely a bit more >>> difficult. >>> >> >> OK; I am happy to share this. Thank you for following up with your >> difficulties. >> >> It is bleeding edge Archlinux both inside and outside. gpg and dirmngr >> are at the latest release, 2.2.6. >> >> Nothing is bind-mounted. >> >> There are no networking constraints in place as far as I am aware. >> >> Hope this makes debugging remotely a bit easier. >> >> >>> On Fri 2018-04-13 15:29:50 +0100, Laszlo Papp wrote: >>> > gpg: connecting dirmngr at '/home/nic/.gnupg/S.dirmngr' failed: IPC >>> connect call failed >>> > gpg: keyserver receive failed: No dirmngr >>> >>> if a standard user runtime dir is mounted on /run/user/$UID , the >>> dirmngr socket could be mounted there. It sounds like that is probably >>> not mounted, so gpg is falling back to the socket location in the home >>> directory. >>> >> >> That is right. >> >> >>> but if no dirmngr is running listening on the expected socket, then gpg >>> normally tries to launch it itself. >>> >> >> Correct. >> >> >>> for example, i'd expect to see the following: >>> >>> gpg-connect-agent: no running Dirmngr - starting '/usr/bin/dirmngr' >>> gpg-connect-agent: waiting for the dirmngr to come up ... (5s) >>> gpg-connect-agent: waiting for the dirmngr to come up ... (4s) >>> gpg-connect-agent: connection to dirmngr established >>> >> >>> But i don't see that in your logs. What version of GnuPG is installed? >>> >> >> 2.2.6 >> >> >>> how did dirmnger get installed on this docker system? how did gpg >>> itself get installed? >>> >> >> pacman (Archlinux package manager). >> >> >>> >>> what is the output of: >>> >>> gpgconf --list-dirs >>> >>> (within the docker instance, that is) >>> >> >> sysconfdir:/etc/gnupg >> bindir:/usr/bin >> libexecdir:/usr/lib/gnupg >> libdir:/usr/lib/gnupg >> datadir:/usr/share/gnupg >> localedir:/usr/share/locale >> socketdir:/home/nic/.gnupg >> dirmngr-socket:/home/nic/.gnupg/S.dirmngr >> agent-ssh-socket:/home/nic/.gnupg/S.gpg-agent.ssh >> agent-extra-socket:/home/nic/.gnupg/S.gpg-agent.extra >> agent-browser-socket:/home/nic/.gnupg/S.gpg-agent.browser >> agent-socket:/home/nic/.gnupg/S.gpg-agent >> homedir:/home/nic/.gnupg >> >> Yes, I meant "systemctl --user import-environment http_proxy". That was a >> typo; sorry about that. >> >> I am looking forward to resolving this. Hopefully, the information above >> helps. What should I try next? >> >> Best regards, L. >> > > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: dirmngr timeout
Adding the list back. On Thu, Apr 19, 2018 at 9:31 AM, Laszlo Papp wrote: > > > On Wed, Apr 18, 2018 at 9:02 PM, Daniel Kahn Gillmor < > d...@fifthhorseman.net> wrote: > >> Hi Laszlo-- >> >> I'm afraid we don't know the details of how your docker instance is set >> up; which versions of which packages you have installed inside docker >> vs. outside of docker, what's bind-mounted, what the networking >> constraints are in place. this makes debugging remotely a bit more >> difficult. >> > > OK; I am happy to share this. Thank you for following up with your > difficulties. > > It is bleeding edge Archlinux both inside and outside. gpg and dirmngr are > at the latest release, 2.2.6. > > Nothing is bind-mounted. > > There are no networking constraints in place as far as I am aware. > > Hope this makes debugging remotely a bit easier. > > >> On Fri 2018-04-13 15:29:50 +0100, Laszlo Papp wrote: >> > gpg: connecting dirmngr at '/home/nic/.gnupg/S.dirmngr' failed: IPC >> connect call failed >> > gpg: keyserver receive failed: No dirmngr >> >> if a standard user runtime dir is mounted on /run/user/$UID , the >> dirmngr socket could be mounted there. It sounds like that is probably >> not mounted, so gpg is falling back to the socket location in the home >> directory. >> > > That is right. > > >> but if no dirmngr is running listening on the expected socket, then gpg >> normally tries to launch it itself. >> > > Correct. > > >> for example, i'd expect to see the following: >> >> gpg-connect-agent: no running Dirmngr - starting '/usr/bin/dirmngr' >> gpg-connect-agent: waiting for the dirmngr to come up ... (5s) >> gpg-connect-agent: waiting for the dirmngr to come up ... (4s) >> gpg-connect-agent: connection to dirmngr established >> > >> But i don't see that in your logs. What version of GnuPG is installed? >> > > 2.2.6 > > >> how did dirmnger get installed on this docker system? how did gpg >> itself get installed? >> > > pacman (Archlinux package manager). > > >> >> what is the output of: >> >> gpgconf --list-dirs >> >> (within the docker instance, that is) >> > > sysconfdir:/etc/gnupg > bindir:/usr/bin > libexecdir:/usr/lib/gnupg > libdir:/usr/lib/gnupg > datadir:/usr/share/gnupg > localedir:/usr/share/locale > socketdir:/home/nic/.gnupg > dirmngr-socket:/home/nic/.gnupg/S.dirmngr > agent-ssh-socket:/home/nic/.gnupg/S.gpg-agent.ssh > agent-extra-socket:/home/nic/.gnupg/S.gpg-agent.extra > agent-browser-socket:/home/nic/.gnupg/S.gpg-agent.browser > agent-socket:/home/nic/.gnupg/S.gpg-agent > homedir:/home/nic/.gnupg > > Yes, I meant "systemctl --user import-environment http_proxy". That was a > typo; sorry about that. > > I am looking forward to resolving this. Hopefully, the information above > helps. What should I try next? > > Best regards, L. > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: dirmngr timeout
On Fri 2018-04-13 11:00:59 +0100, Laszlo Papp wrote: > Yes, I meant to reply yesterday after solving this. > > systemd --user import-environment http_proxy > > is what I used. i think you mean: systemctl --user import-environment http_proxy Please read the "Environment Commands" section of systemctl(1) for more details. Another alternative is to add an Environment= directive to dirmngr.service -- you can do this with: systemctl --user edit dirmngr.service or simply by putting the following two lines in ~/.config/systemd/user/dirmngr.service.d/proxy.conf : [Service] Environment=http_proxy=http://192.0.2.8:3128 hth, --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: dirmngr timeout
Hi Laszlo-- I'm afraid we don't know the details of how your docker instance is set up; which versions of which packages you have installed inside docker vs. outside of docker, what's bind-mounted, what the networking constraints are in place. this makes debugging remotely a bit more difficult. On Fri 2018-04-13 15:29:50 +0100, Laszlo Papp wrote: > gpg: connecting dirmngr at '/home/nic/.gnupg/S.dirmngr' failed: IPC connect > call failed > gpg: keyserver receive failed: No dirmngr if a standard user runtime dir is mounted on /run/user/$UID , the dirmngr socket could be mounted there. It sounds like that is probably not mounted, so gpg is falling back to the socket location in the home directory. but if no dirmngr is running listening on the expected socket, then gpg normally tries to launch it itself. for example, i'd expect to see the following: gpg-connect-agent: no running Dirmngr - starting '/usr/bin/dirmngr' gpg-connect-agent: waiting for the dirmngr to come up ... (5s) gpg-connect-agent: waiting for the dirmngr to come up ... (4s) gpg-connect-agent: connection to dirmngr established But i don't see that in your logs. What version of GnuPG is installed? how did dirmnger get installed on this docker system? how did gpg itself get installed? what is the output of: gpgconf --list-dirs (within the docker instance, that is) hth, --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: dirmngr timeout
I still have not managed to solve this. Does anyone have an idea? On Fri, Apr 13, 2018 at 3:29 PM, Laszlo Papp wrote: > Unfortunately, I am seeing the following issue in docker, still. What > would be the solution to this? I am using 2.2.6. > > Step 12/46 : RUN dirmngr < /dev/null && echo "honor_http_proxy" > > /home/nic/.gnupg/dirmngr.conf && touch ~/.gnupg/dirmngr_ldapservers.conf > && ls -ld ~/.gnupg && gpg --keyserver hkp://p80.pool.sks-keyservers. > net:80 --recv-key 702353E0F7E48EDB; cd ~ && git clone > https://aur.archlinux.org/lib32-ncurses5-compat-libs.git > lib32-ncurses5-compat-libs && cd lib32-ncurses5-compat-libs && makepkg -f > --noconfirm > ---> Running in 698013ee8936 > dirmngr[8]: error opening '/home/nic/.gnupg/dirmngr_ldapservers.conf': No > such file or directory > dirmngr[8.0]: permanently loaded certificates: 136 > dirmngr[8.0]: runtime cached certificates: 0 > dirmngr[8.0]:trusted certificates: 136 (135,0,0,1) > dirmngr[8.0]: failed to open cache dir file '/home/nic/.gnupg/crls.d/DIR.txt': > No such file or directory > dirmngr[8.0]: creating directory '/home/nic/.gnupg' > dirmngr[8.0]: creating directory '/home/nic/.gnupg/crls.d' > dirmngr[8.0]: new cache dir file '/home/nic/.gnupg/crls.d/DIR.txt' created > # Home: /home/nic/.gnupg > # Config: [none] > OK Dirmngr 2.2.6 at your service > drwx-- 3 nic admin 4096 Apr 13 13:45 /home/nic/.gnupg > gpg: keybox '/home/nic/.gnupg/pubring.kbx' created > gpg: connecting dirmngr at '/home/nic/.gnupg/S.dirmngr' failed: IPC > connect call failed > gpg: keyserver receive failed: No dirmngr > Cloning into 'lib32-ncurses5-compat-libs'... > ==> Making package: lib32-ncurses5-compat-libs 6.1-1 (Fri Apr 13 13:46:14 > UTC 2018) > ==> Checking runtime dependencies... > ==> Checking buildtime dependencies... > ==> Retrieving sources... > -> Downloading ncurses-6.1.tar.gz... > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft > Speed > 100 3286k 100 3286k0 0 221k 0 0:00:14 0:00:14 --:--:-- > 765k > -> Downloading ncurses-6.1.tar.gz.sig... > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft > Speed > 10072 100720 0 5 0 0:00:14 0:00:12 0:00:02 > 21 > ==> Validating source files with md5sums... > ncurses-6.1.tar.gz ... Passed > ncurses-6.1.tar.gz.sig ... Skipped > ==> Verifying source file signatures with gpg... > ncurses-6.1.tar.gz ... FAILED (unknown public key 702353E0F7E48EDB) > ==> ERROR: One or more PGP signatures could not be verified! > The command '/bin/sh -c dirmngr < /dev/null && echo "honor_http_proxy" > > /home/nic/.gnupg/dirmngr.conf && touch ~/.gnupg/dirmngr_ldapservers.conf > && ls -ld ~/.gnupg && gpg --keyserver hkp://p80.pool.sks-keyservers. > net:80 --recv-key 702353E0F7E48EDB; cd ~ && git clone > https://aur.archlinux.org/lib32-ncurses5-compat-libs.git > lib32-ncurses5-compat-libs && cd lib32-ncurses5-compat-libs && makepkg -f > --noconfirm' returned a non-zero code: 1 > > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: dirmngr timeout
Unfortunately, I am seeing the following issue in docker, still. What would be the solution to this? I am using 2.2.6. Step 12/46 : RUN dirmngr < /dev/null && echo "honor_http_proxy" > /home/nic/.gnupg/dirmngr.conf && touch ~/.gnupg/dirmngr_ldapservers.conf && ls -ld ~/.gnupg && gpg --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-key 702353E0F7E48EDB; cd ~ && git clone https://aur.archlinux.org/lib32-ncurses5-compat-libs.git lib32-ncurses5-compat-libs && cd lib32-ncurses5-compat-libs && makepkg -f --noconfirm ---> Running in 698013ee8936 dirmngr[8]: error opening '/home/nic/.gnupg/dirmngr_ldapservers.conf': No such file or directory dirmngr[8.0]: permanently loaded certificates: 136 dirmngr[8.0]: runtime cached certificates: 0 dirmngr[8.0]:trusted certificates: 136 (135,0,0,1) dirmngr[8.0]: failed to open cache dir file '/home/nic/.gnupg/crls.d/DIR.txt': No such file or directory dirmngr[8.0]: creating directory '/home/nic/.gnupg' dirmngr[8.0]: creating directory '/home/nic/.gnupg/crls.d' dirmngr[8.0]: new cache dir file '/home/nic/.gnupg/crls.d/DIR.txt' created # Home: /home/nic/.gnupg # Config: [none] OK Dirmngr 2.2.6 at your service drwx-- 3 nic admin 4096 Apr 13 13:45 /home/nic/.gnupg gpg: keybox '/home/nic/.gnupg/pubring.kbx' created gpg: connecting dirmngr at '/home/nic/.gnupg/S.dirmngr' failed: IPC connect call failed gpg: keyserver receive failed: No dirmngr Cloning into 'lib32-ncurses5-compat-libs'... ==> Making package: lib32-ncurses5-compat-libs 6.1-1 (Fri Apr 13 13:46:14 UTC 2018) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Downloading ncurses-6.1.tar.gz... % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 3286k 100 3286k0 0 221k 0 0:00:14 0:00:14 --:--:-- 765k -> Downloading ncurses-6.1.tar.gz.sig... % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 10072 100720 0 5 0 0:00:14 0:00:12 0:00:02 21 ==> Validating source files with md5sums... ncurses-6.1.tar.gz ... Passed ncurses-6.1.tar.gz.sig ... Skipped ==> Verifying source file signatures with gpg... ncurses-6.1.tar.gz ... FAILED (unknown public key 702353E0F7E48EDB) ==> ERROR: One or more PGP signatures could not be verified! The command '/bin/sh -c dirmngr < /dev/null && echo "honor_http_proxy" > /home/nic/.gnupg/dirmngr.conf && touch ~/.gnupg/dirmngr_ldapservers.conf && ls -ld ~/.gnupg && gpg --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-key 702353E0F7E48EDB; cd ~ && git clone https://aur.archlinux.org/lib32-ncurses5-compat-libs.git lib32-ncurses5-compat-libs && cd lib32-ncurses5-compat-libs && makepkg -f --noconfirm' returned a non-zero code: 1 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: dirmngr timeout
On Fri, Apr 13, 2018 at 10:46 AM, Werner Koch wrote: > On Thu, 12 Apr 2018 15:45, lp...@kde.org said: > > [Full quote trimmed] > > It looks like if I run dirmngr manually, as follows, with > honor-http-proxy, > > gpg works: > > > > dirmngr --daemon > > It will also work if dirnmnr is automatically started by gpg or via > gpgconf --launch dirmngr. > > > But when it is run as dirmngr --supervised, gpg does not seem to work > until > > the http-proxy is specified in the config explicitly. > > It seems that systemd has a different view on the envvars and thus your > somewhere set http_proxy=foo:port is not inherited by dirmngr. > According to IRC there are ways to set envvars for specific systemd > actions. If can find them out it would be nice if you can document that > in a reply. > Yes, I meant to reply yesterday after solving this. systemd --user import-environment http_proxy is what I used. > > > Shalom-Salam, > >Werner > > > -- > # Please read: Daniel Ellsberg - The Doomsday Machine # > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: dirmngr timeout
On Thu, 12 Apr 2018 15:45, lp...@kde.org said: [Full quote trimmed] > It looks like if I run dirmngr manually, as follows, with honor-http-proxy, > gpg works: > > dirmngr --daemon It will also work if dirnmnr is automatically started by gpg or via gpgconf --launch dirmngr. > But when it is run as dirmngr --supervised, gpg does not seem to work until > the http-proxy is specified in the config explicitly. It seems that systemd has a different view on the envvars and thus your somewhere set http_proxy=foo:port is not inherited by dirmngr. According to IRC there are ways to set envvars for specific systemd actions. If can find them out it would be nice if you can document that in a reply. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpV7iVLmJ2kP.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: dirmngr timeout
On Thu, Apr 12, 2018 at 9:30 AM, Laszlo Papp wrote: > > > On Wed, Apr 11, 2018 at 8:09 PM, Werner Koch 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, >> though. >> >> Do you have the envvar http_proxy set? If so you also need to have >> >> honor-http-proxy >> >> 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, gpg works: dirmngr --daemon But when it is run as dirmngr --supervised, gpg does not seem to work until the http-proxy is specified in the config explicitly. > Salam-Shalom, > >> >>Werner >> >> -- >> # Please read: Daniel Ellsberg - The Doomsday Machine # >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >> >> ___ >> Gnupg-users mailing list >> Gnupg-users@gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> >> > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: dirmngr timeout
On Wed, Apr 11, 2018 at 8:09 PM, Werner Koch 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, > though. > > Do you have the envvar http_proxy set? If so you also need to have > > honor-http-proxy > > 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? > Salam-Shalom, > >Werner > > -- > # Please read: Daniel Ellsberg - The Doomsday Machine # > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: dirmngr timeout
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, though. Do you have the envvar http_proxy set? If so you also need to have honor-http-proxy in your dirmngr.conf. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp2TcxEzRZTd.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: dirmngr timeout
On Tue, Apr 10, 2018 at 3:29 PM, Werner Koch wrote: > On Tue, 10 Apr 2018 14:29, lp...@kde.org said: > > > wget -4 -v -O/dev/null http://80.108.201.53:80 > > Please try this also: > > wget -vOx 'http://80.108.201.53:80/pks/lookup?op=get&options=mr&; > search=0x702353E0F7E48EDB' > > This is the actual request dirmngr does. 'x' has the key then; please > check. > wget -vOx ' http://80.108.201.53:80/pks/lookup?op=get&options=mr&search=0x702353E0F7E48EDB ' --2018-04-10 16:10:08-- http://80.108.201.53/pks/lookup?op=get&options=mr&search=0x702353E0F7E48EDB ... Proxy request sent, awaiting response... 200 OK Length: 58162 (57K) [application/pgp-keys] Saving to: ‘x’ x 100%[==>] 56.80K --.-KB/sin 0.01s 2018-04-10 16:10:08 (4.29 MB/s) - ‘x’ saved [58162/58162] cat x -BEGIN PGP PUBLIC KEY BLOCK- Version: SKS 1.1.6 Comment: Hostname: keyserver.miniskipper.at mQGiBD/4r7IRBADFuacEqf9fye+NQSm7xjNP705aq75VrUd2hJyPmSiFUIyQEfc44GQXGdFg +/Apq4iq/50/8pR8YXOKwP5OE69emEp7IxjST41orGUk5ZwcnlSkaruNWLTe/lN3e0oOIVbY ig1lUbU5IxZu03KfNg2DZ9JiZdNBlzlqx1+oFlWFLwCg3awgEfOUfbe4kVxNrsnxaCJYJ38E AMRVyUOfhkm9l0YuiC4ebOHrdmn9jFVW+XZPZDeb8DcyTBNrgvVTnEmrNzVJgOyZIW+uraBV itak+No1kwXvC/i0kZEzYqfG87EdJSfeOV7axIRisiTrcbZdRJ3CBDtGvLqJ9OuGFHPQmntn ZfhiwJTR79hepndEQYyV5eQboQ+aA/0bI+/odyRDefc9HF1EhOcz8E76QP+VlvUfIDUJrmwv /3gLZ968HACOe0DE+bcUockLJxoNwQFwCQPjm5S2+Ba2uY4hRhOA+MResZWlPouoosay2ADf iU7pdBCxnbcLAuezgnZg4jcXvLl1QiAihxaEI2jqgZBnnierWzqRzRZM4LQrVGhvbWFzIERp Y2tleSA8ZGlja2V5QGludmlzaWJsZS1pc2xhbmQubmV0PohGBBARAgAGBQJCkMV3AAoJEIvY Lm8wuUtcwrsAn2Nb0qwppoWfwQUVOKNDEwpdM1d9AJ9WAeZcDap/wfnxevVm49edWnWJgYhG BBMRAgAGBQJWd8sPAAoJEF3fj7dojjGmdGwAn1QhYfhswwjV5md0XJgyoycVu7+GAJ9AKQoI kvLWQtl9mTrPOFsCQSBe74heBBMRAgAeBQI/+K+yAhsDBgsJCAcDAgMVAgMDFgIBAh4BAheA AAoJEHAjU+D35I7bejEAnRYLqlswwk+F+pWcppXLnsskhTfSAKCrg23hTwzaaW9mlbmDavid +QQu3YheBBMRAgAeBQI/+K+yAhsDBgsJCAcDAgMVAgMDFgIBAh4BAheAAAoJEHAjU+D35I7b ejEAnimR6EoAAiEJPea1nn80i1C3KY8aAJ41XrfHtf9Yp3cE/8Aw5zmww3zNlIkBIQQQAQIA DAUCTTs5qAUDABJ1AAAKCRCXELibyletfPqjB/dFnhX6ap/V+z0b/NxBhOiYGofwJ1aLRpGt vcRfUp2c28MOd1dhf27fA/+2Byrk4sfaPajUY25uWHH0qhDMU026BPrLaNoc6Eak/9fkpMZ1 2YU5/rncJULBzlTWyRzXiTFDoMe7mxesJq7zSxB3l8vTnVrBE5B6vwHIRD5Y2h6qp0GIe9n/ AJMj3t2CoBVm/3+qEDN38CRsAD+TXLrFRN6V8dkCLB5UX2w/j8Uvaj5PrGtePR0wI5z77jjN VR0sG5cqqo0xbH6tiG8a7GuxEV9Nsn7KpiNstaazYxCVxFoeXy5RKYt2+6G9taBwGHGLEnxM qbBWTRwCyLs/BILho9KJASIEEAECAAwFAkJG55MFAwASdQAACgkQlxC4m8pXrXwhzQgAkSBD CXpkVz1PnO/k4pO5or0WtjDIN8mzajHcMTrLSZf1dGp5B1741V09gM5a5+xxCp1N0Sr2szJQ 3oxdRYoFKQpgGbeoivx69t/1fQzheyC7kxdDkfacsiInb7yeyfvPfNDT9/UCeL7FinjMup7g PzPbz5imAVE8gTXrHE86l7yMRU/RisoMNjkCMxJJk/0TkmMPlgsnWKpW0tDODXfQ+p9nAnSM FcTDZj1bcgr9qFE94hE/nB4imGy7Y2Pyy2hkrUVhIary1P/nziWpP6pKW85SSMW/8u/jor/1 ryImrzzUSFMFaLHwpPq1VNwEbxDUDazJH2j8PfMXpStMLsWZXYkBIgQQAQIADAUCQlgonwUD ABJ1AAAKCRCXELibyletfIS6CADDeXZws1WjpoGLCBTgL18Qf8BtitA4WmhAbk9BHoU+gH3i CaXZfxjPXib722M8lw2BrZ+UGW9NShu4D1dmUmKOcEnKw+polbcIXED9ab2UoSQL3SnlBa6s png2AWXL71WFAzdu/FXpIiAyj04MiwOyYqNL9TfaHji5tkutMkMOCXks+pgUP2hfhWNeWTUH gEr/q+/DGJI95THFeMJbDlxlAMYBfHoy5UfdVBCwVzQX2vxXTgSOUdxHO3GiV/x3llODip6l v02tptlkboimb4L0KobAVAt3eZNeB2AhSqja6srqs4GiqzmuVBalV6qpGfKWk+wI6IimiK0E Z0nxAFjXiQEiBBABAgAMBQJCafbnBQMAEnUAAAoJEJcQuJvKV618S9kH/1P69nxrz2M1pSxg BinLCulwCDk964eoglsH8/MvgzKiyQLnEGiaKJGfJJaaACSO5ehEUUab1pzz80cr8LGIgXuu GiDrLKdLrvF1Y0KMdN+qz/6ABQ9a//9HshZaSprBPwB0qt6OcVDzgNHwh1VhSK+2WfuX4ajb AXLimU8meEoYJ6tBMERD4ci78HhVPvaXxwZjCLMJP6ncJHW+1k7X7jMHdClPiMubmhW9+zyc zojTzj1H1ZnokGNYe0TzpVfqxGQaayRICeUym1yLZGSUAIO2V9FyfmAb3oAY56UFKjUpArnY icz29/Wqzw/aYcnztPH4CzhdfsAWb08TzTzQM4GJASIEEAECAAwFAkJ8bXcFAwASdQAACgkQ lxC4m8pXrXwHCgf/V4aLbchOUCv2QpCJwoeXHoGCZve15inevBeDjXovItHCe+uRlWEwKuj6 3YNRP4wiuwUlMspTjtBrg3gIXoai3MtXJGjuyGJbY7kSZfIywK+Dcea7pwuCj8pMU1lbe7uj w7ZJPFegAKosiqusVhN7IqB3g2/PaKF8nyaTvpqo+kCgVhJZ5v71dGlxJlV2k8rgiQHV4Kvu PvBOVlcSvYDHGOtZ33F4oCv2b0xwMse8Z17FXj2LT2RZaRHmVj1cVq/VZJhYkHzypztC0orh aasGxH8sjkHaswS23li0qUKTlIy7JxqpgCvPCC++/5nXrVVuuy3cXpK+sGaUYqqNQNhxeYkB IgQQAQIADAUCQo2T6AUDABJ1AAAKCRCXELibyletfOEgB/sHQJOBMyMZOmj738i4+WT2aIaF 9y0eOhMCnYd4PPTWbV11u4SoG4aivRzWyAdKk5E7Q4HieOrbGCa0PyhFdLFoPOS8r37wWrmj o9MpfRSYXUTvbx3v6mI5XdxSZZRKjy72K8UECr2ksXFsIiBnZRRG70h0XWWvqHElzRUVDPMG ZtoGddHIUY6Egif7hmB23QRGpuJucTRCVfPQC9i5YJVxlLQ1Vbe+Y53vfO920ph4XEyRQCGQ Rb2rRLbrEtOH2UteCijmQsL6AWp/VOS7PiFg16Q1n9/Bnzk/cWQpuihOULEMIJm5hIHG6KVF 5KyN2SZtOWtisrmzDKynf5GUxYQsiQEiBBABAgAMBQJCn2FpBQMAEnUAAAoJEJcQuJvKV618 5joIAKFMlfN/fn9UTOF59VsycoyzBMVBSkJTiHzgVEPnkhsc75q5j9XFU0Zi7+mgp9Mbcyt+ CB1z43tDz4S0FG3uHFAXAzL3MkVYey7TiDXXLVtKJVX7XodkOeiFjmFb278hBG85S2t2piG2 kcY/G/26/xQ14nDAG9knoRtUHDEUOmjWDZ+hWpYJ8svgU6YqMP06r/ryqr7yOSr2O998Ba7x jNKwek9A4PolJ9+6GnLs+NqS3FU7LCpIXkjZFBPGQTWniU5J2PKG1xn8r90+cFYJhvNb7QOp 22bz79IZ3UuRyAvIRyy/bfKYaif9mvRVHgdyicn/bLWSxcOBR9MIcG5MTlOJASIEEAECAAwF AkKyjVMFAwASdQAACgkQlxC4m8pXrXxVBAf8C71P1kPCiHDqNDeViNqj0tVeefyFjKjYl0eq 1dGsXMe/M2+8cmw0SRpMWkaJzVMsT6KOHVDxJh
Re: dirmngr timeout
On Tue, 10 Apr 2018 14:29, lp...@kde.org said: > wget -4 -v -O/dev/null http://80.108.201.53:80 Please try this also: wget -vOx 'http://80.108.201.53:80/pks/lookup?op=get&options=mr&search=0x702353E0F7E48EDB' This is the actual request dirmngr does. 'x' has the key then; please check. > Yes, I do have a corporate proxy, however, the environment variables are > set up properly. Other applications work. Having said that, port 80 is used A simple proxy or one of those application firewalls? Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpZI5rFRIKTJ.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
dirmngr timeout
Dear gnupg developers, I keep getting a timeout for "gpg -v --keyserver hkp:// p80.pool.sks-keyservers.net:80 --recv-key 702353E0F7E48EDB" as follows: tail -F /home/lpapp/dirmngr.log 2018-04-10 11:58:03 dirmngr[11735.6] DBG: chan_6 -> ERR 167805060 Connection timed out 2018-04-10 11:58:03 dirmngr[11735.6] DBG: chan_6 <- BYE 2018-04-10 11:58:03 dirmngr[11735.6] DBG: chan_6 -> OK closing connection 2018-04-10 11:58:03 dirmngr[11735.6] handler for fd 6 terminated 2018-04-10 12:08:04 dirmngr[11735.0] running scheduled tasks 2018-04-10 12:18:04 dirmngr[11735.0] running scheduled tasks 2018-04-10 12:28:04 dirmngr[11735.0] running scheduled tasks 2018-04-10 12:38:05 dirmngr[11735.0] running scheduled tasks 2018-04-10 12:47:30 dirmngr[11735.0] SIGTERM received - shutting down ... 2018-04-10 12:47:31 dirmngr[11735.0] dirmngr (GnuPG) 2.2.5 stopped 2018-04-10 12:48:15 dirmngr[14734.0] permanently loaded certificates: 136 2018-04-10 12:48:15 dirmngr[14734.0] runtime cached certificates: 0 2018-04-10 12:48:15 dirmngr[14734.0]trusted certificates: 136 (135,0,0,1) 2018-04-10 12:48:15 dirmngr[14734.6] handler for fd 6 started 2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> # Home: /home/lpapp/.gnupg 2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> # Config: /home/lpapp/.gnupg/dirmngr.conf 2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> OK Dirmngr 2.2.5 at your service 2018-04-10 12:48:15 dirmngr[14734.6] connection from process 14733 (1000:1000) 2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 <- GETINFO version 2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> D 2.2.5 2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> OK 2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 <- KEYSERVER --clear hkp:// p80.pool.sks-keyservers.net:80 2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> OK 2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 <- KS_GET -- 0x702353E0F7E48EDB 2018-04-10 12:48:15 dirmngr[14734.6] DBG: dns: libdns initialized 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_name( p80.pool.sks-keyservers.net): Success 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '212.51.156.40' 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '212.47.242.101' 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '192.167.206.241' 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '192.94.109.73' 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '185.95.216.79' 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '85.25.235.230' 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '80.108.201.53' 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '69.164.220.134' 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '24.134.103.65' 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '18.9.60.141' 2018-04-10 12:48:25 dirmngr[14734.6] number of system provided CAs: 153 2018-04-10 12:48:25 dirmngr[14734.6] DBG: http.c:connect_server: trying name='24.134.103.65' port=80 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_name(24.134.103.65): Success 2018-04-10 12:50:37 dirmngr[14734.6] can't connect to '24.134.103.65': Connection timed out 2018-04-10 12:50:37 dirmngr[14734.6] error connecting to ' http://24.134.103.65:80': Connection timed out 2018-04-10 12:50:37 dirmngr[14734.6] selecting a different host due to a timeout 2018-04-10 12:50:37 dirmngr[14734.6] DBG: http.c:connect_server: trying name='80.108.201.53' port=80 2018-04-10 12:50:37 dirmngr[14734.6] DBG: dns: resolve_dns_name(80.108.201.53): Success 2018-04-10 12:52:48 dirmngr[14734.6] can't connect to '80.108.201.53': Connection timed out 2018-04-10 12:52:48 dirmngr[14734.6] error connecting to ' http://80.108.201.53:80': Connection timed out 2018-04-10 12:52:48 dirmngr[14734.6] selecting a different host due to a timeout 2018-04-10 12:52:48 dirmngr[14734.6] DBG: http.c:connect_server: trying name='185.95.216.79' por
dirmngr timeout
Dear gnupg developers, I keep getting a timeout for "gpg -v --keyserver hkp:// p80.pool.sks-keyservers.net:80 --recv-key 702353E0F7E48EDB" as follows: tail -F /home/lpapp/dirmngr.log 2018-04-10 11:58:03 dirmngr[11735.6] DBG: chan_6 -> ERR 167805060 Connection timed out 2018-04-10 11:58:03 dirmngr[11735.6] DBG: chan_6 <- BYE 2018-04-10 11:58:03 dirmngr[11735.6] DBG: chan_6 -> OK closing connection 2018-04-10 11:58:03 dirmngr[11735.6] handler for fd 6 terminated 2018-04-10 12:08:04 dirmngr[11735.0] running scheduled tasks 2018-04-10 12:18:04 dirmngr[11735.0] running scheduled tasks 2018-04-10 12:28:04 dirmngr[11735.0] running scheduled tasks 2018-04-10 12:38:05 dirmngr[11735.0] running scheduled tasks 2018-04-10 12:47:30 dirmngr[11735.0] SIGTERM received - shutting down ... 2018-04-10 12:47:31 dirmngr[11735.0] dirmngr (GnuPG) 2.2.5 stopped 2018-04-10 12:48:15 dirmngr[14734.0] permanently loaded certificates: 136 2018-04-10 12:48:15 dirmngr[14734.0] runtime cached certificates: 0 2018-04-10 12:48:15 dirmngr[14734.0]trusted certificates: 136 (135,0,0,1) 2018-04-10 12:48:15 dirmngr[14734.6] handler for fd 6 started 2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> # Home: /home/lpapp/.gnupg 2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> # Config: /home/lpapp/.gnupg/dirmngr.conf 2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> OK Dirmngr 2.2.5 at your service 2018-04-10 12:48:15 dirmngr[14734.6] connection from process 14733 (1000:1000) 2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 <- GETINFO version 2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> D 2.2.5 2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> OK 2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 <- KEYSERVER --clear hkp:// p80.pool.sks-keyservers.net:80 2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> OK 2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 <- KS_GET -- 0x702353E0F7E48EDB 2018-04-10 12:48:15 dirmngr[14734.6] DBG: dns: libdns initialized 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_name( p80.pool.sks-keyservers.net): Success 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '212.51.156.40' 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '212.47.242.101' 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '192.167.206.241' 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '192.94.109.73' 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '185.95.216.79' 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '85.25.235.230' 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '80.108.201.53' 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '69.164.220.134' 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '24.134.103.65' 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success 2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for ' p80.pool.sks-keyservers.net': '18.9.60.141' 2018-04-10 12:48:25 dirmngr[14734.6] number of system provided CAs: 153 2018-04-10 12:48:25 dirmngr[14734.6] DBG: http.c:connect_server: trying name='24.134.103.65' port=80 2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_name(24.134.103.65): Success 2018-04-10 12:50:37 dirmngr[14734.6] can't connect to '24.134.103.65': Connection timed out 2018-04-10 12:50:37 dirmngr[14734.6] error connecting to ' http://24.134.103.65:80': Connection timed out 2018-04-10 12:50:37 dirmngr[14734.6] selecting a different host due to a timeout 2018-04-10 12:50:37 dirmngr[14734.6] DBG: http.c:connect_server: trying name='80.108.201.53' port=80 2018-04-10 12:50:37 dirmngr[14734.6] DBG: dns: resolve_dns_name(80.108.201.53): Success 2018-04-10 12:52:48 dirmngr[14734.6] can't connect to '80.108.201.53': Connection timed out 2018-04-10 12:52:48 dirmngr[14734.6] error connecting to ' http://80.108.201.53:80': Connection timed out 2018-04-10 12:52:48 dirmngr[14734.6] selecting a different host due to a timeout 2018-04-10 12:52:48 dirmngr[14734.6] DBG: http.c:connect_server: trying name='185.95.216.79