Collaborative Working Sessions - Build sandboxing

Build sandboxing

== Summary ==

  1. Almost everybody uses isolation for builds, but the details vary a lot (VMs, containers, VMs + containers, raw namespacing, userspace syscall substition, MACs). Isolation matters for dependency detection, dependency minimization,but conversly dependency sharing, isolation of builds, security obvs., resource control.
  2. Network might or might not be allowed. One option is to allow network access in some phases, but require a fixed hash of the downloaded artifact (Nix/Guix solution).
  3. Bootstrapping is an extreme case of dependency minimization.

== Log ==

Gabor: everybody doing RB has some isolation in place.

Why are we doing is? unknown sources, foil autodetection, prevent spillover between builds, minimize dependencies that are used during build, share dependencies/state between builds and minimize, e.g. glibc version

separate hosts, VMs, namespaces / jails, +selinux optionally VMs is not enough, because it provides isolation from host, but is not a minimal environment, easier and faster to do local builds Justin: library os layer to abstract OS differences, maybe ready for next RBS recompile software to substitute system calls with function calls into the library gvisor is similar, the new thing is more portable rr, dettrace

Jochen: Some packages want to load kernel modules during build… (bup) nvidia drivers are needed after the build for some things

Gabor: should we substitute syscalls? apparmor? e.g. for a database that is spun up for tests…

Debian packages have nocheck, but not always honoured, and the test dependencies leak into build results and increase the system surface that is accessed during package builds.

Some test stuff could/should be moved out of the build phase. Debian: upstream tests in the build phase, then downstream integration tests, also piuparts

Gabor: should resource constraints be introduced into the build? Should this be enforced? This happens to some extent automatically with VMs and containers. Not really a question of BR.

Gabor: Should builds be allowed to access the network? Debian yes, Fdroid no. Proxies can be used. Nix and Guix have two types of derivations: one, hash of the result, fixed output delivaration, e.g. a downloaded tarball or repo checkout, two, a real build with type one as inputs, but no network access. Then the question of network access doesn’t matter. Except when the source might go away at some point.

It is more economic to build a system which allows BR for a limited time, e.g. when stuff is available to download from the CDN.

For Nix/Guix the build is just anything that reproduces the output hash, allowing caching. Next step is to abstract hardware, so that builds can be done without access to specific hardware types.

For nix any user belonging to a group can trigger builds.

Jochen: bootstrapping? Use a shell script to bootstrap for a new architecture. Bootstrapping is an extreme case of dependency minimization. In Guix, 400 byte bootstrap binary + 25MB guile driver. Debian is interested in cross-arch boostrapping, because new arch every year or so, but the set of base packages changes every time, so hard to reuse the process. Maybe fewer new architectures after Risc-V.

Jochen: reproducibility of cross and native builds is good for trust.