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
This was my constant fear since the first day I learned about this
policy. While I consider the change the right thing, I'm somewhat
concerned the wording leads to requirements that neither were intended
nor are necessary to reach the goal that I consider the idea behind
it: The behaviour of any network activity must not affect the result
of the build. Where behaviour includes unavailability, and completely
unexpected behaviour like providing bogus data for any kind of
request. The easiest way to enforce this is to disallow network
traffic at all.
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 other daemons, most prominentely
named? Running "hostname --fqdn" unless this is handled by /etc/hosts
already? Also, I remember a certain package (name withheld) did a
*lot* of DNS traffic in the test suite, so far nobody has shown
concerns about this.
> However, I have a hard time to find this useful for anyone. To sum up:
>
> - patching the test suite requires maintaining the patch forever
This is one the the maintainer's chores. Many packages have patches
that will never go upstream and hence need a refresh at every new
release. Disabling a test should be a one-line patch that applies upon
new versions easily. If upstream constantly reorganizes the sources,
it'll become somewhat annoying but still feasible.
> - both pbuilder and sbuild are using an isolated network namespace
Network isolation doesn't look like the right answer to the problem.
Also, I'd be glad if any manual dpkg-buildpackage invocation would
result in the same build behaviour.
> - package builds reproducibly with or without network access
If I understood correctly the build will fail if the resolver does not
give a negative reply. Then your assumption isn't true.
> 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.
Again, I consider the change the right thing, mostly for the reason of
reproducibility. The wording could use some clarification though.
Christoph
Attachment:
signature.asc
Description: Digital signature