the expectation of being able to run docker whenever in CI jobs is probably the single worst outcome of free GitHub Actions minutes because reproducing it in a bring-your-own-compute environment is borderline impossible unless you make every machine single-tenant
@whitequark Don’t all modern CI systems run each job in an ephemeral VM? It’s about the only security boundary that I’d think you could defend against someone able to run arbitrary code these days, unless you lock down the environment so much that CI can’t do things it needs to do.
@david_chisnall Forgejo Actions runners offer you a choice of "Docker", "Podman", "LXC", and "lol rawdog it on the host"
@david_chisnall right now I'm using rootless Podman and I think it's defendable enough that I'm okay offering it to friends (who may still click on Approve & Run from a sketchy source, mind) but it's not letting cibuildwheel or other Docker-expecting applications run which is a problem

@whitequark

Yup, if your threat model is ‘friends who aren’t actively attacking your infrastructure and will do at least a bit of checking before they hit approve on PRs from other people’ that’s probably fine. I don’t think I’d trust any of those mechanisms for a high-profile project though, given how often privilege-elevation bugs in the Linux kernel are found.

I wouldn’t have thought any of these were easier for management than simply booting a VM with a bunch of preinstalled tools and a CoW base image, and the CI job settings exposed via something like qemufwcfg or a tiny FS on another virtual device.

@david_chisnall @whitequark the rabbithole of self hosted CI is a nightmare, the reality is there is no secure method, the sandboxing options are all flawed.

If I were to make a professional suggestion it would be to spin up a new temporary VM for each job on
someone else's infrastructure and hope for the best.

Good luck
@Baa @david_chisnall I am very well aware of this and if there was a reasonable way to do this with Forgejo Actions I would've already been doing it