The Debian ftp team have ruled that they consider packages in main whose
automated tests download unpackaged programs from outside main to be a
REJECTable problem (reference:REJECT-FAQ.html §(Non-Main II)). However,
for some packages both inside and outside main, the ability to download
executable code from outside Debian is a large part of their purpose,
which should ideally be covered by tests.

For example, flatpak, snapd and docker.io are in main, because they
don't depend on third-party programs (it's more like the other way round,
the third-party programs depend on flatpak, snapd or docker.io); but if
we accidentally ship a version of one of those packages that is unable
to download those third-party programs, then its usefulness to our users
would be quite limited, and that's a failure mode that should be
straightforward to detect.

To prevent that sort of thing, I'd like to be able to add an autopkgtest
test-case that asserts that Flatpak *can* download and install third-party
programs, possibly with an appropriate Restriction that means official
Debian infrastructure won't run that test unless the operators of that
infrastructure are happy to do so. But I don't want that potential for
increased test coverage to result in removal from Debian, which would be
quite counterproductive.

For background, in case ftp team members are not familiar with autopkgtest
Restrictions: each test-case can be marked with "Restrictions" flags,
which are things like needs-root and isolation-container. Implementations
of the spec, like autopkgtest itself and devscripts' sadt, will not run a
test that has restrictions they don't understand unless specifically told
to do so, so marking a test with a newly-invented Restrictions flag will
cause that test to not be run by default, while leaving it straightforward
for a maintainer to run it locally before upload if they want to.

Some questions for the ftp team:

1. If flatpak (a package in main) had an autopkgtest that was basically
   this, marked with Restrictions: needs-internet:

    #!/bin/sh
    set -e
    flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo
    flatpak install flathub org.gnome.Recipes

   (which will download third-party executable code but not actually
   run it), would the ftp team consider that to be valid?

2. Would the answer to (1) change if the test additionally had some new
   restriction defined by the autopkgtest spec, perhaps
   Restrictions: downloads-third-party-programs or something similar?

3. Are the answers to (1) and (2) different if the test is downloading
   works from outside Debian that are not executable code, such as text,
   graphics or sound files? (I'm intentionally trying to avoid the word
   "software" here to avoid the ambiguity highlighted by GRs in 2004.)

4. Would the answer to (1) change if the test downloaded third-party
   executable code, but unlike in (1), the test also *ran* the third-party
   executable code? (For example if I added
   "flatpak run org.gnome.Recipes --help" to the end of that test, which
   ends up running "gnome-recipes --help" in the downloaded container.)

5. Would the answer to (4) change if the test had a restriction like
   Restrictions: runs-third-party-programs?

6. For a package in contrib (like game-data-packager) or non-free, are the
   ftp team's rules about autopkgtests different? Is it considered more
   valid for g-d-p to have an autopkgtest that downloads and/or runs
   third-party programs than it would be for flatpak, because g-d-p is
   in contrib?

When the ftp team has clarified what they will and will not allow, I would
like to add whatever new Restrictions flags would be useful into
the autopkgtest specification
<https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst>,
but there doesn't seem to be much point in me preemptively defining new
restrictions if uses of those restrictions would cause packages to be
removed from Debian.

Thanks,
    smcv

Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.

I see that #1031648 has been reassigned from the ftp.debian.org
pseudo-package to the general pseudo-package, presumably because
ftp.debian.org is now the issue tracker for the recently-created archive
operations team, and the questions I asked in #1031648 are something for
what is now the DFSG team (the other half of what used to be ftp team
responsibilities).

Quoting the full text of my questions below for the DFSG team:

My questions about Flatpak apply equally to other tools that are
frequently used to download and run arbitrary third-party software, like
snapd, docker.io, podman, lxd, vagrant, extrepo and so on. If you're
more familar with one of the other tools than with Flatpak, answers that
refer to one of the other tools would be equally useful.

Thanks,
     smcv

Hi Simon,

The DFSG team has discussed your questions regarding the relationship
between archive components and autopkgtests that require internet
access. Here are our answers to your specific points:

1. Downloading third-party data

 From a strict DFSG perspective, we treat them the same, but we
acknowledge that it makes sense to restrict execution of external code
for security reasons. Our mandate is to ensure that the source and
binary packages in the archive are DFSG- and Policy- compliant. If an
autopkgtest needs to download data to verify functionality, it should
simply be marked appropriately. The needs-internet flag is the correct
declaration of intent. It is then up to the infrastructure policy (not
the package maintainer) to decide if that flag is honored.

2 & 3. Downloading third-party executable code
As noted above, we do not differentiate between "data" and "code" for
the purpose of these downloads. While we agree that packages in main
should not download data from the internet during builds, for tests, the
needs-internet restriction is the appropriate mechanism, we currently
see no policy-driven need for a more granular distinction (like
"downloading code" vs "downloading data").

4 & 5. Running third-party executable code
 From a strict licensing perspective, we do not differentiate between
data and code downloaded during tests, provided the package does not
redistribute that downloaded content. However, we recognize that
executing external code poses security and reproducibility risks. While
these risks do not violate the DFSG, they may impose risks for operating
the machines that run package builds or execute autopkgtests. We
recommend addressing them with virtualization and sandboxing techniques,
rather than asking the Archive Operations or the DFSG team to identify
such issues manually, which is time-intensive and error-prone.

6. Packages in contrib vs. main
The rules for contrib are indeed different. Since contrib packages (like
game-data-packager) are explicitly for software that requires non-free
components to function, it is entirely acceptable for their autopkgtests
to download or run third-party programs that don't meet DFSG
requirements. However, that doesn't mean different rules for using
autopkgtest restrictions to declare intent. Unlike g-d-p, which targets
installing proprietary and non-free games, flatpak's main purpose is to
sandbox and distribute free software. As such, those autopkgtests can
and should focus on DFSG free software packages, which match flatpak's
typical intended use-case.

Regarding Package Removal and Release Eligibility:
You raised a concern that adding these restrictions might trigger
package removal. The DFSG team prefers not to block such packages from
entering the archive. We advocate for tracking these issues via the Bug
Tracking System (BTS) and resolving them through the standard maintainer
workflow, rather than using immediate rejection or removal.

@Release Team: Simon's concern specifically touches on whether packages
explicitly flagged as downloading/running third-party code in main would
be considered unsuitable for a stable release.

Does the Release Team agree with the DFSG team's approach (tracking
these as bugs rather than blockers)?

The DFSG team believes that test-only external dependencies should not
disqualify a package from main, provided the package functionality works
without them and the downloaded artifacts (like OCI images or flatpak
applications) are not included in the resulting .deb files. This allows
for the case at hand where a test ensures the expected behavior when
interacting with external services such as the flatpack archive or
docker image registries. We recommend the Release Team take a similar
stance and permit such packages in testing and stable releases.

We believe clarifying this will resolve the concern about potential
removals.

Best regards,