Builds isolation

[marmarek]

The current architecture relies on mmdebstrap for build isolation. If one build manages to escape that, it can alter artifacts of other builds in a shared artifacts directory - and those artifacts will then be attested in in-toto metadata and signed. Consider providing better build isolation (separate artifacts directories? extra integrity protection of artifacts, like sending file hashes on build finish?).

The threat model I'm thinking about is:

1. Someone manages to compromise one source package in Debian (either via Debian packaging - for example by compromising a Debian Developer's system, or by injecting malicious change into upstream sources directly). Lets call it package X. If a package is niche, that is less likely to be noticed and possibly also not very hard. But also, the impact will be small.
2. That package's build scripts try to escape mmdebstrap's sandbox and inject a backdoor into every artifact it find in artifacts directory (since it's shared, there will be artifacts from other builds too). This may be way more popular package (lets call it package Y). With some luck, it can do it before creating in-toto metadata, and so, in-toto will contain a hash of backdoored version.

Now there are several possible outcomes:

1. That was the only compromise: the rebuilder will report a different package Y hash than the upstream package. Depending on the configuration, and the scale, it may cause the package to be rejected as not reproducible. Manual inspection will likely reveal what's wrong, but it may significantly delay package availability - not good if that would be a security update.
2. This happens in parallel to an official build compromise (via some other vector): in this case, the malicious package X may inject the same backdoor as the official package Y has, and thus avoiding detection of binary package Y modification. It defeats the protection that reproducible rebuilds promise to give.

There are a lot of assumptions in the above attack scenarios, and some are highly non-trivial. But reproducible builds are defending against rather sophisticated attacks (on build infrastructure for example), and thus I don't think this attack should be dismissed yet.