Re: Network access during build

Hello, On Fri, Oct 07, 2016 at 10:35:01AM +0100, Simon McVittie wrote: > I think schroot also has internal support for unsharing the network > namespace, which is what unshare(1) and bwrap do, and probably also what > firejail does. See #802849. -- Sean Whitton

Re: Network access during build

On Fri, 07 Oct 2016 11:53:58 +0200, Jakub Wilk wrote: > * Jérémy Lal , 2016-10-06, 17:48: > > Is there some simple way to check, when using sbuild, that the build > > does not access network ? > It probably doesn't count as simple, but: > I have a separate user for building,

Re: Network access during build

* Jérémy Lal , 2016-10-06, 17:48: Is there some simple way to check, when using sbuild, that the build does not access network ? It probably doesn't count as simple, but: I have a separate user for building, and log (and block) all outgoing traffic of this user using

Re: Network access during build

On Fri, 07 Oct 2016 at 10:09:34 +0200, Philip Hands wrote: > I only stumbled across 'firejail' recently, but it seems possible that > one could run the build under it, to lock things down and/or get reports > of naughtiness. firejail is a "do what I mean" approach to sandboxing, AIUI. It might be

Re: Network access during build

2016-10-07 10:09 GMT+02:00 Philip Hands : > Paul Wise writes: > > > On Thu, Oct 6, 2016 at 11:48 PM, Jérémy Lal wrote: > > > >> Is there some simple way to check, when using sbuild, that the build > >> does not access network ? > > > > nsntrace could probably be

Re: Network access during build

Paul Wise writes: > On Thu, Oct 6, 2016 at 11:48 PM, Jérémy Lal wrote: > >> Is there some simple way to check, when using sbuild, that the build >> does not access network ? > > nsntrace could probably be used for this. I think lamby has another > method too. I only stumbled

Re: Network access during build

On Thu, Oct 6, 2016 at 11:48 PM, Jérémy Lal wrote: > Is there some simple way to check, when using sbuild, that the build does > not access network ? nsntrace could probably be used for this. I think lamby has another method too. -- bye, pabs https://wiki.debian.org/PaulWise

Re: Network access during build

2016-09-07 12:32 GMT+02:00 Paul Wise : > On Wed, Sep 7, 2016 at 6:06 PM, Guillem Jover wrote: > > I think what we actually want is for the build to be self-contained. > > So nothing inside the build environment (defined as dpkg-buildpackage > or debian/rules and all

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

* 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

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

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

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

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

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

* 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: $

Re: Network access during build

* Paul Wise , 2016-09-19, 09:09: The only controversial cases seem to be tests, and these can run optionally after the packages have been built. Has anyone already thought of moving such tests into a separate optional step after the build is completed? IIRC DEP-8 has a

Re: Network access during build

On Mon, Sep 19, 2016 at 1:07 AM, Adrian Bunk wrote: > The only controversial cases seem to be tests, and these can run > optionally after the packages have been built. > > Has anyone already thought of moving such tests into a separate optional > step after the build is completed? IIRC DEP-8 has

Re: Network access during build

On Sun, Sep 18, 2016 at 08:07:14PM +0300, Adrian Bunk wrote: > The only controversial cases seem to be tests, and these can run > optionally after the packages have been built. > > Has anyone already thought of moving such tests into a separate optional > step after the build is completed? > >

Re: Network access during build

On Wed, Sep 07, 2016 at 09:26:37AM -0700, Russ Allbery wrote: >... > Full disclosure: several of my packages in the archive have similar tests. > Those tests are part of the upstream test suite for the getaddrinfo and > getnameinfo replacement functions for OSes that are too old to have them. >

Re: Network access during build

On 09/13/2016 12:56 AM, Thomas Goirand wrote: On 09/09/2016 09:53 PM, Russ Allbery wrote: Furthermore, we're talking about upstream test behavior here, and I don't think this argument passes the sniff test for conversations with upstream. We already have enough issues with upstream over

Re: Network access during build

On 09/09/2016 09:53 PM, Russ Allbery wrote: > Furthermore, we're talking about upstream test behavior here, and I don't > think this argument passes the sniff test for conversations with upstream. > We already have enough issues with upstream over licensing, where we've > decided that our very

Re: Network access during build

On Fri, Sep 9, 2016 at 3:39 PM, Emmanuel Bourg wrote: > "For packages in the main archive, no build step may attempt network > access in a way that: > - leaks sensitive data > - changes the build result or the operations performed to produce it" > > (with the build result defined as the binary

Re: Network access during build

Adam Borowski writes: > As there's no way to distinguish such details automatically, and as > data/privacy leaks can be quite surprising, I'd strongly prefer the > nice, simple rule of "no attempt to access outside network, period". > If _some_ network accesses are allowed,

Re: Network access during build

* Guus Sliepen , 2016-09-09, 16:19: AFAIK, at the moment it's only the buildds that block network access. Do they? [citation needed] -- Jakub Wilk

Re: Network access during build

Guus Sliepen writes ("Re: Network access during build"): > But should this perhaps also be enforced in our build tools? Ie, have > dpkg-buildpackage set up an empty namespace before executing > debian/rules? AFAIK, at the moment it's only the buildds that block > netwo

Re: Network access during build

On Fri, Sep 09, 2016 at 03:57:42PM +0200, Adam Borowski wrote: > > "For packages in the main archive, no build step may attempt network > > access in a way that: > > - leaks sensitive data > > - changes the build result or the operations performed to produce it" > > As there's no way to

Re: Network access during build

On Friday, September 09, 2016 03:57:42 PM Adam Borowski wrote: > On Fri, Sep 09, 2016 at 09:39:09AM +0200, Emmanuel Bourg wrote: > > Le 9/09/2016 à 01:13, Henrique de Moraes Holschuh a écrit : > > > "must not change build behavior or build result depending on network > > > availability" is also

Re: Network access during build

On Fri, Sep 09, 2016 at 09:39:09AM +0200, Emmanuel Bourg wrote: > Le 9/09/2016 à 01:13, Henrique de Moraes Holschuh a écrit : > > > "must not change build behavior or build result depending on network > > availability" is also needed somewhere, if it is not already in there. > > If some tests

Re: Network access during build

Le 9/09/2016 à 01:13, Henrique de Moraes Holschuh a écrit : > "must not change build behavior or build result depending on network > availability" is also needed somewhere, if it is not already in there. If some tests are automatically disabled when the network isn't available one could argue

Re: Network access during build

On Thu, 08 Sep 2016, Russ Allbery wrote: > gregor herrmann writes: > > IIRC (I didn't re-read the whole bug log now) the intention in > > #770016 was indeed more than "not affect the build result" but > > "explicitly forbid any attempt to access the network because leak". > >

Re: Network access during build

gregor herrmann writes: > IIRC (I didn't re-read the whole bug log now) the intention in > #770016 was indeed more than "not affect the build result" but > "explicitly forbid any attempt to access the network because leak". > As a result policy 4.9. now says: > For

Re: Network access during build

On Wed, 07 Sep 2016 08:41:19 +0200, Christoph Biedl 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: > >

Re: Network access during build

Emmanuel Bourg writes ("Re: Network access during build"): > That makes sense, but in this case what is the usefulness of the > Standards-Version field? And more precisely, why is it considered an > error [1] to omit it? The field is useful because it shows the most recent ve

Re: Network access during build

On Thu, Sep 08, 2016 at 09:42:57AM +0200, Emmanuel Bourg wrote: > That makes sense, but in this case what is the usefulness of the > Standards-Version field? And more precisely, why is it considered an > error [1] to omit it? As far as I care, the only point of the field is to document which

Re: Network access during build

Le 7/09/2016 à 09:35, Lars Wirzenius a écrit : > That's not how policy compliance actually works. All packages for a > given Debian release must conform to the version of policy that was > current when it was frozen for release. Otherwise we effectively have > no policy, if every package gets to

Re: Network access during build

On Wed, Sep 07, 2016 at 09:26:37AM -0700, Russ Allbery wrote: > Thomas Goirand writes: > > While I do agree that a package *must* be able to build without Internet > > access (for example, the test suite should never mandate access to a > > working DNS, or a query to a google

Re: Network access during build

Hi, Quoting Jakub Wilk (2016-09-07 19:29:05) > * Vincent Bernat , 2016-09-07, 07:17: > >both pbuilder and sbuild are using an isolated network namespace > > I know about pbuilder, but [citation needed] for sbuild. there is no out-of-the-box functionality that provides this

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

* 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,

Re: Network access during build

Jakub Wilk writes: > * Russ Allbery , 2016-09-07, 09:26: >> Now, that said, assuming that "fail" is not a valid host in the local >> domain isn't a good assumption and makes the build fragile. My packages >> that perform a similar test use the DNS name

Re: Network access during build

* Russ Allbery , 2016-09-07, 09:26: Now, that said, assuming that "fail" is not a valid host in the local domain isn't a good assumption and makes the build fragile. My packages that perform a similar test use the DNS name addrinfo-test.invalid to force a failure, which is

Re: Network access during build

* Vincent Bernat , 2016-09-07, 07:17: both pbuilder and sbuild are using an isolated network namespace I know about pbuilder, but [citation needed] for sbuild. -- Jakub Wilk

Re: Network access during build

Thomas Goirand writes: > While I do agree that a package *must* be able to build without Internet > access (for example, the test suite should never mandate access to a > working DNS, or a query to a google search, both of which are real world > cases...), I'm not sure about the

Re: Network access during build

On 09/07/2016 07:17 AM, Vincent Bernat wrote: > Hey! > > 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: >

Re: Network access during build

Vincent Bernat writes ("Network access during build"): > 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 If it is hard to maintain such a trivial patch

Re: Network access during build

On Wed, Sep 7, 2016 at 6:06 PM, Guillem Jover wrote: > On Wed, 2016-09-07 at 08:41:19 +0200, Christoph Biedl wrote: >> Now the funny question: Does traffic on the loopback interface count >> as network access? A daemon started during build to run tests is >> certainly okay. What about traffic to

Re: Network access during build

Hi! On Wed, 2016-09-07 at 08:41:19 +0200, Christoph Biedl wrote: > 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

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

* 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

Re: Network access during build

On Wed, Sep 7, 2016 at 1:17 PM, 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: >

Re: Network access during build

On Wed, Sep 07, 2016 at 09:29:53AM +0200, Emmanuel Bourg wrote: > This rule appeared in the version 3.9.7 of the policy. Just declare in > debian/control that your package conforms to the version 3.9.6 and the > issue will no longer be a RC policy violation ;) That's not how policy compliance

Re: Network access during build

Le 7/09/2016 à 07:17, Vincent Bernat a écrit : > Any thoughts? I agree with you, if the network access has no impact on the build and doesn't leak sensitive data it should be acceptable. This rule appeared in the version 3.9.7 of the policy. Just declare in debian/control that your package

Re: Network access during build

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: >

Re: Network access during build

On Wed, Sep 07, 2016 at 07:17:20AM +0200, Vincent Bernat wrote: > The fix is easy: just disable the test. > > However, I have a hard time to find this useful for anyone. To sum up: As a counterpoint, it's useful to prevent others from wondering why the build attempts to access the network. In

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

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: >