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
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, and log (and block) al
* 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 iptables/ip6tables.
--
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
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 used for this. I think lamby has a
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 across 'firejail' re
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
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 sub-processes) should contact a
* 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.
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
Jakub Wilk writes ("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
> asy
* 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 h
* 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 'needs network access'
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
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?
>
> W
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.
> The
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 licens
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 aggr
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 pac
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, we can't easily spot
* 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
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
>
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 distingui
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 nee
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 are
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 tha
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".
>
> > As a result policy
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 packages in the main arc
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:
> > h
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
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
polic
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 c
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 search, both of whic
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 for sbuild. There
is a
* 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 nam
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 addrinfo-test.invalid to
>> force a failure,
* 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 guaranteed by IANA re
* 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
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 severity: serious
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:
> https://bugs.de
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 forever
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 ot
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 not"),
* 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
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:
> https://bugs.deb
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 actu
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 confo
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?
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 thi
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/c
50 matches
Mail list logo
