That is basically what the EUPL is.

In the sense that allowing a malicious application to steal your SSH keys is “fixing”, yes.

This is interesting, but I wouldn’t consider this to be at all comparable to Flatpak. From what I can see the only purpose of using bubblewrap here is the dependency isolation (without having to recompile the world ala Nix), which does have some value but it feels misleading to even call it a sandbox.

It mounts /home and /run into the sandbox chroot, which means that “sandboxed” applications can do things like reading your SSH keys, dumping your keyring or escaping the sandbox via write to .bashrc (so most of the attacks you’d want to prevent). This is presumably done because without /home access you wouldn’t be able to write to the filesystem and without /run access you can’t even display a graphical window, which would make the packages quite useless.

XDG Desktop Portal solves this by allowing filtered dbus access controlled by package metadata (/.flatpak-info), and then having sandboxed applications use portals to access files, secrets and other resources. The metadata is a major flaw in Flatpaks design (note that a lot of the most popular Flatpaks want full $HOME access), but it’s also what allows Flatpak to be useful. In this project, there’s no metadata since the packages just come from Alpine repositories.

I haven’t heard of Coldbrew before, it looks very interesting.

The unfortunate thing about snap is that of all options, it is the most capable. You get GUI, CLI, server, full filesystem access if needed (aka classic snaps). But Canonical really drags the project down and handicaps it with poor decisions.

That’s also how I feel about it. I’ve heard many good things about it technically, but Canonical really killed its adoption outside of Ubuntu.

Then you look into it a bit more and the story changes to “oh actually you need to enable this experimental feature to get better reproducibility”.

This unfortunately gets misunderstood a lot, mostly because of the stupid flake hype. You do not need flakes for reproducibility, Nix comes with a fetchTarball builtin function which allows you to pin a specific Nixpkgs commit and output hash.

You’re right though, I agree on basically every point (including the part about flakes).

I’ve used NixOS, wasn’t that big of a fan. I certainly love the idea, but not the execution.

Would you mind elaborating on that? I do have some suspicions but I would love to hear what bothered you about it.

There’s probably a combination of magic command line flags that allows podman/distrobox to work, but we honestly shouldn’t need containers for this at all.

It’s frustrating how we have all the pieces to make this work, but they just don’t come together properly:

• Brew isn’t sandboxed and pollutes the environment
• Nix isn’t sandboxed and can’t prefix install (also the DX with Nix really sucks)
• Guix is like Nix but without the packages
• Flatpak doesn’t have the packages
• Snap is proprietary garbage

Maybe this is a hint that I should write my own package manager, with blackjack and hookers that works like Nix, but doesn’t hardcode /nix/store, runs everything in bubblewrap and works with SELinux?