Open almet opened 1 week ago
After reading the gVisor blog post it occurred to me now that Docker became only a portability layer there is not such a pressure to ensure this is always up to date:
[...] By doing so, Dangerzone now has two containers with different responsibilities:
- The outer Docker/Podman container acts as the portability layer for Dangerzone. Its main responsibility is to bundle the necessary config files, scripts, and programs to run gVisor. It’s also responsible for bundling the container image that gVisor will spawn a container from.
- The inner gVisor container acts as the isolation layer for Dangerzone. Its sole responsibility is to run the actual Dangerzone logic for rendering documents to pixels.
What I'm implying is that we could even bundle podman (the non-desktop version) in Dangerzone's installer. This way the user user not be bothered at all by any extra user interface.
There are of course-edge cases that need to be considered:
what happens if we bundle podman and the user also happens to be a developer using podman for something else?
podman
(and other OCI container runtimes) can be directed to store all their files in a specific directory using the --root
flag. If Dangerzone were to bundle podman
inside of it, it could specify --root
to point to some directory owned by Dangerzone, and this would avoid interfering with any other non-Dangerzone containers or podman
installations on the machine.
Oh, great! Then that's a non-issue! (Updated the original comment)
That's a very good idea, thanks! It would simplify our life with {Docker, Podman} Desktop versions compatibility (on Windows and OSX, at least). That's pretty exciting, thanks for bringing it up.
Bringing this comment to your attention as well: https://github.com/freedomofpress/dangerzone/issues/736#issuecomment-1971782435
I have a small reservation (not verified yet), that {Podman,Docker} Desktop are also responsible for the instrumentation of the Linux VM. The binaries we're talking about are just the clients to the container engine (within the VM), and I guess they are the easy part to vendor within our project. Let's find out though.
As part of the search for alternatives to docker desktop (which is closed source) on OSX and windows (see #118), I tried Podman desktop, which is provided under an Apache2 license.
We still need some more discussion about which technology would be the best for us, but at least I'm happy to report that I was able to run it both via CLI and in the GUI, with minimal changes in how we detect the "runtimes".
Including a patch here in case it helps, which shortcuts the detection of the container tech to podman, and hardcodes the path to the binary, which obviously is not ideal, but was done just to check it would work :