Andreas Tille <andr...@an3as.eu> writes: > From a user perspective some intermediate binary build wouldn't be more > difficult, thought.
It would be nice to not do this on the tag2upload server, though, to maintain some security separation. I think it's possible to avoid running arbitrary code from the package during a source package build because tag2upload doesn't need to run the clean step since it's starting from a fresh Git checkout (please check me on this). If I'm correct, it's much harder to attack the source package worker than it is to attack a buildd, which is arbitrary code execution from the package by design. You have to find an exploit in the source package construction code first. Yes, the binary build would be sandboxed, of course, but Linux sandboxing isn't perfect. I would feel more comfortable if binary builds were done somewhere without any access to the tag2upload signing key, even via a sandbox break. I may be over-solving this problem given that the same sandbox break attack could probably be turned into a persistent compromise of an amd64 buildd, which would be arguably worse than compromising the tag2upload server. But still, binary builds are inherently risky and the more sandboxing we can put around them, the better. Ideally we would run them in disposable VMs that we reset after each build. Given all of that, I think it would be more promising to look into a deeper integration with Salsa to check if the Salsa CI has succeeded, as discussed earlier in this thread. That would also match common upstream practice in Git-first development where the workflow for generating the release artifact depends on all of the tests passing through the normal CI mechanism. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
