Feature: add an option to disable Internet/network access during build/testing

[mgorny]

Having an option to completely cut off build/test command execution from network access (whenever possible) would help finding if we aren't e.g. incidentally letting build systems download missing stuff, or tests access third-party servers (see e.g. conda-forge/torchvision-feedstock#107 (comment)).

In Gentoo Portage, we're using unshare(CLONE_NEWNET | CLONE_NEWUTS), followed by the equivalent of ifconfig lo up (so things dependent on running their own services on lo work) and setting hostname to localhost.

(you can grep https://gitweb.gentoo.org/proj/portage.git/tree/lib/portage/process.py for unshare_net, but warning: GPLv2)

[baszalmstra]

We are looking into running the build script in a sandbox to limit its access to the network, but also to the local system. We want to use this to provide better guarantees that “the outside world” does not leak into the built artifacts.

See #1178 for an early experiment.

[wolfv]

@mgorny the prototype in #1178 is much better now. It adds a couple CLI flags:

--sandbox (sandboxes file access and disallows network)
--allow-network (if you need it for some reason during build)
--read-write some/path
--read-execute ...
--read ... (these can be used multiple times)
--override-default-sandbox-config (override the defaults in rattler-build)

We have some defaults in there for macOS. I am wondering if you know what we should use for Linux? The average conda-build recipe uses tools like bash, sed, grep, etc. from host (although we could enforce to use them installed with rattler-build!). We might also have to read / link against some libraries from the linux kernel or glibc.

[mgorny]

I'm afraid I don't really know the answer to that — I'm pretty new to Conda ecosystem. To be honest, I'm a bit wondering why we use so many host tools — my gut feeling is that we'd prefer to install them inside build environment for consistency / more reproducible builds.

[wolfv]

Yep, I agree. We can make the sandbox stricter over time. It would be very interesting to attempt truly "hermetic" builds where everything (including bash) is installed in the build env.

I am closing this one for now as I have just released 0.34.0 with the experimental --sandbox flag.

You can override the default config for teh sandbox completely from the CLI to experiment with very strict sandboxing.