Dear Maintainer,

Whilst autopkgtest builds successfully on unstable/amd64, according to
Debian Policy 4.9 packages may not attempt network access during
a build.

The culprit seems to be:

 testbed.satisfy_dependencies_string('git, ca-certificates', 'install git for --git-source')

in runner/autopkgtest.

  2016-08-05 08:57:30.904700 IP 172.16.42.255.39212 > 10.0.1.1.domain: 1138+ SRV? _http._tcp.httpredir.debian.org. (49)
  2016-08-05 08:57:30.906362 IP 10.0.1.1.domain > 172.16.42.255.39212: 1138 NXDomain* 0/0/0 (49)
  2016-08-05 08:57:30.906785 IP 172.16.42.255.41134 > httpredir.debian.org.http: Flags [S], seq 1490473331, win 29200, options [mss 1460,sackOK,TS val 105543481 ecr 0,nop,wscale 7], length 0
  2016-08-05 08:57:30.906856 IP httpredir.debian.org.http > 172.16.42.255.41134: Flags [S.], seq 875435214, ack 1490473332, win 28960, options [mss 1460,sackOK,TS val 105543481 ecr 105543481,nop,wscale 7], length 0
  2016-08-05 08:57:30.906868 IP 172.16.42.255.41134 > httpredir.debian.org.http: Flags [.], ack 1, win 229, options [nop,nop,TS val 105543481 ecr 105543481], length 0
  2016-08-05 08:57:30.906960 IP 172.16.42.255.41134 > httpredir.debian.org.http: Flags [P.], seq 1:158, ack 1, win 229, options [nop,nop,TS val 105543481 ecr 105543481], length 157: HTTP: GET /debian/pool/main/c/ca-certificates/ca-certificates_20160104_all.deb HTTP/1.1
  2016-08-05 08:57:30.906988 IP httpredir.debian.org.http > 172.16.42.255.41134: Flags [.], ack 158, win 235, options [nop,nop,TS val 105543481 ecr 105543481], length 0
  2016-08-05 08:57:30.907110 IP httpredir.debian.org.http > 172.16.42.255.41134: Flags [.], seq 1:7241, ack 158, win 235, options [nop,nop,TS val 105543481 ecr 105543481], length 7240: HTTP: HTTP/1.1 200 OK
  2016-08-05 08:57:30.907134 IP 172.16.42.255.41134 > httpredir.debian.org.http: Flags [.], ack 7241, win 342, options [nop,nop,TS val 105543481 ecr 105543481], length 0
  2016-08-05 08:57:30.907197 IP httpredir.debian.org.http > 172.16.42.255.41134: Flags [.], seq 7241:14481, ack 158, win 235, options [nop,nop,TS val 105543481 ecr 105543481], length 7240: HTTP

  [..]

The full build log (including tcpdump output) is attached.


Regards,

Hello Chris,

Chris Lamb [2016-08-05 10:02 +0200]:

I'm lowering severity as

 - Violating a "may not" is not an RC bug as per policy 1.1.

 - While this is technically part of a "required" d/rules target, it
   only affects running the tests. These can be skipped with
   DEB_BUILD_OPTIONS=nocheck.

 - autopkgtest itself and the tests only download things via "apt-get
   download" (which is not random internet access but stays within the
   boundaries of the Debian archive, same like installing build
   dependencies). These tests get skipped if "apt-get download" fails,
   thus this is *not* an FTBFS if network access does not actually
   work.

So I believe that while this can be interpreted as a policy violation
it is still acceptable by the spirit of policy 4.9. I could completely
disable the network-using tests during package build, but that would
make regressions harder to detect.

That is one case -- your testbed does have "git" installed (otherwise
that tests would be skipped), but not "ca-certificates" to actually be
able to  verify SSL certs. I recommend to install that in your system
as well.

The various test_tmp_install*() test cases also download some packages
with "apt-get download", so these would need to be skipped as well if
this is really to be considered a policy violation.

Thanks,

Martin

Hi Martin,

Fair and trumps all :) However:

I'm not sure this would make any difference.. I mean, you can disable
all sorts of things - there's nothing special about skipping checks.

I think you may have misread my initial bug report.

It was never my claim that it was a FTBFS, more that an internet
connection is attempted in the first place ("Whilst autopkg builds
successfully [..]") which leaks privacy etc. etc.

But isn't that the whole point of the ci.debian.org/autopkgtest
service itself..?

In a normal system, of course, but I'm building *deliberately* to
find these issues so I will leave it uninstalled unless it is
Build-Depends.

:)


Regards,

Hello Chris,

Chris Lamb [2016-08-12  9:30 +0100]:

Sorry, but "leaking privacy" is not convincing at all. A machine that
builds packages downloads packages from the configured mirror via apt
all the time, and nothing else happens during the test.

The tests do run as autopkgtests as well. But Debian does not actually
use those for gating (yet).  Also, autopkgtest frequently gets
backported, where running the tests is very helpful to spot
regressions. apt itself has changed a lot recently, and configuring it
is very delicate ([1], *cough*) so I'd rather run these when/whereever
possible.

Martin

[1] https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/lib/adt_testbed.py#n1155

Hi Martin,

Let's distinguish two distinct questions here; I fear we are jumping
between the two when making our points:

 a) whether a package build can access/ping/whatever random-site.org
    during build.

 b) whether a package build can obtain "further" packages via the configured
    apt mirror.

To me, "a" is an obvious privacy leak. "b" is absolutely fine as long its
the configured mirror (not, for example, some hardcoded global APT mirror).


Regards,

Control: severity -1 serious

Policy now says "must not".

I'm going to check if autopkgtest still attempts to download the binaries.

Paul

Hi


 From code inspection, I think the test suite no longer does this since
commit 6ac81a0 from 2019 [1].

Paul

[1] https://salsa.debian.org/ci-team/autopkgtest/-/commit/6ac81a0