Re: [Announce] GnuPG 2.2.20 released

[GnuPG - Dev mailing list]

On 2020-03-20 at 17:51 +0100, Werner Koch via Gnupg-devel wrote:
> We are pleased to announce the availability of a new GnuPG release:
> version 2.2.20.

There appears to be a regression in handling keyserver directives, in
~/.gnupg/gpg.conf or on the command-line.

    % gpg --recv-key $my_key
    gpg: keyserver receive failed: Invalid URI

As near as I can determine, anything hkps: triggers this, as does
`keys.openpgp.org`, but if I can find another functioning non-HKPS HKP
keyserver, then I can use that.

For `keys.openpgp.org`, `hkp://`, `hkps://`, or bare hostname, all
trigger this.

I haven't yet found a common trigger to isolate this, unless it's
existence of MX records in DNS, which seems unlikely.

-Phil

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[GnuPG - Dev mailing list]

On Sun 2020-03-22 19:10:46 -0400, Phil Pennock via Gnupg-devel wrote:
> On 2020-03-20 at 17:51 +0100, Werner Koch via Gnupg-devel wrote:
>> We are pleased to announce the availability of a new GnuPG release:
>> version 2.2.20.
>
> There appears to be a regression in handling keyserver directives, in
> ~/.gnupg/gpg.conf or on the command-line.
>
>     % gpg --recv-key $my_key
>     gpg: keyserver receive failed: Invalid URI

I've just built and tested and uploaded 2.2.20 for debian, and i'm not
seeing this particular failure here.

> As near as I can determine, anything hkps: triggers this, as does
> `keys.openpgp.org`, but if I can find another functioning non-HKPS HKP
> keyserver, then I can use that.
>
> For `keys.openpgp.org`, `hkp://`, `hkps://`, or bare hostname, all
> trigger this.
>
> I haven't yet found a common trigger to isolate this, unless it's
> existence of MX records in DNS, which seems unlikely.

Have you stopped any older already-running instances of dirmngr?

I'd be happy to help debug further, but maybe it would help to post some
logs from dirmngr or something to see what might be going wrong.

     --dkg

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[GnuPG - Dev mailing list]

On 2020-03-23 at 15:29 -0400, Daniel Kahn Gillmor wrote:
> I've just built and tested and uploaded 2.2.20 for debian, and i'm not
> seeing this particular failure here.

Drat.

> Have you stopped any older already-running instances of dirmngr?

Not only that, I'd even rebooted since.

> I'd be happy to help debug further, but maybe it would help to post some
> logs from dirmngr or something to see what might be going wrong.

Sure.  I considered holding off for debugging but I didn't have time
then, so figured it was worth saying something in case it was an easy
fix.  Also: sorry for not changing the mail subject.

The packages are my own builds, these are the version numbers:

    gmp          6.2.0
    gnupg        2.2.20
    gnutls       3.6.12
    libassuan    2.5.3
    libgcrypt    1.8.5
    libgpg-error 1.37
    libksba      1.3.5
    nettle       3.5.1
    npth         1.6
    pinentry     1.1.0

With verbose / debug-all / gnutls-debug 9 :

~~~~~~~~~~~~~~~~~~~~~~~~~~~8< log.dirmngr >8~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2020-03-23 18:11:38 dirmngr[20128.0] permanently loaded certificates: 66
2020-03-23 18:11:38 dirmngr[20128.0]     runtime cached certificates: 0
2020-03-23 18:11:38 dirmngr[20128.0]            trusted certificates: 66 (65,0,0,1)
2020-03-23 18:11:38 dirmngr[20128.6] handler for fd 6 started
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> # Home: /home/pdp/.gnupg
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> # Config: /home/pdp/.gnupg/dirmngr.conf
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> OK Dirmngr 2.2.20 at your service
2020-03-23 18:11:38 dirmngr[20128.6] connection from process 20127 (1000:1000)
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 <- GETINFO version
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> D 2.2.20
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> OK
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 <- KEYSERVER --clear hkps://keys.openpgp.org
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> OK
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 <- KEYSERVER
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> S KEYSERVER hkps://keys.openpgp.org
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> OK
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 <- KS_GET -- 0x4833892924C60A7AE666D32A1DA3E68F41CEECAC
2020-03-23 18:11:38 dirmngr[20128.6] DBG: dns: libdns initialized
2020-03-23 18:11:38 dirmngr[20128.6] DBG: dns: getsrv(_pgpkey-https._tcp.keys.openpgp.org) -> 0 records
2020-03-23 18:11:38 dirmngr[20128.6] DBG: dns: resolve_dns_name(keys.openpgp.org): Success
2020-03-23 18:11:38 dirmngr[20128.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known]
2020-03-23 18:11:38 dirmngr[20128.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known]
2020-03-23 18:11:38 dirmngr[20128.6] command 'KS_GET' failed: Invalid URI
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> ERR 167772207 Invalid URI <Dirmngr>
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 <- BYE
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> OK closing connection
2020-03-23 18:11:38 dirmngr[20128.6] handler for fd 6 terminated
~~~~~~~~~~~~~~~~~~~~~~~~~~~8< log.dirmngr >8~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-Phil

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[GnuPG - Dev mailing list]

Hi!

I just tried with 2.2.21-beta1 (which is identical to 2.2.20) using
both, ntbtls and gnutls and could niot see any problems.  I tried to
specify the keyserver with gpg, dirmngr, ans also with the default.

> getsrv(_pgpkey-https._tcp.keys.openpgp.org) -> 0 records
> 2020-03-23 18:11:38 dirmngr[20128.6] DBG: dns:
> resolve_dns_name(keys.openpgp.org): Success
> 2020-03-23 18:11:38 dirmngr[20128.6] resolve_dns_addr for
> 'keys.openpgp.org': 'keys.openpgp.org' [already known]
> 2020-03-23 18:11:38 dirmngr[20128.6] resolve_dns_addr for
> 'keys.openpgp.org': 'keys.openpgp.org' [already known]
> 2020-03-23 18:11:38 dirmngr[20128.6] command 'KS_GET' failed: Invalid URI

It seems to be a DNS problem with a wrong error code emitted.  Did you
used

  debug dns,network
  verbose

in your dirmngr.conf?


Shalom-Salam,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[GnuPG - Dev mailing list]

On 2020-03-24 at 10:09 +0100, Werner Koch via Gnupg-devel wrote:
> It seems to be a DNS problem with a wrong error code emitted.  Did you
> used
>
>   debug dns,network
>   verbose
>
> in your dirmngr.conf?

I wrote:
} With verbose / debug-all / gnutls-debug 9

That is:

    log-file /home/pdp/.gnupg/log.dirmngr
    verbose
    debug-all
    gnutls-debug 9

Moving aside ~/.gnupg/gpg.conf to use defaults, I get the failure from
the default of `hkps://hkps.pool.sks-keyservers.net`; I see the same for
`hkps://keys.openpgp.org` and `hkp://keys.openpgp.org`.

A bare `--keyserver pool.sks-keyservers.net` works.

I'm using systemd's resolved as the DNS resolver, and do not have IPv6
connectivity at home (sigh).

Compilation environment and configure args:

      "env": [
        "PKG_CONFIG_PATH=#{prefix}/lib/pkgconfig",
        "LDFLAGS=-L#{prefix}/lib -Wl,-R#{prefix}/lib"
      ],
      "params": [
        "--disable-nls",
        "--disable-ldap",
        "--enable-noexecstack",
        "--enable-key-cache=32768",
        "--enable-wks-tools",
        "--with-pinentry-pgm=#{prefix}/bin/pinentry-curses",
        "--with-libgpg-error-prefix=#{prefix}",
        "--with-libassuan-prefix=#{prefix}",
        "--with-libgcrypt-prefix=#{prefix}",
        "--with-ksba-prefix=#{prefix}",
        "--with-npth-prefix=#{prefix}"
      ],

    plus --prefix=/opt/gnupg

My attempts to add more logging seem to have triggered a switch to a
different error code so I'm doing something wrong and can't spend more
time on this now to chase further, sorry.  (I saw the error switch to
"Syntax error in URI" and do_parse_uri() trying to parse a URI from
the 0xFingerprint, not seeing what I changed to cause _that_).

-Phil

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[GnuPG - Dev mailing list]

On Tue, 24 Mar 2020 22:27, Phil Pennock said:

> } With verbose / debug-all / gnutls-debug 9

Just wanted to make sure and also to seed the search engines that using
"debug KEYWORDLIST" (try "help") is a better way to enable debugging.

> I'm using systemd's resolved as the DNS resolver, and do not have IPv6
> connectivity at home (sigh).

I checke the code and it does not seem to be a DNS issue.  also the
chnages related to dirmngr between 2.2.19 and 2.2.20 are minimal and not
related to your problem.

> time on this now to chase further, sorry.  (I saw the error switch to
> "Syntax error in URI" and do_parse_uri() trying to parse a URI from
> the 0xFingerprint, not seeing what I changed to cause _that_).

A candidate for GPG_ERR_INV_URI ("Invalid URI") is:

 - A HTTP proxy using "https:".  We support only "http:", "socks4:", and
   "socks5h".

Candidates for GPG_ERR_BAD_URI ("Syntax error in URI") are:

 - Well, a syntax errors.  Like bad characters, being longer that about
   10000 characters, bad escape sequences, or a binary Nul after
   de-escaping.


Sorry, for not beeing abale to provide more help.  Stepping though the
code would be the fastest way to track it down.


Shalom-Salam,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[GnuPG - Dev mailing list]

On 2020-03-25 at 12:44 +0100, Werner Koch wrote:
> A candidate for GPG_ERR_INV_URI ("Invalid URI") is:
>
>  - A HTTP proxy using "https:".  We support only "http:", "socks4:", and
>    "socks5h".

I revisited this late last night, building with the new libgpg-error.

There's one more scenario which can lead to this error: building without
TLS support.

My build flow is a little too quiet, so I did not get to see the
complaint that GnuTLS support was being disabled, because `nettle.pc`
could not be found in the pkgconfig path.

And that was because on sufficiently new OS releases, the `.pc` files
of nettle (and hogweed) get installed into PREFIX/lib64/pkgconfig/
instead of PREFIX/lib/pkgconfig/.

So with a $PKG_CONFIG_PATH which only included the `lib` form, GnuPG's
configure script missed finding `nettle.pc`, auto-disabled TLS support
without failing the configure, and so when keyservers respond with HTTP
redirects to the `https:` schema, the build GnuPG errors out
cryptically.

I'm half sorry for the noise and half thinking that this highlights a
couple of places for UX improvement.

Thanks for the debugging assistance,
-Phil

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[GnuPG - Dev mailing list]

On Tue,  2 Jun 2020 20:27, Phil Pennock said:

> I'm half sorry for the noise and half thinking that this highlights a
> couple of places for UX improvement.

I see.  One of the problems here is that most installations are using
ntbtls and not gnutls.  Thus this is the major test platform for us and
we don't always test gnutls support.  It might be better for maintenance
if we do not allow to choose between gnutls and ntbtls.  One problem on
Unices is that OpenLDAP uses GnuTLS (or another system provided cryto
lib) so we currently still end up with two complete crypto stacks in
dirmngr.


Shalom-Salam,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel