Re: Alternative solution (was: Re: Network access during build)

[Jakub Wilk]

* Ian Jackson , 2016-09-30, 15:03:

you can completely disable external network with socket_wrapper
... which is a pretty heavy-weight solution, and in fact it breaks asyncssh's 
tests.

Then that is clearly a bug in asyncssh's tests


... or in socket_wrapper, or in the way I used socket_wrapper. (Most likely the 
last one.)


--
Jakub Wilk

Re: Alternative solution (was: Re: Network access during build)

[Jérémy Lal]

2016-09-29 22:54 GMT+02:00 Jakub Wilk :

> * Jakub Wilk , 2016-09-07, 23:49:
>
>> you can completely disable external network with socket_wrapper
>>
>
> ... which is a pretty heavy-weight solution, and in fact it breaks
> asyncssh's tests.
>
> Luckily, glibc has a way to disable DNS queries without LD_PRELOAD
> trickery:
>
> $ RES_OPTIONS=attempts:0 wget http://www.example.com/
> --2016-09-29 22:49:22--  http://www.example.com/
>
> Resolving www.example.com (www.example.com)... failed: Temporary failure
> in name resolution.
> wget: unable to resolve host address ‘www.example.com’
>
>
This is wonderful, thank you !

Jérémy

Re: Alternative solution (was: Re: Network access during build)

[Ian Jackson]

Jakub Wilk writes ("Re: Alternative solution (was: Re: Network access during 
build)"):
> * Jakub Wilk <jw...@debian.org>, 2016-09-07, 23:49:
> >you can completely disable external network with socket_wrapper
> 
> ... which is a pretty heavy-weight solution, and in fact it breaks
> asyncssh's tests.

Then that is clearly a bug in asyncssh's tests.  Package builds and
tests should work in such a situation.

> Luckily, glibc has a way to disable DNS queries without LD_PRELOAD trickery:
> 
> $ RES_OPTIONS=attempts:0 wget http://www.example.com/
> --2016-09-29 22:49:22--  http://www.example.com/
> Resolving www.example.com (www.example.com)... failed: Temporary failure in 
> name resolution.
> wget: unable to resolve host address ‘www.example.com’

That's interesting - thanks for a useful contribution.

Doing that in the asyncssh package (either in debian/ or in upstream)
would mean that the above bug would go away.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Alternative solution (was: Re: Network access during build)

[Jakub Wilk]

* Jakub Wilk , 2016-09-07, 23:49:

you can completely disable external network with socket_wrapper


... which is a pretty heavy-weight solution, and in fact it breaks asyncssh's 
tests.


Luckily, glibc has a way to disable DNS queries without LD_PRELOAD trickery:

$ RES_OPTIONS=attempts:0 wget http://www.example.com/
--2016-09-29 22:49:22--  http://www.example.com/
Resolving www.example.com (www.example.com)... failed: Temporary failure in 
name resolution.
wget: unable to resolve host address ‘www.example.com’

--
Jakub Wilk

Re: Alternative solution (was: Re: Network access during build)

[Jakub Wilk]

* Christian Seiler , 2016-09-07, 07:43:
That way, you can force host name resolution to not use DNS for your 
test suite (via just using a hosts file), then there will be no network 
access during package build, and you don't have to keep rebasing a 
patch. And, even better, IF there is a host name called 'fail' on the 
local network, using nss_wrapper the package build will still succeed.


With nss_wrapper you can have your own hosts file, but I don't think it 
lets you force a name to fail to resolve.


However, you can completely disable external network with 
socket_wrapper:


$ LD_PRELOAD=libsocket_wrapper.so SOCKET_WRAPPER_DIR=$PWD wget 
http://www.example.com/
--2016-09-07 23:36:51--  http://www.example.com/
Resolving www.example.com (www.example.com)... failed: Temporary failure in 
name resolution.
wget: unable to resolve host address ‘www.example.com’

--
Jakub Wilk

Re: Alternative solution (was: Re: Network access during build)

[Jakub Wilk]

* Christian Seiler , 2016-09-07, 07:43:
And, even better, IF there is a host name called 'fail' on the local 
network


...or when your ISP hijacks all NXDOMAIN responses...


, using nss_wrapper the package build will still succeed.


--
Jakub Wilk

Alternative solution (was: Re: Network access during build)

[Christian Seiler]

On 09/07/2016 07:17 AM, Vincent Bernat wrote:
> One of the package that I maintain (python-asyncssh) makes a DNS request
> during build and expects it to fail. Since Policy 4.9 forbids network
> access (in a rather confusing wording "may not"), I got this serious
> bug:
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830568
> 
> The fix is easy: just disable the test.
> 
> However, I have a hard time to find this useful for anyone. To sum up:
> 
>  - patching the test suite requires maintaining the patch forever
>  - both pbuilder and sbuild are using an isolated network namespace
>  - package builds reproducibly with or without network access
> 
> I have the impression that enforcing every word of the policy in the
> hard sense can bring endless serious bugs. This particular occurrence
> affected about 70 packages. I appear as a bad maintainer because I don't
> feel this is an important bug.
> 
> Any thoughts?

Well, the problem mentioned in the bug report is not only the
package itself, but the information leak created by the DNS
request. And I think that really is something you should fix,
because package builds should really not cause _any_ network
traffic, even if said traffic doesn't actually affect the
result of the build. I don't think this is an overly strict
interpretation of the policy, but rather it's intention.

However, instead of disabling the test via a patch, there is a
solution where you can have your cake and eat it too. And it's
even in Debian. :-)

There's a piece of software called nss_wrapper, written by the
Samba people, that allows you to modify glibc's DNS functions'
(getaddrinfo, gethostbyname, ...) behavior via an LD_PRELOAD
library. It's called nss_wrapper;

Upstream website:
https://cwrap.org/nss_wrapper.html

Debian package:
https://packages.debian.org/unstable/libnss-wrapper

That way, you can force host name resolution to not use DNS for
your test suite (via just using a hosts file), then there will
be no network access during package build, and you don't have
to keep rebasing a patch. And, even better, IF there is a host
name called 'fail' on the local network, using nss_wrapper the
package build will still succeed.

Hope that helps.

Regards,
Christian