Hi,

during the year, a src:dnspython change made it so that any software
importing that library now requires a valid /etc/resolv.conf with at
least one nameserver configured.

This also made it so that something between 50-100 packages now fail to
build if the build system doesn't have any working /etc/resolv.conf. I
venture to say that this is a very reasonable configuration to have in a
build system that tries to be network-disabled.

It must be noted that no actual network operation happen, so this
doesn't fall into the "no network activity" bucket.


This is the bug that was filed against dnspython: https://bugs.debian.org/989171


Do anybody on the list have any opinion on where is the bug, on
dnspython, or on the build environment?


As the pbuilder maintainer, I've been asked to make it serve a
non-working /etc/resolv.conf just to make that bug above moot, so I'm
quite biased on the matter myself :)

--
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-

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

iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAmE2KCkACgkQCBa54Yx2 K61YTQ/+PEHwMBywy0UHY84COmWSy7RhvL/4VPEvR/EypGlXit/W/1fwznJM9E/B 5lGQ6Ai8xSpHlvW+k426QO3zqDph9Drm9J+Izw9GaHGVzp1mSgLYr0XDW943x634 dNFtDFgUSDc1RSHQFroHMIwd4T0gccSP53dalCmDQBXCnmF66oGUr2Cy3ILOQxuV eW4VqUr54j6mPT+6lX9R2S/fjFej6S4QskFm4Wg25mFT+iWO7qUy5QSKGzqLRQZ1 TLk0F2JMLXNe7xhW/T5uUUriaJ3pFCWx/OjhMqz+gEyK86M2PYhvKN0EFEK8A4E5 +aHu9On4K+CcqtwavXNCC2hdyihMRKZ/tlx/UCADn3IVBW0vurmboUI/rpROKzEj WsDXF00ELxE332ZfSvbKaXNaOlbegkBjff2Tk9VUf604rx3HM5r5XzBIzOCfqSqT ptllONpKkmNV5Wx9AiOSJClg7pfpiUpy1W67jk5Ns/tG7NLJz4kRUEgLF98MTqcE APVF0mMG5DSivCa8N0+vZuIlMZSzwm5/76k0pN4RnK9qKnWAcsk

On Mon, 06 Sep 2021, Mattia Rizzolo wrote:

It must be noted that no actual network operation happen, so this
doesn't fall into the "no network activity" bucket.

This is the bug that was filed against dnspython: https://bugs.debian.org/989171

Do anybody on the list have any opinion on where is the bug, on
dnspython, or on the build environment?

Do you know why dnspython doesn't just fall back to socket.getaddrinfo
if it can't parse /etc/resolv.conf [or maybe why python applications
using dnspython don't fall back to that if dnspython fails?]

That seems like the right default unless you really, really need to talk
to a full-fledged DNS server directly.


--
Don Armstrong https://www.donarmstrong.com

He quite enjoyed the time by himself in the mornings. The day was too
early to have started going really wrong.
-- Terry Pratchet _Only You Can Save Mankind_ p133

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Sep 07, 2021 at 04:41:49PM -0700, Don Armstrong wrote:

On Mon, 06 Sep 2021, Mattia Rizzolo wrote:

It must be noted that no actual network operation happen, so this
doesn't fall into the "no network activity" bucket.

This is the bug that was filed against dnspython: https://bugs.debian.org/989171

Do anybody on the list have any opinion on where is the bug, on
dnspython, or on the build environment?

Do you know why dnspython doesn't just fall back to socket.getaddrinfo
if it can't parse /etc/resolv.conf [or maybe why python applications
using dnspython don't fall back to that if dnspython fails?]

That seems like the right default unless you really, really need to talk
to a full-fledged DNS server directly.

https://github.com/rthalley/dnspython

dnspython provides both high and low level access to DNS. The high level
classes perform queries for data of a given name, type, and class, and
return an answer set. The low level classes allow direct manipulation of
DNS zones, messages, names, and records.
...
dnspython is a utility to work with DNS, /etc/hosts is thus not used.
For simple forward DNS lookups, it's better to use socket.getaddrinfo()
or socket.gethostbyname().

dnspython originated at Nominum where it was developed to facilitate the
testing of DNS software.


cu
Adrian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On ബു, സെപ്റ്റം 8 2021 at 04:18:46 വൈകു
+0200 +0200, Thomas Goirand <zigo@debian.org> wrote:

Therefore, I am in the opinion that we should let the package run its
test as much as possible, especially considering that it's not doing
actual network outbound connections.

Can't we run these tests as autopkgtests?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/6/21 4:39 PM, Mattia Rizzolo wrote:

Hi,

during the year, a src:dnspython change made it so that any software importing that library now requires a valid /etc/resolv.conf with at
least one nameserver configured.

This also made it so that something between 50-100 packages now fail to
build if the build system doesn't have any working /etc/resolv.conf. I venture to say that this is a very reasonable configuration to have in a build system that tries to be network-disabled.

It must be noted that no actual network operation happen, so this
doesn't fall into the "no network activity" bucket.

This is the bug that was filed against dnspython: https://bugs.debian.org/989171

Do anybody on the list have any opinion on where is the bug, on
dnspython, or on the build environment?

As the pbuilder maintainer, I've been asked to make it serve a
non-working /etc/resolv.conf just to make that bug above moot, so I'm
quite biased on the matter myself :)

I already stated this during discussions on IRC, but I will reiterate
here to feed the discussion.

The only place where dnspython needs a working /etc/resolv.conf is
testing. Mandating a non-working /etc/resolv.conf will only result in
having less tests in that package, which will potentially lower the
package quality insurance, rather than improving Debian. When addressing
this problem, we should ask ourselves: what is it that we're actually
trying to fix. IMO: not much here... There's nothing broken.

Therefore, I am in the opinion that we should let the package run its
test as much as possible, especially considering that it's not doing
actual network outbound connections.

Cheers,

Thomas Goirand (zigo)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Sep 08, 2021 at 07:57:20PM +0530, Pirate Praveen wrote:

On ബു, സെപ്റ്റം 8 2021 at 04:18:46 വൈകു +0200 +0200, Thomas Goirand <zigo@debian.org> wrote:

Therefore, I am in the opinion that we should let the package run its
test as much as possible, especially considering that it's not doing
actual network outbound connections.

Can't we run these tests as autopkgtests?

That would only move the problem elsewhere, since this creates a similar question whether such tests should need a "needs-internet" restriction
for autopkgtest which might result in them being skipped in most cases.

cu
Adrian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Sep 06, 2021 at 04:39:39PM +0200, Mattia Rizzolo wrote:

Do anybody on the list have any opinion on where is the bug, on
dnspython, or on the build environment?

I concur that the absence of /etc/resolv.conf is a sensible
configuration. Indeed, it is my method-of-choice for implementing
poor-man's network-less builds with sbuild: Delete /etc/resolv.conf. It
doesn't actually prevent network access, but makes accidental network
access very unlikely.

I'm unsure whether /etc/resolv.conf is supposed to be essential. None of
the packages in that set ensure its creation. Rather debootstrap and
mmdebstrap have extra code to copy the host's /etc/resolv.conf into the
chroot. Therefore any created chroot will contain one. However that
seems more like an artifact of the bootstrap implementation rather than
an intentional guarantee to me.

As such, I err on dnspython being in need of a fix.

Helmut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mattia Rizzolo wrote:

during the year, a src:dnspython change made it so that any software importing that library now requires a valid /etc/resolv.conf with at
least one nameserver configured.

This also made it so that something between 50-100 packages now fail to
build if the build system doesn't have any working /etc/resolv.conf. I venture to say that this is a very reasonable configuration to have in a build system that tries to be network-disabled.

It must be noted that no actual network operation happen, so this
doesn't fall into the "no network activity" bucket.

This is the bug that was filed against dnspython: https://bugs.debian.org/989171

Do anybody on the list have any opinion on where is the bug, on
dnspython, or on the build environment?

I think dnspython's previous approach was correct: just like glibc, musl, and other libraries, if /etc/resolv.conf is missing they should treat that as though it specified a nameserver on localhost. The change to make that a configuration error, instead, breaks real configurations that intentionally don't have /etc/resolv.conf.

Among other things, having a DNS server on localhost (or forwarding the DNS port on localhost to your real DNS server) means that a chroot without /etc/resolv.conf still has functional DNS.

Now, that said, if the build process actually wants a DNS server to run tests against, it should provide or depend on such a DNS server, and configure it for such tests. But a build process that's just *importing the dnspython library* should not need to have either /etc/resolv.conf *or* a functional DNS server.

- Josh Triplett

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Sep 08, 2021 at 05:44:34PM +0200, Helmut Grohne wrote:

On Mon, Sep 06, 2021 at 04:39:39PM +0200, Mattia Rizzolo wrote:

Do anybody on the list have any opinion on where is the bug, on
dnspython, or on the build environment?

I concur that the absence of /etc/resolv.conf is a sensible
configuration. Indeed, it is my method-of-choice for implementing
poor-man's network-less builds with sbuild: Delete /etc/resolv.conf. It doesn't actually prevent network access, but makes accidental network
access very unlikely.

This does not work when software has a built-in fallback IP when no
nameserver is configured in /etc/resolv.conf

dnspython removing such a built-in fallback IP address and returning an
error instead is what caused the breakage in reproducible builds.

...
As such, I err on dnspython being in need of a fix.

What kind of fix?
Re-adding a default of 127.0.0.1 (or even 8.8.8.8) when no nameserver
is found in /etc/resolv.conf ?

dnspython is initialized several packages down in the callstack for the
failing packages by a concurrent networking library, and I am not aware
of any package in this stack doing something unreasonable.

Helmut

cu
Adrian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/8/21 5:44 PM, Helmut Grohne wrote:

As such, I err on dnspython being in need of a fix.

Dnspython isn't broken in any ways, it doesn't do any network access.
The only thing you're going to achieve is:
- more work for the maintainers (who will need to disable or patch the
tests).
- probably less tests (because the maintainer will probably choose to
simply disable the tests), which means less quality.

Again: what are you trying to achieve?

On 9/8/21 6:01 PM, Josh Triplett wrote:

Now, that said, if the build process actually wants a DNS server to
run tests against, it should provide or depend on such a DNS server,
and configure it for such tests.

Just to be 100% sure we're on the same page: that's *not* what dnspython
is doing. It's a client library that's testing parsing of the
/etc/resolv.conf format, and it just expects it to be there for parsing.

The code has:

class Resolver:
def __init__(self, filename='/etc/resolv.conf', configure=True):

Later on, the class calls the method read_resolv_conf that has:

try:
f = stack.enter_context(open(f))
except OSError:
# /etc/resolv.conf doesn't exist, can't be read, etc.
raise NoResolverConfiguration

The test cases are of course instantiating the Resolver object to test
it, and calls it with the default configuration (ie: /etc/resolv.conf as default), with something like this:

r = dns.resolver.Resolver(configure=False)

So, any test case that does that fails simply because the *FILE* /etc/resolv.conf isn't there on the filesystem (and not because there's
no working DNS server, which would be just fine).

One could argue that the test cases should aways instantiate the
Resolver object with a non-default (test only) filename argument. Well,
I agree with that: please propose such a patch upstream. But does it
deserve anyone time? I don't think so. We're achieving absolutely
nothing doing this: this doesn't improve Debian...

Cheers,

Thomas Goirand (zigo)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On ബു, സെപ്റ്റം 8 2021 at 06:10:56 വൈകു
+0300 +0300, Adrian Bunk <bunk@debian.org> wrote:

On Wed, Sep 08, 2021 at 07:57:20PM +0530, Pirate Praveen wrote:

On ബു, സെപ്റ്റം 8 2021 at 04:18:46 വൈകു
+0200 +0200, Thomas Goirand <zigo@debian.org> wrote:

Therefore, I am in the opinion that we should let the package run

its

test as much as possible, especially considering that it's not

doing

actual network outbound connections.

Can't we run these tests as autopkgtests?

That would only move the problem elsewhere, since this creates a
similar
question whether such tests should need a "needs-internet" restriction
for autopkgtest which might result in them being skipped in most
cases.

I don't think the default autopkgtest environment should be as
restrictive as the build environment. So adding this to default
autopkgtest enviroment is not the same as adding it to default build environment.


--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Sep 8, 2021 at 8:23 PM Thomas Goirand wrote:

Later on, the class calls the method read_resolv_conf that has:

It also fails if the file exists but has no nameservers:

if len(self.nameservers) == 0:
raise NoResolverConfiguration

So, any test case that does that fails simply because the *FILE* /etc/resolv.conf isn't there on the filesystem (and not because there's
no working DNS server, which would be just fine).

That seems like a bug in the test cases, they shouldn't be testing the
build time environment like that, since it could differ from the
runtime environment. There are nss_wrapper/resolv_wrapper for mocking
away the build-time DNS resolving infrastructure.

https://cwrap.org/nss_wrapper.html
https://cwrap.org/resolv_wrapper.html

One could argue that the test cases should aways instantiate the
Resolver object with a non-default (test only) filename argument.

Agreed.

I agree with that: please propose such a patch upstream. But does it
deserve anyone time? I don't think so. We're achieving absolutely
nothing doing this: this doesn't improve Debian...

It improves support for offline systems, which often don't have a
working /etc/resolv.conf

--
bye,
pabs

https://wiki.debian.org/PaulWise

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Sep 09, 2021 at 04:45:35AM +0000, Paul Wise wrote:

...
That seems like a bug in the test cases, they shouldn't be testing the
build time environment like that, since it could differ from the
runtime environment.

These are usually not the tests of dnspython.

dnspython even has some support for using a different file instead of /etc/resolv.conf, the problem is that there are several other packages
in the callstack before dnspython in these failing tests.

Note that even if you would be mocking /etc/resolv.conf, you'd still
have to add a nameserver IP address in the mocked /etc/resolv.conf
At that point you might as well install the mocked resolv.conf
as /etc/resolv.conf in build environments.

There are nss_wrapper/resolv_wrapper for mocking
away the build-time DNS resolving infrastructure.

https://cwrap.org/nss_wrapper.html
https://cwrap.org/resolv_wrapper.html
...

This is mocking the C library functionality,
which is not used by dnspython.

bye,
pabs

cu
Adrian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thomas Goirand wrote:

On 9/8/21 6:01 PM, Josh Triplett wrote:

Now, that said, if the build process actually wants a DNS server to
run tests against, it should provide or depend on such a DNS server,
and configure it for such tests.

Just to be 100% sure we're on the same page: that's *not* what dnspython
is doing. It's a client library that's testing parsing of the /etc/resolv.conf format, and it just expects it to be there for parsing.

I understood that; I'd just wanted to make it clear that while programs
parsing /etc/resolv.conf should assume a nameserver on localhost if /etc/resolv.conf doesn't exist, that doesn't mean that build processes
should actually require that such a nameserver be running.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Sep 08, 2021 at 09:01:31AM -0700, Josh Triplett wrote:

...
I think dnspython's previous approach was correct: just like glibc, musl, and other libraries, if /etc/resolv.conf is missing they should treat that as though it specified a nameserver on localhost.

How libraries implement a standard high-level C interface is not
necessarily relevant for how a DNS library implements a low-level
interface.

The change to make that a
configuration error, instead, breaks real configurations that intentionally don't have /etc/resolv.conf.

Among other things, having a DNS server on localhost (or forwarding the DNS port on localhost to your real DNS server) means that a chroot without /etc/resolv.conf still has functional DNS.

It is debatable whether this is a feature or a bug.

Having to configure a nameserver when you want DNS is less surprising
than software automatically using nameservers like 127.0.0.1 or 8.8.8.8
when none is configured.

Now, that said, if the build process actually wants a DNS server to run tests against, it should provide or depend on such a DNS server, and configure it for
such tests.
...

Depending on and configuring a normal DNS server might not happen in
practice, since the build process running as a normal user would have
to configure and manually start it running on a non-privileged port.

Trying to resolve DNS addresses on the internet during the build is
not permitted.

- Josh Triplett

cu
Adrian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/9/21 9:07 AM, Adrian Bunk wrote:

On Thu, Sep 09, 2021 at 04:45:35AM +0000, Paul Wise wrote:

...
That seems like a bug in the test cases, they shouldn't be testing the
build time environment like that, since it could differ from the
runtime environment.

These are usually not the tests of dnspython.

dnspython even has some support for using a different file instead of /etc/resolv.conf, the problem is that there are several other packages
in the callstack before dnspython in these failing tests.

Note that even if you would be mocking /etc/resolv.conf, you'd still
have to add a nameserver IP address in the mocked /etc/resolv.conf
At that point you might as well install the mocked resolv.conf
as /etc/resolv.conf in build environments.

Exactly. Which is why I wrote that we would be achieving nothing by
mandating a broken /etc/resolv.conf *IN THIS SPECIFIC CASE* (ie: where
the package is *NOT* doing any exteral DNS query).

I do believe, however, that we should not allow real DNS queries during
build time (just like accessing any external resource on the internet
should be forbiden, DNS shouldn't be an exception). But that's not what happening with dnspython (it builds fine without any internet
connectivity, it just wants a valid /etc/resolv.conf so it can parse it).

Cheers,

Thomas Goirand (zigo)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/10/21 10:53 AM, Josh Triplett wrote:

Thomas Goirand wrote:

On 9/8/21 6:01 PM, Josh Triplett wrote:

Now, that said, if the build process actually wants a DNS server to
run tests against, it should provide or depend on such a DNS server,
and configure it for such tests.

Just to be 100% sure we're on the same page: that's *not* what dnspython
is doing. It's a client library that's testing parsing of the
/etc/resolv.conf format, and it just expects it to be there for parsing.

I understood that; I'd just wanted to make it clear that while programs parsing /etc/resolv.conf should assume a nameserver on localhost if /etc/resolv.conf doesn't exist

I don't understand why that should be the case. If there's a local
nameserver, then it should be configured in resolv.conf as "nameserver 127.0.0.1" no?

Cheers,

Thomas Goirand (zigo)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thomas Goirand wrote:

On 9/10/21 10:53 AM, Josh Triplett wrote:

Thomas Goirand wrote:

On 9/8/21 6:01 PM, Josh Triplett wrote:

Now, that said, if the build process actually wants a DNS server to
run tests against, it should provide or depend on such a DNS server,
and configure it for such tests.

Just to be 100% sure we're on the same page: that's *not* what dnspython >> is doing. It's a client library that's testing parsing of the
/etc/resolv.conf format, and it just expects it to be there for parsing.

I understood that; I'd just wanted to make it clear that while programs parsing /etc/resolv.conf should assume a nameserver on localhost if /etc/resolv.conf doesn't exist

I don't understand why that should be the case. If there's a local nameserver, then it should be configured in resolv.conf as "nameserver 127.0.0.1" no?

Three reasons:

- It's the documented behavior when /etc/resolv.conf doesn't exist. `man
resolv.conf` says "If this file does not exist, only the name server
on the local machine will be queried, and the search list contains the
local domain name determined from the hostname.".
- It's the established historical behavior of glibc, musl, adns, and
various other resolvers, so breaking it would also be a backwards
compatibility break.
- This behavior allows providing DNS for a chroot or similar without
hacks like mounting a file over /etc/resolv.conf.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 10 Sep 2021, Adrian Bunk wrote:

On Wed, Sep 08, 2021 at 09:01:31AM -0700, Josh Triplett wrote:

...
I think dnspython's previous approach was correct: just like glibc, musl, and
other libraries, if /etc/resolv.conf is missing they should treat that as though it specified a nameserver on localhost.

How libraries implement a standard high-level C interface is not
necessarily relevant for how a DNS library implements a low-level
interface.

It seems to me that upstream should just not raise
NoResolverConfiguration, and instead not configure any nameservers.

Then, if someone tries to resolve without any configured nameservers, NoNameservers will be raised, which is the same thing that happens if
there are no good nameservers, and is less inconsistent with the
previous behavior.


--
Don Armstrong https://www.donarmstrong.com

2: There is no out. There is only in.
-- "The Prisoner (2009 Miniseries)"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Quoting Mattia Rizzolo (2021-09-06 16:39:39)

As the pbuilder maintainer, I've been asked to make it serve a non-working /etc/resolv.conf just to make that bug above moot, so I'm quite biased on the matter myself :)

sbuild already disables network access for all chroot backends that support it.

Schroot, the default chroot backend, currently doesn't allow this. See #802849.

The only chroot backend that allows disabling the network is the unshare backend. It does so, by unsharing the network namespace, only bringing up the loopback interface and writing an empty /etc/resolv.conf.

Thanks!

cheers, josch
--==============�97695471271940504=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

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

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmFAV6oACgkQ8sulx4+9 g+GVaBAAqTbWUltw4wVeuh8DxqNg0W4ISoRFwxT4wyIxKG5P9c91nd/GuQFiS7uM 1JCMWk8cpoyTuZ+YxSQ6BXENXxOkpo3h14QW8rWGsgPOEm9UlRa4aXeFCbxMsrbZ pUawCXvqj6s5lw9fJc/uQ4aj+xWbeOzO8arx85c4bXPiLMpJArpiq9CUEh2CVbsE P1Zi3pZQ2SbIBhSRXnM4haTkkO+yaSWhRRxdlEwboz2+6tSoAYMwsRqXx5Zbzgob tj+iLjrbv8a54SSG6vAhYLvMTv3TFZGXNe62qmkLp+S9wBg4jAi7m8LCqMPXo7Cm NPGj5/b1OsYjLhVb33qXZLJSWYjF5DTCZbs5qujDC8jH+j3N2WeS25MjdGPpA+DH Fa1qoQA2x+olTPsNxudevh8dwrsbjqFsq7MKl4WdCtP/G1wFvVtmnMCdStExr+GQ r4xCDxA2N64G+/YzZ3AW2U1fPAga9f6h6Rt69xu8A+e57SERhIAOYvQe50pV4im6 FbmyknzzutxUgNlmtTwbpyvF+ynF/VlzOtfSS51Nq273KEReli9osQ25AE/NkEcs l0WdprJF7qY1DS28Bm2yvFCEh1TPXIPBofYzkxRLpInEQMKXSVvXLJtq195W1o38 lKA1HMJL2mzAAU9l5x5dLZ1h421KLeSkbAGxHYwnC3ZGBabuxWg=
=7bZp
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Sep 13, 2021 at 04:05:57PM -0700, Don Armstrong wrote:

On Fri, 10 Sep 2021, Adrian Bunk wrote:

On Wed, Sep 08, 2021 at 09:01:31AM -0700, Josh Triplett wrote:

...
I think dnspython's previous approach was correct: just like glibc, musl, and
other libraries, if /etc/resolv.conf is missing they should treat that as though it specified a nameserver on localhost.

How libraries implement a standard high-level C interface is not necessarily relevant for how a DNS library implements a low-level interface.

It seems to me that upstream should just not raise
NoResolverConfiguration, and instead not configure any nameservers.

Then, if someone tries to resolve without any configured nameservers, NoNameservers will be raised, which is the same thing that happens if
there are no good nameservers, and is less inconsistent with the
previous behavior.

I would consider it worse if init of a module returns success in a
situation where it is known that the whole module is nonfunctional,
and then returns an error every time a thread tries to use the module.
There are obviously several options what could be done, but it's
difficult to call the current behaviour a bug in a DNS module.

The large picture is that there is no piece of software involved in
all this that is clearly buggy itself, the problem is that all pieces
together are at the border of forbidden "uses network" in Debian builds.

My personal stake in all this is that I've raised the topic twice with
Mattia since it makes it a lot harder to use reproducible for finding
FTBFS, and I was initially making the case for having the IP address
of a non-existing nameserver in /etc/resolv.conf in the reproducible environment.

My impression of this discussion is that unless someone discusses and
convinces an upstream to change their (not obviously buggy) software,
the affected packages must not run these tests during the build and if
there are autopkgtest they must have a "needs-internet" restriction.

cu
Adrian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Sep 14, 2021 at 10:05:01AM +0200, Johannes Schauer Marin Rodrigues wrote:

Hi,

Quoting Mattia Rizzolo (2021-09-06 16:39:39)

As the pbuilder maintainer, I've been asked to make it serve a non-working /etc/resolv.conf just to make that bug above moot, so I'm quite biased on the
matter myself :)

sbuild already disables network access for all chroot backends that support it.

As several people already stated, this is *not* about network access.

Schroot, the default chroot backend, currently doesn't allow this. See #802849.

Likewise pbuilder, yes.

The only chroot backend that allows disabling the network is the unshare backend. It does so, by unsharing the network namespace, only bringing up the loopback interface and writing an empty /etc/resolv.conf.

So you ship an *empty* /etc/resolv.conf? Then I suppose you also can't
build packages using dnspython in their tests with your configuration?

--
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-

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

iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAmFApOoACgkQCBa54Yx2 K63O8A//cc62sL3lPjt9DPXGzTHFGVas/MNSp998t1pj95hUjjxYT56K2qR/Kt9R BKZmutvniNtGI0xRoWvt2kUkmGcAhs/8fU8qewU0QBrYeRwutE+33iyXUJR7EMre 1XVwYTKqv2PkBYfBE2JFicEp+0DxboOSO2UVjPnsfgfbZmZqLdk9f71Sl3mD6TH5 ITiBB3RD0gOEbC3FW819Bv0JRJID0+S7wUOUS31ZSs7JV28H6wpEnBaBXwe/ChOX GkKzGTtDC8S3VWIVgNqPrpK3apIlv9HEm3aCM59yV8+LJ2NgWVbtyAz7KZpMpmnm ixOYv+DJNtYn1z1qFfDk/Q4glpyKKMLVNk2I1q0dsQ+u8/ldG8w6y/ktmMm8oPic bd457K5v/hsvu6iFkaVM6Rw2jWUhGo5QwPtbmLkI6vPpXv+rbdn8kYlS13/tQh/v 7NtwiU9XfMJTA921ciZIVLGAlgknI9goxA34F+Y+LkfttCtdvXXFlVmRCiD1bYxV AGcT84FKQ2D3wePnZGTmwNTPL4Vy4aSh9tvVLZ6BLOxVrIR8CNt

On September 14, 2021 5:16:51 PM UTC, Johannes Schauer Marin Rodrigues <josch@debian.org> wrote:

Quoting Mattia Rizzolo (2021-09-14 15:34:36)

On Tue, Sep 14, 2021 at 10:05:01AM +0200, Johannes Schauer Marin Rodrigues wrote:

Hi,

Quoting Mattia Rizzolo (2021-09-06 16:39:39)

As the pbuilder maintainer, I've been asked to make it serve a non-working
/etc/resolv.conf just to make that bug above moot, so I'm quite biased on the
matter myself :)

sbuild already disables network access for all chroot backends that support it.

As several people already stated, this is *not* about network access.

Yes, I mention it for context.

Schroot, the default chroot backend, currently doesn't allow this. See
#802849.

Likewise pbuilder, yes.

The only chroot backend that allows disabling the network is the unshare >> > backend. It does so, by unsharing the network namespace, only bringing up the
loopback interface and writing an empty /etc/resolv.conf.

So you ship an *empty* /etc/resolv.conf? Then I suppose you also can't build
packages using dnspython in their tests with your configuration?

Correct. This currently fails:

sbuild -d unstable --chroot-mode=unshare python-oslo.rootwrap

The error message is the same as for the package mentioned in #989171, namely:

https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/python-oslo.rootwrap.html

This is why I'm writing about sbuild. I wonder if it's a bug for sbuild to >write out an empty /etc/resolv.conf.

At least based on the error text, I think it would be the same whether it was empty or missing:

"Resolver configuration could not be read or specified no nameserver"

As far as I can tell, dnspython is behaving reasonably. I don't think we should make it so it is an error for a package to complain it can't function.

Scott K

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Quoting Mattia Rizzolo (2021-09-14 15:34:36)

On Tue, Sep 14, 2021 at 10:05:01AM +0200, Johannes Schauer Marin Rodrigues wrote:

Hi,

Quoting Mattia Rizzolo (2021-09-06 16:39:39)

As the pbuilder maintainer, I've been asked to make it serve a non-working
/etc/resolv.conf just to make that bug above moot, so I'm quite biased on the
matter myself :)

sbuild already disables network access for all chroot backends that support it.

As several people already stated, this is *not* about network access.

Yes, I mention it for context.

Schroot, the default chroot backend, currently doesn't allow this. See #802849.

Likewise pbuilder, yes.

The only chroot backend that allows disabling the network is the unshare backend. It does so, by unsharing the network namespace, only bringing up the
loopback interface and writing an empty /etc/resolv.conf.

So you ship an *empty* /etc/resolv.conf? Then I suppose you also can't build packages using dnspython in their tests with your configuration?

Correct. This currently fails:

sbuild -d unstable --chroot-mode=unshare python-oslo.rootwrap

The error message is the same as for the package mentioned in #989171, namely:

https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/python-oslo.rootwrap.html

This is why I'm writing about sbuild. I wonder if it's a bug for sbuild to write out an empty /etc/resolv.conf.

Thanks!

cheers, josch
--==============14587836147587320=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

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

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmFA2P8ACgkQ8sulx4+9 g+FXpQ/9Fj9RjV4eVag8hubh27z+9dwYrlxLWehV17o6KgVRzeTixPRDFwDAT5f9 9RRAJkj5EsJFjNm6WAEyslfUSoCXErp+lQvHcGKH8efkFb2E4QLWuB+PD1aJlvwn 4iCOXQE/dxc0Y/BShuDlSg+WrWySbUkCTDy8PYpeFmx+oORcGCqSj/4RvceSRF8X rZS9ibNKf1YKrH1zCgVytta8SDuPQD5N/02E5QKDr+Fa3W/KW87p3Cd7xpVSsQWH N4rlDvynfiSApqlLPEjC1OpdGjtaY26Yn18BhTTbVJ99nRzQTmgJtAmbrhba07ps Lz7SHVJCB9Df5sRTz1pW01EkHWOuliJmII21xpjYVyy5sz/LGh7qOAjJVVgLiAN/ MdoiEflEw1/9lBDo4cK0z+AQ9JTFljQmDwcKjoQJkvfV9ncJO5F9t9fY9d9ihIUp XSOiC/XrfxztrZyBnmNtXXnItzOwFBeMW6tlj6/dhvXXQ4LzwoTLGKYAVxig6kZN g5paWH44eh2D9VFGexizsJv9Hnmb+E2kLVQfAYHndMK7tds/KWW1HkFjode9Sw2+ SwgRkRJDa+K0uaORKYgNWrpvh90hkBtjLLTWumhzjnpiTAJT73GfWNDc3rK8O3Y1 VAk9NKWoC3JcQHvHwJEp+KqEVwZzohlVXBZcIhpjvGrYG5pKbyQ=
=8uhP
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)