On 2019-10-07 13:43, Johannes Schauer wrote:
Quoting Philipp Kern (2019-10-07 13:21:36)On 10/7/2019 1:17 PM, Shengjing Zhu wrote: > On Mon, Oct 7, 2019 at 6:29 PM Simon McVittie <smcv@debian.org> wrote: >> On Mon, 07 Oct 2019 at 07:22:53 +0200, Johannes Schauer wrote: >>> Specifically, currently autopkgtest is limited to providing a read-only layer >>> for certain backends and its upstream has no intention of widening the scope of >>> the software [1]. This means that to upgrade an autopkgtest backend, the user >>> has to apply backend-specific actions >> I think "re-bootstrap, don't upgrade" is an equally good principle > Why not have a repository for it, like dockerhub. So this becomes > "pull latest build env", which saves lots of time("re-bootstrap" is still > slow nowadays).In that case it'd probably be better to make bootstrapping faster ratherthan trusting random binaries on the internet. (Unless we grow an "assemble an image from debs" service on, say, ftp-master.)creating a working sbuild chroot takes 10 seconds on my system: $ time mmdebstrap --variant=essential unstable debian-unstable.tar [...] mmdebstrap [...] 8.35s user 1.73s system 99% cpu 10.166 total Do we need to spend engineering effort to become faster than that?
I suppose that also depends on deb caching/pipe bandwidth? But yes, I find that totally fine.
Downloading "random binary from the internet" is less of a problem if
we can
create images which are bit-by-bit identical to checksums that we can
verify
through a trusted service. This is also already provided by mmdebstrap:
$ SOURCE_DATE_EPOCH=1570448177 mmdebstrap --variant=essential
unstable - | sha256sum
[...]
f40a3d2e9e168c3ec6270de1be79c522ce9f2381021c25072353bb3b5e1703d6 -
$ SOURCE_DATE_EPOCH=1570448177 mmdebstrap --variant=essential
unstable - | sha256sum
[...]
f40a3d2e9e168c3ec6270de1be79c522ce9f2381021c25072353bb3b5e1703d6 -
I think that's required, but not sufficient. That still depends on someone actually verifying this fact and publishing their proofs. Otherwise you need to do it yourself or risk getting a binary served to your build process only if not checked interactively[0].
Lastly: yes, maybe "re-bootstrap, don't upgrade" is an equally good principle. It has the advantage of not accumulating cruft. The sbuild-createchroot command could gain an option which allows one to replace an existing chroot. Currently,it refuses to work on already existing chroots.
At work we always regenerate unless when you test multiple times locally in quick succession. Assuming that the result is not totally wasteful (e.g. by caching bootstrap debs locally) that seems like a good way to get predictable local build environments.
Kind regards and thanks Philipp Kern[0] It seems to be a standard tool these days to serve exploits only when the caller looks like the target environment. I.e. if you check the script you pipe into bash from a browser it looks fine, if you curl it into bash[1], it looks different.
[1] Yes, it seems like even that case can be identified.