XPost: linux.debian.policy

On Mon, May 05, 2025 at 11:19:09AM +0200, Bill Allombert wrote:

On Sat, May 03, 2025 at 09:11:21PM +0530, Pirate Praveen wrote:

Package: debian-policy
Version: 4.7.2.0

Current policy text says:

Except for packages in the non-free archive with the Autobuild control

field unset or set to no,

required targets must not attempt network access, except, via the loopback

interface,

to services on the build host that have been started by the build.

I think it should be changed to,

Except for packages in the non-free archive with the Autobuild control

field unset or set to no,

required targets must not require network access, except, via the loopback

interface,

to services on the build host that have been started by the build.

I think enforcing there is no internet access is a better way to achieve the
goal of actually ensuring there is no internet during build rather than considering packages that can use internet when available for tests as rc buggy.

I disagree. This was not the consensus at the time I made this change to policy, and
I do not think it is the consensus now. We want more reproducible builds, not depending on external resources that are bound to change, and not being tracked via
server logs. In your case building the package with internet access
- fails if timestamp.digicert.com is down
- leaks the system IP to DIGICERT

I agree.

Completly disabling access to internet during a build is harder than it sound.

I believe it is irrelevant how hard it is to disable Internet access
at build time. Even if it was easy, we did not want to require
disabling Internet access.

What we wanted, was that packages do not require, and also not
optionally talk to services on the Internet by default, at least at
build time.

IMO the policy wording is fine, and 1104509 needs to be fixed in the
package.

Best,
Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.policy

On Sat, May 03, 2025 at 09:11:21PM +0530, Pirate Praveen wrote:

Package: debian-policy
Version: 4.7.2.0

Dear Pirate,

Control: block 1104509 by -1

As a general policy, such block is inappropriate. Package are supposed to comply with policy at the time they are uploaded. They cannot depend on future potential policy update.

Current policy text says:

Except for packages in the non-free archive with the Autobuild control

field unset or set to no,

required targets must not attempt network access, except, via the loopback

interface,

to services on the build host that have been started by the build.

I think it should be changed to,

Except for packages in the non-free archive with the Autobuild control

field unset or set to no,

required targets must not require network access, except, via the loopback

interface,

to services on the build host that have been started by the build.

I think enforcing there is no internet access is a better way to achieve the goal of actually ensuring there is no internet during build rather than considering packages that can use internet when available for tests as rc buggy.

I disagree. This was not the consensus at the time I made this change to policy, and
I do not think it is the consensus now. We want more reproducible builds, not depending on external resources that are bound to change, and not being tracked via
server logs. In your case building the package with internet access
- fails if timestamp.digicert.com is down
- leaks the system IP to DIGICERT

Completly disabling access to internet during a build is harder than it sound.

Cheers,
--
Bill. <ballombe@debian.org>

Imagine a large red swirl here.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.policy

El 3/5/25 a las 17:41, Pirate Praveen escribió:

Package: debian-policy
Version: 4.7.2.0
Control: block 1104509 by -1

Note: I've just removed the block for the reasons stated by Bill.

I think it should be changed to,

Except for packages in the non-free archive with the Autobuild control field unset or set to no,
required targets must not require network access, except, via the loopback interface,
to services on the build host that have been started by the build.

I think enforcing there is no internet access is a better way to achieve the goal of actually ensuring there is no internet during build rather than considering packages that can use internet when available for tests as rc buggy.

I think the goal has never been "ensuring there is no internet during build".

When I'm debugging a package, I usually work in a directory-based chroot (created with debootstrap). If I had to drop internet access, I would have
to use firewall rules or just unplug the cable, which would make other
tasks requiring internet in my computer not to work at the same time.

I would consider the real goal to be ensuring that the package
builds the same regardless of network being present or not,
and also regardless of the way you choose to build the package,
be it dpkg-buildpackage in a chroot, sbuild with unshare, sbuild
with schroot, pbuilder, etc. It's a requirement which helps
reproducibility.

I did not want to be the first to reply to this policy bug,
but I also agree with the others participants that policy is
ok as it is, and I would also hope we keep enforcing it
even in cases like this one where the unshare backend hides
the network access and makes the package build not to fail.

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.policy

El 5/5/25 a las 21:54, Pirate Praveen escribió:

On 05/05/2025 4:28 pm, Santiago Vila wrote:

When I'm debugging a package, I usually work in a directory-based chroot
(created with debootstrap). If I had to drop internet access, I would have >> to use firewall rules or just unplug the cable, which would make other
tasks requiring internet in my computer not to work at the same time.

I would consider the real goal to be ensuring that the package
builds the same regardless of network being present or not,
and also regardless of the way you choose to build the package,
be it dpkg-buildpackage in a chroot, sbuild with unshare, sbuild
with schroot, pbuilder, etc. It's a requirement which helps
reproducibility.

at least in this specific instance, the final package remains the same irrespective of whether you have internet access or not. So this does not affect reproducibility at all. You just test more functionality if internet is present, that is all.

On the contrary, in this specific instance the final outcome changed completely.

- In the buildds -> the package built fine because network access was forbidden

- In my archive rebuild setup -> the package failed to build because it was accessing
the network and the service was giving 500 Error.

If we can't be sure if the package will build ok or not depending on external factors,
then the package does not really contain the complete source code, so this is not
only a reproducibility problem but also a DFSG-compliance issue.

Not only the .deb should always be the same, also the tests which pass or not pass
should also be the same.

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.policy

"Pirate" == Pirate Praveen <praveen@debian.org> writes:

Pirate> That was a temporary error. By disabling that test, we are
Pirate> losing out on useful tests.

I think we absolutely do not want a failure in an external service to
cause a package to FTBFS either on buildds or for individual users.
Ideally we would replicate the network side of a test and run against a
mocked component.
When that is not done (it's a lot of work), I would much rather disable
tests than introduce fragility by having tests that can sometimes fail
when an external service is down.

I also believe the privacy exposure of having code contact external
services is great enough that we should disable tests by default rather
than accept that exposure.

I agree with the option of creating a build option to allow network
access for tests if there are tests you would find useful to run say
from salsa-ci.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.policy

Hello,

On Tue 06 May 2025 at 02:11am +0530, Pirate Praveen wrote:

If we can't be sure if the package will build ok or not depending on
external factors,
then the package does not really contain the complete source code, so this >> is not
only a reproducibility problem but also a DFSG-compliance issue.

This is stretching the DFSG definition too much. Do we really want to interpret DFSG like this? We are testing functionality of the package that uses internet. So we should not have any tests that will confirm any features that uses internet?

Not only the .deb should always be the same, also the tests which pass or
not pass
should also be the same.

You are stretching DFSG here and I don't think this interpretation is actually
helpful. It only adds unnecessary constraint to ourselves on our ability to test features that needs internet.

The FTP team already interprets the DFSG this way, so it's not a
stretch.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmga7gcZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQOyGD/94lqKnKabNclNbiC5OvG+R rF+Le6LktgCItBjCHVdNcBpHeHB8y3HQJ6MFUgnAnM0yU1eX13qg+BNEOuArTrtP xbYmotjpfSyF7yDyraJ3hBaSRJNof894fv7JVUG9lkXUZ65ql741j9qW02bGEO2a GjahJYCBTfw/CgYzL9Jry9FlxlG8+Sm/UkR3mzNMfD2PUJYC8vxxKwekhxJNMUKN bvyTW3sLbCRqFKLN+QI/wZOHkmBZv8Vq+vi5+jQ1PPX4Ojgi/7dkZ9BpAmbo6plO JrYiEUZ3YW0Vx/TYuTlF3vICf7Zt4nAPkhD52NX/AuLhmQ9dayEjaxrjBx9Cw2mv xx5YkaxCUQJh7AbO56jyS2SVZl/vo6CjK1J1kL00mxDajv5nikeCjeRR6GoEOFLt FBW4G0PGLSYJ9LVYvTemUNsb4KWSyRZKRFdRsXxo5LV/mEXgeaORmQvOV7cmdnok tkkoIMsNgZ4QuQ39eyRDlDg5LlPOcmYpTbXiGaZtmkweXX4YLT+9w3TcDy+9bHW6 qYZBp0WVtOpO3IKtvtAFGrs1siW0oRGeKv92fTX6/Jlu29WRzH8csOmJ672Gp4pv BDDOfqPv0G7boNtOeMwawoI4BnjtNGte8KMZWRtpKSo5De6cynt9ptSdmO7toaPi ZEwoM/YyJ0enhokL9Yh6nQ==eKXO
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us