Mailing List Archive

On Tue, Jan 19, 2021 at 5:24 PM Erich Eckner via Gnupg-users
<gnupg-users@gnupg.org> 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 -vvvv --locate-external-keys
> erich@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 erich@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

-----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
> <gnupg-users@gnupg.org> 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 -vvvv --locate-external-keys
>> erich@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 erich@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 'erich@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

On Tue, Jan 19, 2021 at 6:26 PM Erich Eckner via Gnupg-users
<gnupg-users@gnupg.org> 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

On Tue, Jan 19, 2021 at 6:28 PM Stefan Claas
<spam.trap.mailing.lists@gmail.com> wrote:
>
> On Tue, Jan 19, 2021 at 6:26 PM Erich Eckner via Gnupg-users
> <gnupg-users@gnupg.org> 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

-----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
> <spam.trap.mailing.lists@gmail.com> wrote:
>>
>> On Tue, Jan 19, 2021 at 6:26 PM Erich Eckner via Gnupg-users
>> <gnupg-users@gnupg.org> 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

On Tue, Jan 19, 2021 at 11:01 PM Erich Eckner via Gnupg-users
<gnupg-users@gnupg.org> 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

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

On Tue, 19 Jan 2021 17:24, Erich Eckner said:

> error in the subject when doing `gpg -vvvv --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.

-----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 -vvvv --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

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.

-----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 -- erich@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 <Dirmngr>
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 -- erich@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 <Dirmngr>

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-----

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.

-----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 (0000000)
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:2010000:1:

* GpgRT 1.41-unknown (0000000)

* 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

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 (0000000)

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!

-----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 difference in particular on my Windows VM.

I agree: Switching between ip versions is always worth a trial
(especially, since my ipv6 @home is actually a 6in4 routed through ukraine
- - and thus also probably russia and the KGB ;-p)

>
>
>> 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 (0000000)
>
> 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!
>

regards,
Erich

P.S.: I liked the old signature better. (Nothing against political
statements, but it was more witty)

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmALBfMACgkQCu7JB1Xa
e1ok2w/9FsoldOMnbIoyR8vvwe0YknX2js//R/UDGuWM3POg67ua/hAtSBniXEPv
Lm16zhkICUOsw2Ij8IvpMfOPE5TFfgKfP89V+6Obd9SesaoezhNKXKcO58kWdHal
lt3xFlitTxC7AQT+IHeDr4hvtju5Mv/075bpDeF2LvWRyt9HJ/u+zvqFUnudsunE
PKzy03bn4jgtGUWxIkWOgTkBC2SvveOyDemLJRTMUq4gLMX6P+nLV0H8sjc9+uKs
/VjWDiybvZzSgIg6yZ7MHwEgdAq38rbL3rdWOWTdIMVf6KfitV0WMHsp4X2mcbFb
jUdAAseak5cSNgK/3P3g/pFROYval1nmaIpQNYByYgfk/Cfb57TLWHLcB28PTpWa
8lUVw9KB2xk41jBnjHIfQf56hiKmwTS5x17EK3meOWgoDZdutadFpUJuyyHX6VIc
ZR5HKNeOLTrKKNhglttvtQNCnQHMRRPPOUqDWwvfLGqxgAh/yVcZHta8rj7/cHY/
pUZ4Vmk6BzOrq9LjLZA8oahdMuHRiAGVv0EFt4U77KjvrIVqITQXsEFItua4v9O0
Ya8BnGswY+HgXZLHuntqnsS/PBnqRApaJJ4h4RGqP5UTQFoeY2G0wZ34NLul65AN
DPiWQc0CEGlOmtnZ6a2Vn2NNMRBfsCG1qeP1SdU5qq4l4kabO/Y=
=manV
-----END PGP SIGNATURE-----

-----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

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

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.

-----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-----

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