✧✦Catherine✦✧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
David Chisnall (*Now with 50% more sarcasm!*)@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
Timo the timo@whitequark my experience with podman so far has been "docker's default is to run code inside the container as the container's own root user and podman's default is to have a UID 1000 inside the container run everything" so 90% of the fixes for Containerfiles and containers I've pulled off the net was just to give it the flag to run "root" on the inside. the "podman-docker" or "docker-podman" package gives you a compatible socket in the right path that docker CLI and tools that speak to the docker socket directly can be happy, which may take you almost all the way to workflows requiring "docker-in-docker"? I hope at least one of these is new & helpful information to you
@timotimo this seems pretty much completely irrelevant
@whitequark I was thinking cibuildwheel should be able to run with that, but a second look lead me to the "container-engine" option (or CIBW_CONTAINER_ENGINE) that you can set to "podman". is it not running in practice even though it should work in theory?
@timotimo that fails with inability to find /dev/net/tun and /dev/fuse (the latter might be fixed by fuse-overlayfs, the former not sure)
@whitequark I've been able to do this just now:
podman run --rm -it --security-opt label=disable --user podman quay.io/podman/stable podman run -it --rm --user root registry.fedoraproject.org/fedora-toolbox
that's an image specifically built to use podman inside podman (or docker I guess?) and I'm running it as user and without --privileged and inside of it is a fedora toolbox and inside the fedora toolbox itself I was able to curl codeberg.org
This might be a good place to start from. Not sure what exactly makes the error about tun/tap not happen with this image, however
@whitequark I think I'll have time to look more closely this evening!
@timotimo thank you!