Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
On 2021-02-24 at 12:40 +0100, Erich Eckner wrote: > Hi, > > thanks, again, just a minor typo: > > > --use-tor > > --no-use-tor > > > >The option --use-tor switches Dirmngr and thus GnuPG into ``Tor > >mode'' to route all net‐ work access via Tor (an anonymity network). > >Certain other features are disabled in this mode. The effect of > >--use-tor cannot be overridden by any other command or even by > >reloading dirmngr. The use of --no-use-tor disables the use of Tor. > >The default is to use Tor if it is available on startup or after > >reloading dirmngr. The test on the avail‐ able of Tor is done by > >trying to connects to a SOCKS proxy at either port 9050 or 9150); if > > -reloading dirmngr. The test on the avail‐ able of Tor is done by > -trying to connects to a SOCKS proxy at either port 9050 or 9150); if > +reloading dirmngr. The test on the avail‐ ability of Tor is done by > +trying to connect to a SOCKS proxy at either port 9050 or 9150); if > > >another type of proxy is listening on one of these ports, you should > >use --no-use-tor. > > Note the last ) should be removed… ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On Wed, 24 Feb 2021, Werner Koch wrote: On Fri, 22 Jan 2021 20:59, Erich Eckner said: Thank you for your time! For everyone to benefit from my problem, I'd like to suggest to clarify in the documentation, that and how tor will be I'll change the option description to: thanks, again, just a minor typo: --use-tor --no-use-tor The option --use-tor switches Dirmngr and thus GnuPG into ``Tor mode'' to route all net‐ work access via Tor (an anonymity network). Certain other features are disabled in this mode. The effect of --use-tor cannot be overridden by any other command or even by reloading dirmngr. The use of --no-use-tor disables the use of Tor. The default is to use Tor if it is available on startup or after reloading dirmngr. The test on the avail‐ able of Tor is done by trying to connects to a SOCKS proxy at either port 9050 or 9150); if - -reloading dirmngr. The test on the avail‐ able of Tor is done by - -trying to connects to a SOCKS proxy at either port 9050 or 9150); if +reloading dirmngr. The test on the avail‐ ability of Tor is done by +trying to connect to a SOCKS proxy at either port 9050 or 9150); if another type of proxy is listening on one of these ports, you should use --no-use-tor. Shalom-Salam, Werner regards, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmA2Oy8ACgkQCu7JB1Xa e1oIkBAAknFv699JQJY/axHlXwWZxtF+70kqEvHgg4uc/DfZ1u4xJcwP7umJz6v5 +SIT0QJCxfe6h/lSRADyfurXnYHBH5k3Bxucnc0EPw/c1dasvxOyYg9q6tfENF38 HQl6g8LYHBXqdm4qUDGxEwAEnoH8XJTL90lE/1dFInQtJMPF9giSvlvJVtxLBv44 QYwhi814kh+tzwgAC54QhAFIOuEKOWSIV0mwhcr81/vIo0LNszzc2NPsMzOjQYwB niEpyCcj69RGNzDxjYvIa5I4hjz3SecuJrqGosgi1l/hRWquEZSMn6Gs6tuNn2iV Ka1oduf2bjUP7kZcQOPVUnwdx1nEPaREC5OgAMm3rhy5Qv6aXz52t8wNlQzFmyvS 7uHq2xx29WCscY79y7vaYIvO75bBynOR5t6/AIyPIgTdvQDWcTabK79HZAgpzZH2 QfZqlT/yPLRRN9kqkhyp3jN/i7Zm5I5GX1tw3sFYKQRv0D5NCTkGwxh0Ry2OS6Hh JMqXINZU/AqtSsZE8NtMnYipGMBvA50tBIgjuJozBJNS/cWloLLpeo+P/EVSUGYM Mh66VztyVTu+/b9wjoY0g6deVj049M/JljkETMUZyrQ6iQOJ9p51D5bkYg1qimNj jm8+oxnM4bqV0nBPqRswfsHxqtM9A9Oj2K2XxfOk/D/bgA+Vfic= =+Z6P -END PGP SIGNATURE-___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
On Fri, 22 Jan 2021 20:59, Erich Eckner said: > Thank you for your time! For everyone to benefit from my problem, I'd like > to suggest to clarify in the documentation, that and how tor will be I'll change the option description to: --use-tor --no-use-tor The option --use-tor switches Dirmngr and thus GnuPG into ``Tor mode'' to route all net‐ work access via Tor (an anonymity network). Certain other features are disabled in this mode. The effect of --use-tor cannot be overridden by any other command or even by reloading dirmngr. The use of --no-use-tor disables the use of Tor. The default is to use Tor if it is available on startup or after reloading dirmngr. The test on the avail‐ able of Tor is done by trying to connects to a SOCKS proxy at either port 9050 or 9150); if another type of proxy is listening on one of these ports, you should use --no-use-tor. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
On 2021-01-22 at 18:05 +0100, Erich Eckner via Gnupg-users wrote: > > I was more wondering, why gpg decides to go into "tor mode" on box #2, > when there is actually no tor installed or running. I'm totally happy to > force non-tor mode via config file, but I'm also open to help find the > root for gpg's misjudgement of tor-availability. The check is in dirmngr.c: > int > dirmngr_use_tor (void) > { > if (tor_mode == TOR_MODE_AUTO) > { > /* Figure out whether Tor is running. */ > assuan_fd_t sock; > > sock = assuan_sock_connect_byname (NULL, 0, 0, NULL, ASSUAN_SOCK_TOR); > if (sock == ASSUAN_INVALID_FD) > tor_mode = TOR_MODE_NO; > else > { > tor_mode = TOR_MODE_YES; > assuan_sock_close (sock); > } That assuan_sock_connect_byname() tests the connection by connecting to both tor port (9050) and the tor browser port (9150). It actually starts negotiating a request (see socks5_connect) > > /* For HOST being NULL we pass an empty string which indicates to > socks5_connect to stop midway during the proxy negotiation. Note > that we can't pass NULL directly as this indicates IP address I don't see how it would automatically treat it as having tor unless you have a socks server on either 9050 or 9150. Best regards ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 22 Jan 2021, Erich Eckner via Gnupg-users wrote: I was more wondering, why gpg decides to go into "tor mode" on box #2, when there is actually no tor installed or running. I'm totally happy to force non-tor mode via config file, but I'm also open to help find the root for gpg's misjudgement of tor-availability. I found it! https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libassuan.git;a=blob;f=src/assuan-socket.c;h=9a24f1a11fbe4e7973fbd6b82a602abe1a009e8e;hb=HEAD#l1106 libassuan merely tries to connect via socks on the correct port (9050 for tor). I have a ssh socks proxy running on that port. Thank you for your time! For everyone to benefit from my problem, I'd like to suggest to clarify in the documentation, that and how tor will be auto-detected (really just a suggestion, feel free to reject or ignore it). cheers, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmALLpEACgkQCu7JB1Xa e1rXhg//WhrPIi6tcW0as1ghKhHjzeQyubz7tvgqhPyPvBbJZuiTvY32gkE8tFKp AAKhVTXxra+izWJup3cfHFmvafTeTRMcFy6z3E+nsE4UscJNvdSAa6IB92iCAYZz UsXWTSu+L3gwryLFuplPUi76HxGGwfbm+4HqY9bo4dw9RvPGWzR2gms9VFwSg0AV Pf2G7VakRLgki5zpBVQBKtbRzoj08X99mRpILF3QJWeYUe5FXAWyH7h6JAUZbmDt YkeHv/b6OhYeZRss/WPuSubP1nMWykBfExj+nPziU6Ojli4oIGQWjJyJ428R/0vl skfUigllJERvqcquRvZ2yNmPQg7aJv2yGdIYQ7wjyrZlN6QDIy+DujE9OEfM3t0X 28uCFuC38tIeyUhgK23dpmwZG3PZCaUp9un7/YhLudshCiLbZmq6uyovkuk5xqBj xn0gkizzrPEjCo6GrOhqqJrdMW2vxwVc9hXHddqmvYWwWD8jMYwcwqrTS7Qw6DFz rv+1C+z+rpIerlCR1NbSHR2KBf1oTU7hm8v7SoZKSZtSguRwbNQq1ke8jLkP+cPG DnR2hZnaQ8x/lhCBabPAv5B2Prxmg9xgmAcDQIR11kt9/cxpfPLb2avwVRQ3M9Hn QfaDDPpPFAR2sAZuviViISECKUepWx79VPcBPcq2SmE6Wo9FAZM= =OPMp -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, first: Maybe I should migrate this discussion to the bug tracker? But I'm always somewhat hesitant to open new bugs, because I always assume, I'm just too stupid to properly configure everything :-) On Fri, 22 Jan 2021, Werner Koch wrote: On Fri, 22 Jan 2021 13:24, Erich Eckner said: Box 1: tor (but no DNS endpoint exposed), named listening on 127.0.0.1:53 (used by /etc/resolv.conf) In Tor mode we use 8.8.8.8 as DNS Server unless you use --nameserver ipaddr In ``Tor mode'' Dirmngr uses a public resolver via Tor to resolve DNS names. If the default public resolver, which is 8.8.8.8, shall not be used a different one can be given us‐ ing this option. Note that a numerical IP address must be given (IPv6 or IPv4) and that no error checking is done for ipaddr. this is all implemented using a full DNS resolver library inside dirmngr (which you can also truns into a --recursive-resolver). If you don't want this, or DNS over Tor and if you are not on Windows you may use --standard-resolver. standard-resolver works (in DNS) on box 1, all other options (even "nameserver 127.0.0.1") give: 4 - 17:25:37 dirmngr[3382567.6]: DBG: dns: resolve_dns_name(openpgpkey.eckner.net): Permission denied 4 - 17:25:37 dirmngr[3382567.6]: DBG: dns: getsrv(_openpgpkey._tcp.eckner.net): Permission denied However, with "standard-resolver" dns works, but the actual fetch fails: 4 - 17:28:28 dirmngr[3383211.6]: DBG: dns: resolve_dns_name(openpgpkey.eckner.net): Success 4 - 17:28:28 dirmngr[3383211.6]: can't connect to 'openpgpkey.eckner.net': Permission denied 4 - 17:28:28 dirmngr[3383211.6]: error connecting to 'https://openpgpkey.eckner.net/.well-known/openpgpkey/eckner.net/hu/81t9qcnyscdr3uatodn7eejogt6tpa8q?l=erich': Permission denied 4 - 17:28:28 dirmngr[3383211.6]: command 'WKD_GET' failed: Permission denied This means, the connection through tor fails, right? This is strange, because a plain curl -x socks5h://127.0.0.1:9050 'https://openpgpkey.eckner.net/.well-known/openpgpkey/eckner.net/hu/81t9qcnyscdr3uatodn7eejogt6tpa8q?l=erich' and also with -4 or -6 works just fine. Looking at tor's log, I see: Tor[2692608]: Your application (using socks5 to port 443) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider using Socks4A (e.g. via privoxy or socat) instead. For more information, please see https://wiki.torproject.org/TheOnionRouter/TorFAQ#SOCKSAndDNS. Rejecting. [1 similar message(s) suppressed in last 5 seconds] This is probably due to "SafeSocks 1" in my torrc. So gnupg resolves the ip and tries to connect to that directly through tor, but tor refuses to do that. It would be really nice, if the name resolution could be handed over to the socks layer, but at least, I now understand, why it fails (and that I probably have no other choice as to disable SafeSocks in tor or not-use tor for gpg). Box 2: named listening on 127.0.0.1:53 (used by /etc/resolv.conf), dnsdist listening on $all_public_ips:53 (used by external clients, relaying to named and iodine as needed), iodine listening on 127.0.0.1:5353 Does gnupg interpret any of these as tor dns endpoints? How does gnupg determine, how to query dns? In non-Tor mode /etc/resolv.conf etc is parsed. --debug dns should show errors or fallbacks for unknown statements. I was more wondering, why gpg decides to go into "tor mode" on box #2, when there is actually no tor installed or running. I'm totally happy to force non-tor mode via config file, but I'm also open to help find the root for gpg's misjudgement of tor-availability. The additional "debug dns" line didn't change anything noticeably for me, I already have "debug ipc,network,dns", so probably it's redundant? I see. I would need to check how to enable all DNS debugging. You have "verbose" also in your dirmngr.conf? yes, my current content is: log-file socket:///home/erich/.gnupg/dirmngr.log verbose debug ipc,network,dns Note, that I *do* see some dns lines (the ones which I posted earlier). I'd prefer to use tor for retrieving keys (if possible). Is there a possibility to turn off dns resolution via tor, but still do all the rest through tor? I don't think so. It is quite some time since I last worked on the Tor features. (dirmngr/dns-stuff.c, dirmngr/dns.c are the main files) Well, from what you wrote before, I understood, that using --nameserver alongside --use-tor, it would query dns directly and do everything else through tor. Maybe, I got something wrong. But this doesn't matter, because I was thinking in the complete wrong direction: If I cannot solve the dns resolution problem through tor, I also cannot use tor (with my current tor config) for direct key retrieval. disable-ipv4 / disable-ipv6 does not make any difference (without also adding "no-use-tor", of course) Sometimes it makes a
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
On Fri, 22 Jan 2021 13:24, Erich Eckner said: > Box 1: tor (but no DNS endpoint exposed), named listening on 127.0.0.1:53 > (used by /etc/resolv.conf) In Tor mode we use 8.8.8.8 as DNS Server unless you use --nameserver ipaddr In ``Tor mode'' Dirmngr uses a public resolver via Tor to resolve DNS names. If the default public resolver, which is 8.8.8.8, shall not be used a different one can be given us‐ ing this option. Note that a numerical IP address must be given (IPv6 or IPv4) and that no error checking is done for ipaddr. this is all implemented using a full DNS resolver library inside dirmngr (which you can also truns into a --recursive-resolver). If you don't want this, or DNS over Tor and if you are not on Windows you may use --standard-resolver. > Box 2: named listening on 127.0.0.1:53 (used by /etc/resolv.conf), dnsdist > listening on $all_public_ips:53 (used by external clients, relaying to > named and iodine as needed), iodine listening on 127.0.0.1:5353 > > Does gnupg interpret any of these as tor dns endpoints? How does gnupg > determine, how to query dns? In non-Tor mode /etc/resolv.conf etc is parsed. --debug dns should show errors or fallbacks for unknown statements. > The additional "debug dns" line didn't change anything noticeably for me, > I already have "debug ipc,network,dns", so probably it's redundant? I see. I would need to check how to enable all DNS debugging. You have "verbose" also in your dirmngr.conf? > I'd prefer to use tor for retrieving keys (if possible). Is there a > possibility to turn off dns resolution via tor, but still do all the rest > through tor? I don't think so. It is quite some time since I last worked on the Tor features. (dirmngr/dns-stuff.c, dirmngr/dns.c are the main files) > disable-ipv4 / disable-ipv6 does not make any difference (without also > adding "no-use-tor", of course) Sometimes it makes a difference in particular on my Windows VM. > version:1.8.7:10807:1.39-unknown:12700: Build against an older libgpg-error (aka gpgrt) version but that does not matter. > * GpgRT 1.41-unknown (000) That is the actual version used. > I don't see any libdns there. Box #1 only differs in the cpu flags line: No library but the (modified) implementation by William Ahern. CPU flags are not relevant here; they are runtime tested. Shalom-Salam, Werner -- * Free Assange and protect free journalism! * Germany: Sign the Treaty on the Prohibition of Nuclear Weapons! signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 22 Jan 2021, Werner Koch wrote: On Thu, 21 Jan 2021 15:05, Erich Eckner said: 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: dns: libdns initialized (tor mode) 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: dns: Your are using Tor for DNS queries, that is the actual DNS server is 8.8.8.8. Tor mode is used if you are running the Tor client or the Tor browser. Put no-use-tor into dirmngr.conf and to get DNS debug messages add "debug dns". Ah, indeed: one machine runs a tor client, adding "no-use-tor" makes things work, there (as far as I can see, there is no tor dns endpoint exposed on that box). The other doesn't run tor, but adding "no-use-tor" makes things work, there, too. To summarize the running DNS relevant software: Box 1: tor (but no DNS endpoint exposed), named listening on 127.0.0.1:53 (used by /etc/resolv.conf) Box 2: named listening on 127.0.0.1:53 (used by /etc/resolv.conf), dnsdist listening on $all_public_ips:53 (used by external clients, relaying to named and iodine as needed), iodine listening on 127.0.0.1:5353 Does gnupg interpret any of these as tor dns endpoints? How does gnupg determine, how to query dns? The additional "debug dns" line didn't change anything noticeably for me, I already have "debug ipc,network,dns", so probably it's redundant? I'd prefer to use tor for retrieving keys (if possible). Is there a possibility to turn off dns resolution via tor, but still do all the rest through tor? getsrv(_openpgpkey._tcp.eckner.net): Verbindung im DNS geschlossen (Yes, I known, GnUPG has two many debug stuff i18n). I wonder, though, why the tried things differ on both machines - both run arch linux with gnupg 2.2.26 and libgcrypt 1.8.7, no gpg.conf. Any proxy, Tor software running. You may try "disable-ipv6" or "disable-ipv4" in your dirmngr.conf. disable-ipv4 / disable-ipv6 does not make any difference (without also adding "no-use-tor", of course) FWIW, "gpgconf --show-versions" gives information on the used libraries, CPU, etc. - From Box #2: - ---8<---8<---8<---8<---8<--- * GnuPG 2.2.27 (000) GNU/Linux * Libgcrypt 1.8.7 () version:1.8.7:10807:1.39-unknown:12700: cc:100200:gcc:10.2.0: ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:chacha20: pubkeys:dsa:elgamal:rsa:ecc: digests:crc:gostr3411-94::md4:md5:rmd160:sha1:sha256:sha512:sha3:tiger:whirlpool:stribog:blake2: rnd-mod:linux: cpu-arch:x86: mpi-asm:amd64/mpih-add1.S:amd64/mpih-sub1.S:amd64/mpih-mul1.S:amd64/mpih-mul2.S:amd64/mpih-mul3.S:amd64/mpih-lshift.S:amd64/mpih-rshift.S: hwflist:intel-cpu:intel-fast-shld:intel-bmi2:intel-ssse3:intel-sse4.1:intel-pclmul:intel-aesni:intel-rdrand:intel-avx:intel-avx2:intel-fast-vpgather:intel-rdtsc: fips-mode:n:n: rng-type:standard:1:201:1: * GpgRT 1.41-unknown (000) * Libassuan 2.5.4 (e368b40) * KSBA 1.4.0 (?) * GNUTLS 3.7.0 - --->8--->8--->8--->8--->8--- I don't see any libdns there. Box #1 only differs in the cpu flags line: - -hwflist:intel-cpu:intel-fast-shld:intel-bmi2:intel-ssse3:intel-sse4.1:intel-pclmul:intel-aesni:intel-rdrand:intel-avx:intel-avx2:intel-fast-vpgather:intel-rdtsc: +hwflist:intel-cpu:intel-fast-shld:intel-ssse3:intel-sse4.1:intel-pclmul:intel-avx:intel-rdtsc: Shalom-Salam, Werner Thank you for your time. Cheers, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAKw/gACgkQCu7JB1Xa e1qPIhAAt/r3BohQnWRd5zdV7DQmfOVEDUbhnoktk5luG/0bPy/zNc5Qr7h2h4Zp aqDM3PsghlCVlqei8S1sM+/FJi+qZzdELMFoFZ/8LCmYORTzee157oBEQXcFvE08 DT0QWeb7QNjEMvof1sKMDbdqSAxh0y+EPm6vsH/CbzRDcvjG7osLgzVNVDf5DDY7 3gUNILnsLCclF3g/u2GEBCVa1j9EaybTgsq3OTya/OVCPbCfoAzJ6FQipwH9Wow1 juUMDM57juX3/YJt5MNPZ50KDI/2E4b83t+YqNobZroZo3o7s/DuIhHiTOHWp4Kf 3BeRMmYzdd4guBsJS3b6pr+PsxXbolECE2g31lWWKck8P+rUxhkZ8kCBVIohx0s4 Ae5bXb4yCA1e/Xh4lIFi61IRcjlLNiPAoVT6hZ0bSDBjsesxdzKgHOmTteUKOLAn sE2QGl4XwN3BhJttOEXZva4GDLPAU9idw/fIljhuvu/dBn3hV6DdOl5HxLpCyVtW dDAaObvwP16TTdO7vYH0dDNC/1CjtUHnk/AeTG1eO3Ji49eJfYn++5L3GEf149Kw voRq82b/X6IGKlm2DVBbEpBUTxU1HyOrPUjC5Kl+hDINxMBmnLl5QIt54fVmhvWP +LEQD9KorvYmEnyj+f7+zbrCL0BOtuKynHRGp4mmCRWOL1cwHkI= =/2O4 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
On Thu, 21 Jan 2021 15:05, Erich Eckner said: > 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: dns: libdns initialized (tor mode) > 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: dns: Your are using Tor for DNS queries, that is the actual DNS server is 8.8.8.8. Tor mode is used if you are running the Tor client or the Tor browser. Put no-use-tor into dirmngr.conf and to get DNS debug messages add "debug dns". > getsrv(_openpgpkey._tcp.eckner.net): Verbindung im DNS geschlossen (Yes, I known, GnUPG has two many debug stuff i18n). > I wonder, though, why the tried things differ on both machines - both run > arch linux with gnupg 2.2.26 and libgcrypt 1.8.7, no gpg.conf. Any proxy, Tor software running. You may try "disable-ipv6" or "disable-ipv4" in your dirmngr.conf. FWIW, "gpgconf --show-versions" gives information on the used libraries, CPU, etc. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 20 Jan 2021, Werner Koch wrote: On Wed, 20 Jan 2021 14:46, Erich Eckner said: is queried. This resolves to some old address (my DNS configuration error), which serves the wrong content. Is it right, that this SRV record should be queried? Should I update it or remove it? Yes, the SRV record is used if there is no openpgpkeys sub-domain. The reason is that the original scheme was to use SRV records but we had to switch to a subdomain due to problems with browser based code. Ah, right, I see the SRV record being queried *after* the openpgpkey.eckner.net query. However, for whatever reason these (and the SRV) queries fail: 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: chan_6 <- WKD_GET -- er...@eckner.net 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: dns: libdns initialized (tor mode) 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: dns: resolve_dns_name(openpgpkey.eckner.net): Verbindung im DNS geschlossen 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: dns: libdns initialized (tor mode) 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: dns: getsrv(_openpgpkey._tcp.eckner.net): Verbindung im DNS geschlossen 2021-01-21 14:41:32 dirmngr[3623955.6] command 'WKD_GET' failed: Verbindung im DNS geschlossen 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: chan_6 -> ERR 167772876 Verbindung im DNS geschlossen 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: chan_6 <- BYE 2021-01-21 14:41:32 dirmngr[3623955.6] DBG: chan_6 -> OK closing connection 2021-01-21 14:41:32 dirmngr[3623955.6] Handhabungsroutine für den fd 6 beendet the other box shows different errors at the same positions: 2021-01-21 14:47:09 dirmngr[1904072.6] DBG: chan_6 <- WKD_GET -- er...@eckner.net 2021-01-21 14:47:09 dirmngr[1904072.6] DBG: dns: resolve_dns_name(openpgpkey.eckner.net): Permission denied 2021-01-21 14:47:09 dirmngr[1904072.6] DBG: dns: getsrv(_openpgpkey._tcp.eckner.net): Permission denied 2021-01-21 14:47:09 dirmngr[1904072.6] command 'WKD_GET' failed: Permission denied 2021-01-21 14:47:09 dirmngr[1904072.6] DBG: chan_6 -> ERR 167804929 Permission denied I wonder, though, why the tried things differ on both machines - both run arch linux with gnupg 2.2.26 and libgcrypt 1.8.7, no gpg.conf. What should I do to dig further into this? I assume, this is for debugging *a lot* of gnupg in one place (like your Right. It is also cool to watch the diagnostccs fly by during regular use ;-) I played around with the socket:// log "file", and I must say, the nice thing is, that you can keep this in your dirmngr.conf without creating endless logs - only when the listening command is started, the socket is created and actual logs will be generated :-) Salam-Shalom, Werner regards, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAJikIACgkQCu7JB1Xa e1q30g/8DbT9NA95gxe3NXEN54oj5Cge1dxqGbuqhg2tQv4Pex5hMNv8YSVE8kMM g0npzK24d5fszFEhOJlfQ+7HGzFb39hPjVVv48RsHjVPw2pGz1e4/K5p4AkqRjde H7D/CghEGPVdIjM52VI9oJRMCFly2iKPZsurNrJhqfbtzAMCSmTv/gUotO9mA23b 1wvlcBryrt8d/Hu653x+Rx0oCygDHj7etzONH5tMFunw7oJiLoonWB65w18aC3yQ qMKyIBEtUJkskH25SJeY8ZUr8h1CTsXAvovqjhgfvOMV+1p9wnj234o/c8m33uUQ si0sSbP6xtc6BcEy2XuVWrpw9lKZYVsRDdAODnXqKCLeIdb7K57P+2EV2Azc80BP Wy1m9qzgGPLK5A6RxDoQD9jSisTDm4okiDM4ZvK5v+0k2NWqy+7hnsoF2Pohe5zE RBlumaSmE6jiw2QaLuUscUFJB/QgxOnh1PpdU7SoMMh6Vmb7Rt7Eau63iZxmJWym lSY+OUCLlWTdDipV8OU86ZI0uzHJo1JJGDkijR2hlJblLI6bOyc1oC2L42R49dbe jLoFUxoK7K6VDOXVcK8spIcmhrJERudg1U96ArP3G2o9S9bg+n4C2B7hTo2wm3Ml zcdk8Zt3PB6G7wmc41bvtd5LDcbLFXvr1/KxT+JLyWy0tJW0RXU= =GAHG -END PGP SIGNATURE-___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
On Wed, 20 Jan 2021 14:46, Erich Eckner said: > is queried. This resolves to some old address (my DNS configuration > error), which serves the wrong content. Is it right, that this SRV record > should be queried? Should I update it or remove it? Yes, the SRV record is used if there is no openpgpkeys sub-domain. The reason is that the original scheme was to use SRV records but we had to switch to a subdomain due to problems with browser based code. > I assume, this is for debugging *a lot* of gnupg in one place (like your Right. It is also cool to watch the diagnostccs fly by during regular use ;-) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 20 Jan 2021, Werner Koch wrote: On Tue, 19 Jan 2021 17:24, Erich Eckner said: error in the subject when doing `gpg - --locate-external-keys Many -v don't really help here because the actual task is done by the dirmngr process. Thus to debug this put log-file /somewhere/dirmngr.log verbose debug ipc,network,dns into ~/.gnupg/dirmngr.conf and "gpgconf --kill dirmngr". The log file should give you a pretty good insight what's going on. Thank you. I'm always confused by the different parts involved and how to properly increase verbosity :-) - From the log, I see, that _openpgpkey._tcp.eckner.net SRV is queried. This resolves to some old address (my DNS configuration error), which serves the wrong content. Is it right, that this SRV record should be queried? Should I update it or remove it? You may also use log-file socket:// and run in another tty watchgnupg --time-only --force or with older version of gnupg watchgnupg --time-only --force $(gpgconf --list-dirs socketdir)/S.log I assume, this is for debugging *a lot* of gnupg in one place (like your work station, Werner). I'm totally happy with (temporarily) dumping log files in /tmp :-D If we can identify common error patterns in the diagnostics we can convey them to the gpg process to make debugging easier. Ok, I understand. Salam-Shalom, Werner Thank you for your help! Cheers, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAINCAACgkQCu7JB1Xa e1q3sQ/9EuJaERLiHdOqCYEXaqUu+O1Q7Tm7h6h9DLHLHykcJGs+XOK39XStmzTI 1XhHp5CRZJ+f88Dd98eJPSGcGCvnLauHBfyVJwq33TzgQQXzh3D88kpr9RrZjvc1 wLRiaQ3Mx4Jzk26Fmh56qrweQFGOq/RdXzvN45QatM4fSB6hdfB2+sV+RYU6yvpi ABqfFk/RHCnEZGDwI0Du2k6yfbIASgPJozJpVFLsiEv9OmK6IHibyQCOjcjSCBDs RvhRFeS2XrEfpktq+FPYRDuc5t6nnmbvTTk2agdoDaxnmr+LxBZJRSOG3NzcdzXJ Ikg3jOp9KU+Oq9cSijt8E/9wRYT/ukrzehH2j+fEqH62ypqtAU6dtTcX+6tKpZct QxYMxr/A+ovq/H68szfoC4WAZkX7baqj3IF53O8z6XZ4qv5611OA4DN7Tb9B8G97 QuZXu+30pbvrNigyLO/8RsX3KttFfB02md8DF/0NNGT91Ua2iYm1cu650Zl2dtkW TehKWvT6627+1FAL4WrQx5GAPetfiP34pyIXSUZyNhzozLCNAjeXh3RhNoMLgFI+ 5rTh0lwNYf/BqS35QOvHbE7pWR/c7OnzKyOsMDO8AdIPNz7WAXV+HTa9QXa8zrfj 4j7UQETYC9Df4FdLn4LCOpIlD3GuWfkMgvZ3q0lQqHzP4v9AfIU= =CIVf -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
On Tue, 19 Jan 2021 17:24, Erich Eckner said: > error in the subject when doing `gpg - --locate-external-keys Many -v don't really help here because the actual task is done by the dirmngr process. Thus to debug this put log-file /somewhere/dirmngr.log verbose debug ipc,network,dns into ~/.gnupg/dirmngr.conf and "gpgconf --kill dirmngr". The log file should give you a pretty good insight what's going on. You may also use log-file socket:// and run in another tty watchgnupg --time-only --force or with older version of gnupg watchgnupg --time-only --force $(gpgconf --list-dirs socketdir)/S.log If we can identify common error patterns in the diagnostics we can convey them to the gpg process to make debugging easier. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
On 2021-01-19 at 17:24 +0100, Erich Eckner via Gnupg-users wrote: > What can cause a "Connection closed in DNS" error? (Maybe the error > message can be improved: Doesn't dns use udp by default, which is > connectionless?) I think it means dns.c returned DNS_ECONNFIN [1], which gets converted to GPG_ERR_DNS_CLOSED in dns-stuff.c and is then libgpg-error describes as "Connection closed in DNS" I'm not sure if this error can happen when using UDP, but do note that you can also (and in some cases must) perform DNS queries using tcp. Best regards 1- https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=dirmngr/dns.c;h=3ac6a2d021288bf4124745b6e9567e665e09fe49;hb=93d5d7ea2a8b110b3ad88be25f2f67d706361e44#l360 2- https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=dirmngr/dns-stuff.c;h=cdda86d63086184bf09e8dce7d946989a61d14d0;hb=93d5d7ea2a8b110b3ad88be25f2f67d706361e44#l394 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
On Tue, Jan 19, 2021 at 11:01 PM Erich Eckner via Gnupg-users wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > I checked the manual, and there is even a non-permanent solution: > > - --export-filter keep-uid="mbox = ..." > > lets you filter the exported uids :-) Cool :-) , I did not know this. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 19 Jan 2021, Stefan Claas wrote: On Tue, Jan 19, 2021 at 6:28 PM Stefan Claas wrote: On Tue, Jan 19, 2021 at 6:26 PM Erich Eckner via Gnupg-users wrote: Advanced method is set up, direct method is not. The key has multiple UIDs (one for each of my email addresses). Or did I do something wrong when exporting the key to the WKD? Should I have removed the other UIDs there? (how?) Hi Erich, No, not wrong, but then WKD users would know your other email addresses as well, I would say. In case you like to avoid that I would check GnuPG for editing the key, e.g. removing the unwanted UIDs and then save and then export for WKD. gpg [Optionen] --edit-key user-id [commands] I checked the manual, and there is even a non-permanent solution: - --export-filter keep-uid="mbox = ..." lets you filter the exported uids :-) Regards Stefan regards, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAHLfEACgkQCu7JB1Xa e1rmjBAAvqUdx+hoqtg3lDWPUqQE69QtmmUgnxBSXPo4VJbFLQKccsog270mzJXh ccGbqYLHHpj5X0BfFWcIn/7UII7QRfscp8/lvt+IM7I5pHvGpGky21jrMgVhm6h7 VrnioKV97MgHZcFG1ihCOLI5txVL81efSulaS9akUkhB096nJy6j8G05L1ZUlLkJ q/ZwXaqdBH2aG9moHh0zCC0a7081FfwmBf120c9ZH9MmBHM47TPqDauI2/ECgi52 wB7LzaGPyvbQngGrxsD3aUTftOE+dq7XChp4kuiuIA4o5+rmJ/0umwdm8IBr324R mW9Cs/iSJcVA/XXuAIWSe5uFLgg2ZrqdeMA2HHQF90ElxnRsCeKYs9Bq3HIBqqEn zJ3DR5J87uUgsgLxEZfStCSVMz0nC5jpcP2Ycyv0qKpZ8zu15wBYl0GuUZ7SLQS8 Db21TerHsDr2RFvLj3K/YfVIIRxFJD7hZtP3hGW0+cuqQcyAGtbHbJm9Id5h0G2f 5EvpJGn4d6b6w2nsGGP5hQOQ99WYTnJGpjiUvQvOd+f06IQ76BgIZdMIlwENFlSt nY6du0KZKMHhiUOp5+nBFRIzqWpoI4NGvZAnHR16ClJVKNymIdMm6R/SsYlM5XHt rv6LtEotIF4b72pMhwAgckEOcAl2NM4UTLIOeWa5ZME03oKMypc= =g12g -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
On Tue, Jan 19, 2021 at 6:28 PM Stefan Claas wrote: > > On Tue, Jan 19, 2021 at 6:26 PM Erich Eckner via Gnupg-users > wrote: > > > Advanced method is set up, direct method is not. The key has multiple UIDs > > (one for each of my email addresses). Or did I do something wrong when > > exporting the key to the WKD? Should I have removed the other UIDs there? > > (how?) > > Hi Erich, > > No, not wrong, but then WKD users would know your other email addresses > as well, I would say. In case you like to avoid that I would check GnuPG for > editing the key, e.g. removing the unwanted UIDs and then save and then > export for WKD. gpg [Optionen] --edit-key user-id [commands] Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
On Tue, Jan 19, 2021 at 6:26 PM Erich Eckner via Gnupg-users wrote: > Advanced method is set up, direct method is not. The key has multiple UIDs > (one for each of my email addresses). Or did I do something wrong when > exporting the key to the WKD? Should I have removed the other UIDs there? > (how?) Hi Erich, No, not wrong, but then WKD users would know your other email addresses as well, I would say. In case you like to avoid that I would check GnuPG for editing the key, e.g. removing the unwanted UIDs and then save and then export for WKD. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Stefan, thanks for your answer. On Tue, 19 Jan 2021, Stefan Claas wrote: On Tue, Jan 19, 2021 at 5:24 PM Erich Eckner via Gnupg-users wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I'm playing around with my WKD setup (guess, why) and encountered the error in the subject when doing `gpg - --locate-external-keys er...@eckner.net`. Retrieving via curl and the manually-constructed url works fine, also I cannot find any problems in dns on that box. A second box shows the same behaviour, but on a third machine, it works. All three run the latest arch linux :-/ What can cause a "Connection closed in DNS" error? (Maybe the error message can be improved: Doesn't dns use udp by default, which is connectionless?) I did a quick check and according to Wiktor's WKD checker the direct-method says that key is missing and the advanced method seems to be ok. sq.exe can fetch your key and when I do a gpg --locate-keys er...@eckner.net it fetches also a couple of others from you (with differrent email addresses , which I must admit I do not understand why and would probably not need when communicating with you. Yes, this is the proper behaviour (which I also see on one machine of the three mentioned machines): Advanced method is set up, direct method is not. The key has multiple UIDs (one for each of my email addresses). Or did I do something wrong when exporting the key to the WKD? Should I have removed the other UIDs there? (how?) However, on two machines, I only get this strange "Connection closed in DNS" error. Ah, wait, I checked again, and one box says: "gpg: error retrieving 'er...@eckner.net' via WKD: Permission denied" Something is oddly wrong :-/ Regards Stefan regards, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAHFXgACgkQCu7JB1Xa e1rSvBAAttQc553QJAWAsjmSMEDAYp21pOiRLGcPEGInkhcF2DvQaLpW2Y4WQZR+ Xj+m8hOf3IbYPHs7k07Xqu35oD0KrXh//lPkZ0kben/EkY2TMzMjuwvZhW9KN9do QMiZJ8DfEiD2E88EliwqTDZoLsjpjtZLEfMjd0Cp/nk2r1LqPmLzYCDvjh2kxhyt 1W16B/xsnB9ITsb3odDcuGxRA4dPuWwuX9z1qIiInXqBFP39P4W/6Fi3aKPm1aOq Dir0uygAWDKytV7XNZlFsKqGc4ndOmj398LWHS0dSIg/EYOOS4O8ja/SGiacNKu+ l26DkWiECZk7FQDvKZuzCZbxbdSIej8fPa1m4adTCB0nR9XZCimg0EZHKlzfK/7A 88IPNq1UuMsTDimimROh0wR8ZZFRLFkEdMf/IB5pGE9nfOFhOc0sXIsmnO60ZoJa pmstR0mjuicDd0bsPHl3QDx9zTjqz5448MOCGfelBgfbxWVB4TmSKQxLqoqTmVyB 1z+fuDq+IjUzHt3RyjwebMOMZlwRuZjEvdwOFwz/+NdjqEHpX6z4sWpRlrZmyq7w vIL4lrdBUuOqCxZmkIbMZMVQOu+ZMoRzA44cvMZAIMhYoTvmL5NjzL6LWlMv0jRo pSk+QMFMnxoVFr/8ntlJN+vSjVuTHVgSUXrb1YltsWLfR2Uy4wg= =YNH1 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
On Tue, Jan 19, 2021 at 5:24 PM Erich Eckner via Gnupg-users wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi, > > I'm playing around with my WKD setup (guess, why) and encountered the > error in the subject when doing `gpg - --locate-external-keys > er...@eckner.net`. Retrieving via curl and the manually-constructed url > works fine, also I cannot find any problems in dns on that box. A second > box shows the same behaviour, but on a third machine, it works. All three > run the latest arch linux :-/ > > What can cause a "Connection closed in DNS" error? (Maybe the error > message can be improved: Doesn't dns use udp by default, which is > connectionless?) I did a quick check and according to Wiktor's WKD checker the direct-method says that key is missing and the advanced method seems to be ok. sq.exe can fetch your key and when I do a gpg --locate-keys er...@eckner.net it fetches also a couple of others from you (with differrent email addresses , which I must admit I do not understand why and would probably not need when communicating with you. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I'm playing around with my WKD setup (guess, why) and encountered the error in the subject when doing `gpg - --locate-external-keys er...@eckner.net`. Retrieving via curl and the manually-constructed url works fine, also I cannot find any problems in dns on that box. A second box shows the same behaviour, but on a third machine, it works. All three run the latest arch linux :-/ What can cause a "Connection closed in DNS" error? (Maybe the error message can be improved: Doesn't dns use udp by default, which is connectionless?) Cheers, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAHB6QACgkQCu7JB1Xa e1o5EBAAlwWivpw2CYX+FgWfFOqCVEy26uHpX6vbcUjG5F5hM54pxs7OUw+iFvOr i9lAWpIaFFpE9zE98U02caycNmrV6JvazrXb/NvmIxiAwVTbXGjoJxWF1+GzMow5 xhaUeeac+TzYDEC+4XdB1crWmWbe1EHbXuWzq6UGjCisaTKEqRk7Wtvj+XeeVbrH hjEHLySG53s5BmC8WlAzM7h+AeY6q6asmnMDPxtYSUAvErDsjtT/9X+UsVHp+Qrg JSfrLriVHEmTmJBpCsil/B7PIaOV4BhBy4+1qCWrytE/DZav+nz97TI+z6ZP40LC RCxEK1SHbSGNDrOoIzv8WddMRM3wpjlU1lDPlecgykKCWsu0X/Js64mpq1Ext6RV vEF94I399odyb2qJOv1icg8l7770BJyjqvgcIBV3QBPEKkSVpHCN3Pi8m2rO1Ahc hTHsBAeyDM4uqWHjfK+8UWxXe1464u6vyQ3SseWDqdFPVHXS4IkmUfEV9MUpAr0y UOfPEWID4Awmp/ZMs2pad4GSYhhY/Mqzy1WN3DAHs3O5WtZ9gTwHYnJOT8e3DE/V i3gRUmUBjCNIByq2cCTc764TK7B6q+J1No5euLy4QYqH/ZeHTqBEm35wqdae6SQs VorbRIhlXTHpMvR8vvr1xG2gnV2uA4s/3lOsaxv/5HLOFWpIyMY= =6cGU -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users