Bug#834098: libc6: name resolution fails for keys.gnupg.net on some machines / networks

2016-08-13 Thread Vincent Lefevre 
On 2016-08-13 16:46:46 +0200, Aurelien Jarno wrote:
> On 2016-08-13 04:23, Vincent Lefevre wrote:
> > I was not suggesting not to return all addresses. But in case of error
> > (which could just be a temporary network error, not necessarily due to
> > a bug in the nameserver, e.g. due to network congestion), if some of
> > the IP addresses are known, they could be made available to the calling
> > application in case they could be useful (e.g. for a connection). If
> > the application wants all the addresses, it can check error conditions
> > as usual.
> 
> The glibc provides getaddrinfo() which is a POSIX interface, also
> described in RFC2553. You can't change it just because you think it's
> better. Alternatively some other resolver libraries might provide the
> behaviour you need. Anyway in both cases it requires some changes on the
> application side too, which is clearly out of scope of this bug report.

It seems that POSIX doesn't specify the answer in the struct addrinfo
in case of error. But anyway, I was thinking more of an alternative
function, which could be more efficient when the goal is to do a
connection, since the applications need to be modified. Since many
applications could benefit from this, having such a function in the
GNU libc may be better than another resolver library.

Now, in the present case of keys.gnupg.net, this may be unnecessary
(see below about the 11/9/5 and the truncation bit).

> Also note that in your case the getaddrinfo() function returns an
> EAI_AGAIN error aka "Temporary failure in name resolution". The
> application (in your case gnupg) can try to handle the failure or at
> least display a better error message than "Host not found" which is
> clearly misleading in that case.

Indeed. Now, with the new gnupg 2.x that has just replaced the old
one in Debian/unstable, resolving seems to be done differently and
I no longer get an error (I've checked that "ping" still fails to
be sure that this wasn't due to something else). So, there's no bug
to report to gnupg. :)

> > And I would say that it could be the opposite. Imagine a host with
> > hundreds of millions of IP addresses...
> 
> I am sure there is a limit somewhere in one of the RFC.

I haven't found a limit (though I didn't check everything).

According to

  
http://serverfault.com/questions/652237/whats-the-maximum-number-of-ips-a-dns-a-record-can-have

there isn't a limit, but this doesn't seem to be based on RFC's,
more on testing. With the example, 1000 records are obtained per
TCP query; other records are obtained with additional TCP queries,
but only one more at a time (rotation by 1). Well, this is rather
ugly with this client.

> Anyway if such a DNS entry exists, I don't think returning a failure
> is really a problem.

And this is what the nameserver of our router is doing! Its chosen
limit can appear to be low, but in absence of specification, how
to choose a practical limit? It seems to be rare to have more than
4 A or  records. Even www.google.org has only one. BTW, I'd be
interested in some statistics.

> > > The point is that the local resolver is supposed to be working
> > > correctly.
> > 
> > and the network quality is good, which is not always the case.
> > 
> > > If it doesn't, one can easily setup a local recursive name server
> > > like unbound.
> > 
> > Unfortunately, this is not a general solution due to buggy ISP's.
> > 
> > > > 11:55:59.097743 IP 192.168.0.6.41008 > 192.168.0.1.domain: 60367+ A? 
> > > > keys.gnupg.net. (32)
> > > > 11:55:59.097796 IP 192.168.0.6.41008 > 192.168.0.1.domain: 31606+ ? 
> > > > keys.gnupg.net. (32)
> > > > 11:55:59.098339 IP 192.168.0.6.38010 > 192.168.0.1.domain: 4217+ PTR? 
> > > > 1.0.168.192.in-addr.arpa. (42)
> > > > 11:55:59.143100 IP 192.168.0.1.domain > 192.168.0.6.38010: 4217 
> > > > NXDomain* 0/1/0 (94)
> > > > 11:55:59.143325 IP 192.168.0.6.43592 > 192.168.0.1.domain: 23396+ PTR? 
> > > > 6.0.168.192.in-addr.arpa. (42)
> > > > 11:55:59.161082 IP 192.168.0.1.domain > 192.168.0.6.41008: 60367 11/9/5 
> > > > CNAME pool.sks-keyservers.net., A 198.128.3.63, A 93.94.119.246, A 
> > > > 78.46.223.54, A 131.175.15.4, A 151.252.40.184, A 5.9.50.141, A 
> > > > 209.135.211.141, A 5.135.158.148, A 68.187.0.77, A 193.17.17.6 (502)
> > > 
> > > This tcpdump trace doesn't show the answer header, so we don't know if
> > > the truncation flag is set. That said the 11/9/5 says that the answer
> > > contains 11 answer records, 9 name server records and 5 additional
> > > records. This clearly doesn't fit. A normal DNS server would just return
> > > 11 answers, so 11/0/0.
> > > 
> > > That said I just realized that the strace entry in your previous email
> > > contains the beginning of the answer:
> > > 
> > > > 30419 recvfrom(4, 
> > > > "'J\203\200\0\1\0\v\0\10\0\0\4keys\5gnupg\3net\0\0\34\0\1"..., 2048, 0, 
> > > > {sa_family=AF_INET, sin_port=htons(53), 
> > > > sin_addr=inet_addr("192.168.0.1")}, [16]) = 500
> > > 
> > > Converted into

[glibc] branch glibc-2.24 updated (b01b0e2 -> 3b40ff5)

2016-08-13 Thread Aurelien Jarno 
This is an automated email from the git hooks/post-receive script.

aurel32 pushed a change to branch glibc-2.24
in repository glibc.

  from  b01b0e2   patches/localedata/locale-C.diff: update to unicode 
8.0.0, add missing categories, use the copy directive when possible.
   new  3b40ff5   debian/rules.d/build.mk: disable the C++ compiler for 
stage 1 builds, based on a patch from Matthias Klose.  Closes: #834138.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "adds" were already present in the repository and have only
been added to this reference.


Summary of changes:
 debian/changelog| 2 ++
 debian/rules.d/build.mk | 4 +---
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/pkg-glibc/glibc.git

Bug#834138: build stage1 glibc without a C++ compiler

2016-08-13 Thread Aurelien Jarno 
On 2016-08-12 13:06, Matthias Klose wrote:
> Package: src:glibc
> Version: 2.24-0experimental0
> Tags: patch
> 
> build stage1 glibc without a C++ compiler.  As long as this is not required, 
> we
> shouldn't be forced to a C++ compiler for stage1.

Thanks for the patch.

> --- glibc-2.24/debian/rules.d/build.mk~   2016-08-12 10:49:51.119631719 
> +0200
> +++ glibc-2.24/debian/rules.d/build.mk2016-08-12 12:54:25.763270288 
> +0200
> @@ -31,10 +31,12 @@
>   @echo Configuring $(curpass)
>   rm -f $(DEB_BUILDDIR)/configparms
>   echo "CC = $(call xx,CC)" >> $(DEB_BUILDDIR)/configparms
> - echo "CXX = $(call xx,CXX)"   >> $(DEB_BUILDDIR)/configparms
>   echo "MIG = $(call xx,MIG)"   >> $(DEB_BUILDDIR)/configparms
>   echo "BUILD_CC = $(BUILD_CC)" >> $(DEB_BUILDDIR)/configparms
> +ifeq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
> + echo "CXX = $(call xx,CXX)"   >> $(DEB_BUILDDIR)/configparms
>   echo "BUILD_CXX = $(BUILD_CXX)"   >> $(DEB_BUILDDIR)/configparms
> +endif
>   echo "CFLAGS = $(HOST_CFLAGS)">> $(DEB_BUILDDIR)/configparms
>   echo "ASFLAGS = $(HOST_CFLAGS)"   >> $(DEB_BUILDDIR)/configparms
>   echo "BUILD_CFLAGS = $(BUILD_CFLAGS)" >> $(DEB_BUILDDIR)/configparms
> @@ -83,7 +85,7 @@
>   $(call logme, -a $(log_build), \
>   cd $(DEB_BUILDDIR) && \
>   CC="$(call xx,CC)" \
> - CXX="$(call xx,CXX)" \
> + $(if $(filter stage1,$(DEB_BUILD_PROFILES)),,CXX="$(call 
> xx,CXX)") \

Hmm it might work for now, but I am afraid the configure script might
try to detect a C++ compiler anyway and get the wrong one. I have
therefore slightly changed your patch to force an empty (":") C++
compiler.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Processed: Bug#834138 marked as pending

2016-08-13 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> tag 834138 pending
Bug #834138 [src:glibc] build stage1 glibc without a C++ compiler
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
834138: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834138
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

[glibc] 01/01: debian/rules.d/build.mk: disable the C++ compiler for stage 1 builds, based on a patch from Matthias Klose. Closes: #834138.

2016-08-13 Thread Aurelien Jarno 
This is an automated email from the git hooks/post-receive script.

aurel32 pushed a commit to branch glibc-2.24
in repository glibc.

commit 3b40ff5e9ff6431ddf87fafa692d39b1f1e01ef4
Author: Aurelien Jarno 
Date:   Sat Aug 13 17:24:51 2016 +0200

debian/rules.d/build.mk: disable the C++ compiler for stage 1 builds, based 
on a patch from Matthias Klose.  Closes: #834138.
---
 debian/changelog| 2 ++
 debian/rules.d/build.mk | 4 +---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index c79285e..1a4a98b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -16,6 +16,8 @@ glibc (2.24-0experimental1) UNRELEASED; urgency=medium
 merged upstream from the 2.23 version.
   * patches/localedata/locale-C.diff: update to unicode 8.0.0, add missing
 categories, use the copy directive when possible.
+  * debian/rules.d/build.mk: disable the C++ compiler for stage 1 builds,
+based on a patch from Matthias Klose.  Closes: #834138.
 
  -- Samuel Thibault   Thu, 04 Aug 2016 09:20:04 +0200
 
diff --git a/debian/rules.d/build.mk b/debian/rules.d/build.mk
index abc1225..231d387 100644
--- a/debian/rules.d/build.mk
+++ b/debian/rules.d/build.mk
@@ -30,8 +30,6 @@ $(patsubst %,configure_%,$(GLIBC_PASSES)) :: configure_% : 
$(stamp)configure_%
 $(stamp)configure_%: $(stamp)mkbuilddir_%
@echo Configuring $(curpass)
rm -f $(DEB_BUILDDIR)/configparms
-   echo "CC = $(call xx,CC)" >> $(DEB_BUILDDIR)/configparms
-   echo "CXX = $(call xx,CXX)"   >> $(DEB_BUILDDIR)/configparms
echo "MIG = $(call xx,MIG)"   >> $(DEB_BUILDDIR)/configparms
echo "BUILD_CC = $(BUILD_CC)" >> $(DEB_BUILDDIR)/configparms
echo "BUILD_CXX = $(BUILD_CXX)"   >> $(DEB_BUILDDIR)/configparms
@@ -81,7 +79,7 @@ $(stamp)configure_%: $(stamp)mkbuilddir_%
$(call logme, -a $(log_build), \
cd $(DEB_BUILDDIR) && \
CC="$(call xx,CC)" \
-   CXX="$(call xx,CXX)" \
+   CXX=$(if $(filter stage1,$(DEB_BUILD_PROFILES)),:,"$(call 
xx,CXX)") \
MIG="$(call xx,MIG)" \
AUTOCONF=false \
MAKEINFO=: \

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/pkg-glibc/glibc.git

Bug#834098: libc6: name resolution fails for keys.gnupg.net on some machines / networks

2016-08-13 Thread Aurelien Jarno 
On 2016-08-13 04:23, Vincent Lefevre wrote:
> On 2016-08-12 23:24:29 +0200, Aurelien Jarno wrote:
> > On 2016-08-12 12:15, Vincent Lefevre wrote:
> > > According to tcpdump output below, there is no truncation: the number
> > > of A's and 's (10 for each) match what "host keys.gnupg.net"
> > > gives. BTW, even if there were a truncation, there shouldn't be a
> > > failure: using of the returned IP addresses would be sufficient to
> > > connect.
> > 
> > That a wrong assumption. The libc getaddrinfo interface is not to
> > connect to an IP, but rather to return *all* addresses corresponding to
> > a query. The returned IPs are not necessarily used for a connection
> > later. 
> 
> I was not suggesting not to return all addresses. But in case of error
> (which could just be a temporary network error, not necessarily due to
> a bug in the nameserver, e.g. due to network congestion), if some of
> the IP addresses are known, they could be made available to the calling
> application in case they could be useful (e.g. for a connection). If
> the application wants all the addresses, it can check error conditions
> as usual.

The glibc provides getaddrinfo() which is a POSIX interface, also
described in RFC2553. You can't change it just because you think it's
better. Alternatively some other resolver libraries might provide the
behaviour you need. Anyway in both cases it requires some changes on the
application side too, which is clearly out of scope of this bug report.

Also note that in your case the getaddrinfo() function returns an
EAI_AGAIN error aka "Temporary failure in name resolution". The
application (in your case gnupg) can try to handle the failure or at
least display a better error message than "Host not found" which is
clearly misleading in that case.

> > Not returning all addresses so might lead to data loss or
> > security issue.
> 
> Well, an application should not base its security on the nameserver.
> It is well-known that nameservers can return fake answers.

The local recursive nameserver is by definition trusted. If additional
security is required, DNSSEC can be used.

> And I would say that it could be the opposite. Imagine a host with
> hundreds of millions of IP addresses...

I am sure there is a limit somewhere in one of the RFC. Anyway if such
a DNS entry exists, I don't think returning a failure is really a
problem.

> > The point is that the local resolver is supposed to be working
> > correctly.
> 
> and the network quality is good, which is not always the case.
> 
> > If it doesn't, one can easily setup a local recursive name server
> > like unbound.
> 
> Unfortunately, this is not a general solution due to buggy ISP's.
> 
> > > 11:55:59.097743 IP 192.168.0.6.41008 > 192.168.0.1.domain: 60367+ A? 
> > > keys.gnupg.net. (32)
> > > 11:55:59.097796 IP 192.168.0.6.41008 > 192.168.0.1.domain: 31606+ ? 
> > > keys.gnupg.net. (32)
> > > 11:55:59.098339 IP 192.168.0.6.38010 > 192.168.0.1.domain: 4217+ PTR? 
> > > 1.0.168.192.in-addr.arpa. (42)
> > > 11:55:59.143100 IP 192.168.0.1.domain > 192.168.0.6.38010: 4217 NXDomain* 
> > > 0/1/0 (94)
> > > 11:55:59.143325 IP 192.168.0.6.43592 > 192.168.0.1.domain: 23396+ PTR? 
> > > 6.0.168.192.in-addr.arpa. (42)
> > > 11:55:59.161082 IP 192.168.0.1.domain > 192.168.0.6.41008: 60367 11/9/5 
> > > CNAME pool.sks-keyservers.net., A 198.128.3.63, A 93.94.119.246, A 
> > > 78.46.223.54, A 131.175.15.4, A 151.252.40.184, A 5.9.50.141, A 
> > > 209.135.211.141, A 5.135.158.148, A 68.187.0.77, A 193.17.17.6 (502)
> > 
> > This tcpdump trace doesn't show the answer header, so we don't know if
> > the truncation flag is set. That said the 11/9/5 says that the answer
> > contains 11 answer records, 9 name server records and 5 additional
> > records. This clearly doesn't fit. A normal DNS server would just return
> > 11 answers, so 11/0/0.
> > 
> > That said I just realized that the strace entry in your previous email
> > contains the beginning of the answer:
> > 
> > > 30419 recvfrom(4, 
> > > "'J\203\200\0\1\0\v\0\10\0\0\4keys\5gnupg\3net\0\0\34\0\1"..., 2048, 0, 
> > > {sa_family=AF_INET, sin_port=htons(53), 
> > > sin_addr=inet_addr("192.168.0.1")}, [16]) = 500
> > 
> > Converted into hexadecimal, this is:
> >   27 4a 83 80 00 01 00 0b 00 08 00 00 04 6b 65 79
> >   73 05 67 6e 75 70 67 03 6e 65 74 00 00 1c 00 01
> > 
> > 274a is the identification. The flags are 8380 and corresponds to QR,
> > TC, RD, RA. Your name server clearly says that the answer is truncated.
> > On a working nameserver, the flags are 8180 for this query, so the same
> > without the truncation flag.
> 
> I don't understand here. You said above "This clearly doesn't fit.",
> so that it is normal that the truncation flag is set, isn't it?
> Or do you mean that the answer should have been 11/0/0, so that
> the truncation flag wouldn't be set as a consequence?

Your recursive DNS nameserver got asked to resolve keys.gnupg.net. As
all A records fit inside the 512 bytes limit, your