Bug#849845: [pkg-gnupg-maint] Bug#849845: dirmngr: Can't resolve keyserver hostname anymore

2017-01-06 Thread Jaden Peterson
On Thu, 05 Jan 2017 16:56:40 -0500 Daniel Kahn Gillmor 
 wrote:

> Control: fowarded 849845 https://bugs.gnupg.org/gnupg/issue2902
>
> On Thu 2017-01-05 08:15:06 -0500, intrigeri wrote:
> > Daniel Kahn Gillmor:
> >> The remaining problem for me ws that when i use tor, if i get 
back 
> >> records, the connections fail, but the IPv6 records are not 
marked as

> >> dead, so they fail repeatedly.
> >
> > Same here, with a package built from commit
> > 32bae0c609cb0c6180e9405a3d6a8fb3c0dec20e in the Vcs-Git (which by 
the

> > way fixes the other problem I've reported here :)
>
> thanks for the reportback!  I've reported the remaining issue 
upstream

> (see the url above).  I'll do an upload to unstable with the
> intermediate fix later today, unless i can sort out a fix for the 
whole

> issue first.
>
>  --dkg

Hi,

I have no place in the topic of this bug, but I installed the patches 
you provided on January 5th onto my Debian Testing system. I would like 
to notify you that gpgv2 depends on gpgv version 2.1.17-3 or greater, 
which is not provided, and results in mixed versions.






Bug#849845: [pkg-gnupg-maint] Bug#849845: dirmngr: Can't resolve keyserver hostname anymore

2017-01-06 Thread Daniel Kahn Gillmor
Control: fowarded 849845 https://bugs.gnupg.org/gnupg/issue2902

On Thu 2017-01-05 08:15:06 -0500, intrigeri wrote:
> Daniel Kahn Gillmor:
>> The remaining problem for me ws that when i use tor, if i get back 
>> records, the connections fail, but the IPv6 records are not marked as
>> dead, so they fail repeatedly.
>
> Same here, with a package built from commit
> 32bae0c609cb0c6180e9405a3d6a8fb3c0dec20e in the Vcs-Git (which by the
> way fixes the other problem I've reported here :)

thanks for the reportback!  I've reported the remaining issue upstream
(see the url above).  I'll do an upload to unstable with the
intermediate fix later today, unless i can sort out a fix for the whole
issue first.

 --dkg


signature.asc
Description: PGP signature


Bug#849845: [pkg-gnupg-maint] Bug#849845: dirmngr: Can't resolve keyserver hostname anymore

2017-01-05 Thread intrigeri
Hi,

Daniel Kahn Gillmor:
> The remaining problem for me ws that when i use tor, if i get back 
> records, the connections fail, but the IPv6 records are not marked as
> dead, so they fail repeatedly.

Same here, with a package built from commit
32bae0c609cb0c6180e9405a3d6a8fb3c0dec20e in the Vcs-Git (which by the
way fixes the other problem I've reported here :)

Cheers,
-- 
intrigeri



Bug#849845: [pkg-gnupg-maint] Bug#849845: dirmngr: Can't resolve keyserver hostname anymore

2017-01-04 Thread Daniel Kahn Gillmor
On Wed 2017-01-04 09:27:16 -0500, intrigeri wrote:
> Daniel Kahn Gillmor:
>> I've been able to replicate the problems described by intrigeri in
>> https://bugs.debian.org/849845; i'm preparing an update to gpg with
>> cherry-picked patches that resolves most of them for me.
>
> I'd be happy to test these changes before you upload. If you wish,
> push them to the packaging Vcs-Git (in a dedicated branch if you
> prefer) and I'll build & try it :)

Thanks, intrigeri!  I've pushed 32bae0c609cb0c6180e9405a3d6a8fb3c0dec20e
to Vcs-Git master branch.  Please let me know how it goes for you.

   --dkg


signature.asc
Description: PGP signature


Bug#849845: [pkg-gnupg-maint] Bug#849845: dirmngr: Can't resolve keyserver hostname anymore

2017-01-04 Thread intrigeri
Daniel Kahn Gillmor:
> I've been able to replicate the problems described by intrigeri in
> https://bugs.debian.org/849845; i'm preparing an update to gpg with
> cherry-picked patches that resolves most of them for me.

I'd be happy to test these changes before you upload. If you wish,
push them to the packaging Vcs-Git (in a dedicated branch if you
prefer) and I'll build & try it :)



Bug#849845: [pkg-gnupg-maint] Bug#849845: dirmngr: Can't resolve keyserver hostname anymore

2017-01-04 Thread Daniel Kahn Gillmor
Control: severity 849845 grave

Hi all--

I've been able to replicate the problems described by intrigeri in
https://bugs.debian.org/849845; i'm preparing an update to gpg with
cherry-picked patches that resolves most of them for me.  This issue is
bad enough that it basically makes dirmngr unusable, afaict.

The remaining problem for me ws that when i use tor, if i get back 
records, the connections fail, but the IPv6 records are not marked as
dead, so they fail repeatedly.

here's an example:


Jan 03 15:48:37 alice dirmngr[11194]: DBG: chan_5 <- KS_GET -- 
0x4FA73DE89ADE75998AC24E97B8C1D523FE7AAA84
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '[2a02:898:31:0:48:4558:73:6b73]'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '[2a00:14b0:4200:3000:27::27]'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '[2606:1c00:2802::b]'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '[2001:bc8:4700:2300::10:f15]'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '[2001:738:0:600:216:3eff:fe02:42]'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '[2001:720:418:caf1::8]'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '[2001:610:1108:5011::70]'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '[2001:470:1:116::6]'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '216.66.15.2'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '212.12.48.27'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '193.224.163.43'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '192.94.109.73'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '131.155.141.70'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '130.206.1.8'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '94.142.242.225'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '51.15.53.138'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '37.191.238.78'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '18.9.60.141'
Jan 03 15:48:42 alice dirmngr[11194]: DBG: gnutls:L3: ASSERT: 
mpi.c[_gnutls_x509_read_uint]:246
Jan 03 15:48:42 alice dirmngr[11194]: DBG: gnutls:L5: REC[0x7f6d240086b0]: 
Allocating epoch #0
Jan 03 15:48:42 alice dirmngr[11194]: can't connect to 
'2a02:898:31:0:48:4558:73:6b73': Invalid argument
Jan 03 15:48:42 alice dirmngr[11194]: error connecting to 
'https://[2a02:898:31:0:48:4558:73:6b73]:443': Invalid argument
Jan 03 15:48:42 alice dirmngr[11194]: DBG: gnutls:L5: REC[0x7f6d240086b0]: 
Start of epoch cleanup
Jan 03 15:48:42 alice dirmngr[11194]: DBG: gnutls:L5: REC[0x7f6d240086b0]: End 
of epoch cleanup
Jan 03 15:48:42 alice dirmngr[11194]: DBG: gnutls:L5: REC[0x7f6d240086b0]: 
Epoch #0 freed
Jan 03 15:48:42 alice dirmngr[11194]: command 'KS_GET' failed: Invalid argument
Jan 03 15:48:42 alice dirmngr[11194]: DBG: chan_5 -> ERR 167804976 Invalid 
argument 
Jan 03 15:48:42 alice dirmngr[11194]: DBG: chan_5 <- BYE
Jan 03 15:48:42 alice dirmngr[11194]: DBG: chan_5 -> OK closing connection
Jan 03 15:48:42 alice dirmngr[11194]: handler for fd 5 terminated
Jan 03 15:49:11 alice dirmngr[11194]: handler for fd 5 started
Jan 03 15:49:11 alice dirmngr[11194]: DBG: chan_5 -> # Home: /home/dkg/.gnupg
Jan 03 15:49:11 alice dirmngr[11194]: DBG: chan_5 -> # Config: 
/home/dkg/.gnupg/dirmngr.conf
Jan 03 15:49:11 alice dirmngr[11194]: DBG: chan_5 -> OK Dirmngr 2.1.17 at your 
service
Jan 03 15:49:11 alice dirmngr[11194]: connection from process 11200 (1000:1000)
Jan 03 15:49:11 alice dirmngr[11194]: DBG: chan_5 <- GETINFO version
Jan 03 15:49:11 alice dirmngr[11194]: DBG: chan_5 -> D 2.1.17
Jan 03 15:49:11 alice dirmngr[11194]: DBG: chan_5 -> OK
Jan 03 15:49:11 alice dirmngr[11194]: DBG: chan_5 <- KS_GET -- 
0x4FA73DE89ADE75998AC24E97B8C1D523FE7AAA84
Jan 03 15:49:11 alice dirmngr[11194]: DBG: gnutls:L3: ASSERT: 
mpi.c[_gnutls_x509_read_uint]:246
Jan 03 15:49:11 alice dirmngr[11194]: DBG: gnutls:L5: REC[0x7f6d2400c090]: 
Allocating epoch #0
Jan 03 15:49:11 alice dirmngr[11194]: can't connect to 
'2a02:898:31:0:48:4558:73:6b73': Invalid argument
Jan 03 15:49:11 alice dirmngr[11194]: error connecting to 
'https://[2a02:898:31:0:48:4558:73:6b73]:443': Invalid argument
Jan 03 15:49:11 alice dirmngr[11194]: DBG: gnutls:L5: REC[0x7f6d2400c090]: 
Start of epoch cleanup
Jan 03 15:49:11 alice dirmngr[11194]: DBG: gnutls:L5: 

Bug#849845: [pkg-gnupg-maint] Bug#849845: dirmngr: Can't resolve keyserver hostname anymore

2017-01-02 Thread intrigeri
Hi Werner!

Werner Koch:
> The attached patch fixes this problem.  

Thanks for caring! I've tried rebuilding the package currently in sid
with this patch applied, but it doesn't seem to be enough.

The first --recv-keys triggers:

  Jan 02 13:36:33 dirmngr[8281]: DBG: dns: 
getsrv(_hkp._tcp.hkps.pool.sks-keyservers.net): Server indicated a failure
  Jan 02 13:36:33 dirmngr[8281]: command 'KS_GET' failed: Server indicated a 
failure 
  Jan 02 13:36:33 dirmngr[8281]: DBG: chan_5 -> ERR 219 Server indicated a 
failure 

... which is expected if querying 127.0.0.1, that doesn't support
SRV records.

And the next attempts, after manually telling dirmngr that my
keyserver is alive:

  Jan 02 13:37:56 dirmngr[8281]: connection from process 8506 (1002:1002)
  Jan 02 13:37:56 dirmngr[8281]: DBG: chan_5 <- GETINFO version
  Jan 02 13:37:56 dirmngr[8281]: DBG: chan_5 -> D 2.1.17
  Jan 02 13:37:56 dirmngr[8281]: DBG: chan_5 -> OK
  Jan 02 13:37:56 dirmngr[8281]: DBG: chan_5 <- KEYSERVER --clear 
hkps://hkps.pool.sks-keyservers.net
  Jan 02 13:37:56 dirmngr[8281]: DBG: chan_5 -> OK
  Jan 02 13:37:56 dirmngr[8281]: DBG: chan_5 <- KS_GET -- 
0x7C84A74CFB12BC439E81BA78C92949B8A63BB098
  Jan 02 13:37:57 dirmngr[8281]: DBG: dns: 
resolve_dns_name(hkps.pool.sks-keyservers.net): Success
  Jan 02 13:37:57 dirmngr[8281]: can't connect to 
'hkps.pool.sks-keyservers.net': no IP address for host
  Jan 02 13:37:57 dirmngr[8281]: error connecting to 
'https://hkps.pool.sks-keyservers.net:443': Unknown host
  Jan 02 13:37:57 dirmngr[8281]: marking host 'hkps.pool.sks-keyservers.net' as 
dead


strace still seems to indicate that resolv.conf is read, and then
127.0.0.1 is queried.

Cheers,
-- 
intrigeri



Bug#849845: [pkg-gnupg-maint] Bug#849845: dirmngr: Can't resolve keyserver hostname anymore

2017-01-02 Thread Werner Koch
Hi!

The attached patch fixes this problem.  


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
From b200e636ab20d2aa93d9f71f3789db5a04af0a56 Mon Sep 17 00:00:00 2001
From: Werner Koch 
Date: Mon, 2 Jan 2017 10:00:33 +0100
Subject: [PATCH] dirmngr: Strip root zone suffix from libdns cname results.

* dirmngr/dns-stuff.c (resolve_name_libdns): Strip trailing dot.
(get_dns_cname_libdns): Ditto.
--

Signed-off-by: Werner Koch 
---
 dirmngr/dns-stuff.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/dirmngr/dns-stuff.c b/dirmngr/dns-stuff.c
index a31b073..f2e1df9 100644
--- a/dirmngr/dns-stuff.c
+++ b/dirmngr/dns-stuff.c
@@ -732,6 +732,10 @@ resolve_name_libdns (const char *name, unsigned short port,
   err = gpg_error_from_syserror ();
   goto leave;
 }
+  /* Libdns appends the root zone part which is problematic
+   * for most other functions - strip it.  */
+  if (**r_canonname && (*r_canonname)[strlen (*r_canonname)-1] == '.')
+(*r_canonname)[strlen (*r_canonname)-1] = 0;
 }
 
   dai = xtrymalloc (sizeof *dai + ent->ai_addrlen -1);
@@ -1899,6 +1903,13 @@ get_dns_cname_libdns (const char *name, char **r_cname)
   *r_cname = xtrystrdup (cname.host);
   if (!*r_cname)
 err = gpg_error_from_syserror ();
+  else
+{
+  /* Libdns appends the root zone part which is problematic
+   * for most other functions - strip it.  */
+  if (**r_cname && (*r_cname)[strlen (*r_cname)-1] == '.')
+(*r_cname)[strlen (*r_cname)-1] = 0;
+}
 
  leave:
   dns_free (ans);
-- 
2.8.1



pgp9mvglUVpLn.pgp
Description: PGP signature