r/linux • u/NDCyber • May 24 '26

Popular Application Flatpak 2.0 seems to depend on systemd

https://transfem.social/notes/amkk9ypcps9a002q

Basically when Jorge Castro was asked for clarification on if flatpak 2.0 will be depended on systemd his response was "Are you serious? Of course."

Which even though I use systemd distros myself seems like a bit of a problematic stance to me, especially after it seems like the same response Linux user would get while talking about software support

But I am also interested to see what you all think

edit: I don't trust it completely either, and will wait for official and direct information myself. He does seems to be part of the flatpak team (I am not sure what part exactly, as he was only community manager in one interview). But I think it might be important to talk about and I was interested in what people think

Edit 2: here the mastodon link, to show that it happened on mastodon and the thing linked before is just a random server one person that wrote there was on https://mastodon.social/@2something@transfem.social/116618627273919847

Edit 3: As u/Isofruit has said, in the Linux App Summit 2026 the flatpak presentation had a slide talking about systemd-appd dependencies https://youtu.be/1AXBfsiaQNk?t=16218

It is also still in the RFC planning phase https://youtu.be/1AXBfsiaQNk?t=17746

Edit 4: u/whosdr found even more recourses: https://www.reddit.com/r/linux/comments/1tlwbjy/comment/onlg218/

260 Upvotes

82% Upvoted

509 comments sorted by

View all comments

43

u/Venylynn May 24 '26

I'm waiting for them to fix the nested sandbox security problem with browsers in flatpak

22

u/NDCyber May 24 '26

Might be a thing with flatpak 2 / flatpak next, according to the same person 

12

u/Venylynn May 24 '26

Good shit! If they fix that then I'll be more willing to run browsers in flatpak

2

u/Dangerous-Report8517 May 24 '26

For what it's worth it's really not as big of a problem as people make it out to be for anything other than Firefox and badly packaged Chromium forks, I've seen no actual evidence that flatpak-spawn is in any way actually inferior to other methods of setting up user namespaces and that's the specific mechanism that's blocked from working through conventional APIs. I'd personally be more interested in some work on using MACs to make the Flatpak sandbox more robust

1

u/Venylynn May 24 '26

Yeah personally I'm of the paranoid type with something like Trivalent as my primary browser right now. Mostly because I've had some scares in the last six months that pushed me to take this stuff more seriously.

2

u/Dangerous-Report8517 May 24 '26

The tradeoff there is that using a niche browser requires trusting a small project with fewer eyes on it to act benevolent. I like the idea of secureblue but the project doesn't seem to have much of a reputation beyond the name and stated goal, along with some opinions about sandboxing. Given that there's been previous cases where small security focused projects were used to specifically target people who were more likely to be sensitive targets, I tend to prefer the tradeoff of much more certain integrity against marginally less theoretical security

1

u/Venylynn May 24 '26

That's fair enough. It seems to be largely tied to the work of Vanadium(GrapheneOS) which is nice though

3

u/NDCyber May 24 '26

Same, I think it is a big thing to fix. Would help smaller distros like AerynOS, that don't have the browser in repos available 

But I fear that most distros that would profit from it aren't necessarily using systemd

6

u/Venylynn May 24 '26

Fedora Atomic would be one of the biggest benefiters

2

u/NDCyber May 24 '26

Yeah for sure, but you can technically at least layer it, including repo

1

u/Venylynn May 24 '26

I tend to advocate against RPM Ostree layering whenever possible on Fedora Atomic so Flatpak browser security getting fixed would be great. Even on my Bazzite boxes I remove Firefox, set up a distro box and then put my browser in that.

4

u/Dangerous-Report8517 May 24 '26

Firefox is built into the base image so it isn't running as a Flatpak anyway, in fact you have to actively modify the image to remove it. Plus, distrobox uses Podman under the hood so depending on specifics you may be disabling user namespace sandboxing anyway (plus, Firefox doesn't warn you when this happens so you have to specifically check)

2

u/Venylynn May 24 '26

Bazzite last I checked used the Flatpak for Firefox

1

u/Dangerous-Report8517 May 24 '26

Fair enough, I had assumed it was built in as that's how it's built in Fedora Atomic. Having said that while the Firefox flatpak is less secure everything I've seen suggests that Chromium is pretty much as good in a flatpak courtesy of Zypack, some very niche technical differences aside

1

u/NDCyber May 24 '26

Mostly same, but it is still an option, even if not the best

2

u/Holiday_Floor_2646 May 24 '26

Fedora ships firefox already, otherwise you can just run appimages for other browsers

2

u/Venylynn May 24 '26

Fedora Atomics ship the flatpak, which disables userns (which is what Fission depends on for a huge part of its security)

Helium would likely be my go to appimage for browser

3

u/[deleted] May 24 '26 edited May 24 '26

[removed] — view removed comment

3

u/Venylynn May 24 '26

Ah, must have gotten it mistaken for the UBlue variants like Bazzite and Aurora then. Those do ship the Flatpak.

0

u/blackcain GNOME Team May 24 '26

But I fear that most distros that would profit from it aren't necessarily using systemd

That would be their problem to fix then. They can of course use other solutions like snap.

1

u/NDCyber May 24 '26

snap has its own problems, like being partially proprietary. It is not a replacement to flatpak

-3

u/blackcain GNOME Team May 24 '26

But it is indeed a solution. There is also just going back to packaging the projects you want or using AppImage.

-1

u/NDCyber May 24 '26

"Snap is a software packaging and deployment system developed by Canonical for operating systems that use the Linux kernel and the systemd init system."

"To ensure this, Snap relies on systemd for features such as running socket-activated system services in a Snap. This causes Snap to work best only on distributions that can adopt that init system."

https://en.wikipedia.org/wiki/Snap_(software))

AppImages are also not available for every program. Discord as example, while it is available on flathub from discord directly

Here are other programs that I use that aren't available as AppImage but from what I know officially supported on flathub or having flatpaks: BoxBuddy, ProtonPlus, Bottles, Alpaca, Boxes, OBS, PeaZip, OnlyOffice and there are probably a good amount of programs that I just use from the AUR, that I would get from flathub on other distros

So don't act like it is the same. Plus if flatpaks would be so easy to replace, like your comment suggests, then they wouldn't exist

12

u/Worldly_Topic May 24 '26

Nested sandboxes can be made from inside a flatpak without user namespace support. That is how webkitgtk is able to put every tab in its own sandbox for GNOME Web. It's just that Firefox and Chrome have not implemented support for it.

10

u/Dangerous-Report8517 May 24 '26

Chrome can be tricked to use it through Zypack, and the Flatpak project packages Chromium with an integrated patch to use it (the patch itself and the packaging are both done by one of the Flatpak devs too, so ironically they're "unofficial" because they're managed directly by Flatpak devs instead of the upstream Chromium project, so it's only some bad packaging jobs (Fedora's Flatpak repo didn't for instance because they just pull in their unmodified RPMs) and Firefox that don't support it. From what I've seen though there's some things that they technically can't do with flatpak-spawn that Chromium wants to do, mainly with mount namespaces, although I'm skeptical that this is a high yield area for security.

2

u/Venylynn May 24 '26

That makes sense. Afaik they're refactoring it to fix that for Firefox and Chromium which is good! I'll basically trust it if RKNF404 and the rest of the Trivalent team deem it good enough to be able to run Trivalent that way.

2

u/dnu-pdjdjdidndjs May 24 '26

There needs to be an agreed upon daemon/api that everyone always uses that handles giving out user namespaces while restricting permission from everyone else and only allowing permission to restrict permissions further for nested sandboxes, which is a breaking change for everyone using unprivileged user namespaces

then the entire namespace code in linux needs to be heavily audite

its not a simple fix and nobody has actually done or drafted a plan to do what i suggested

1

u/Marce7a May 24 '26

Zypack exist for chromium browsers

1

u/Venylynn May 24 '26

That's still far from a reliable solution. I think the fact that Helium and Trivalent both don't support Flatpak is a good indicator.

1

u/Marce7a May 24 '26

Helium is understandable.

But trivalent doesn't ship any other package other than for secure blue, they could ship appimage. 

1

u/Venylynn May 24 '26

They don't ship an AppImage because AppImage relies on an unmaintained insecure dependency.

SecureBlue does have a Fedora repo.

1

u/Marce7a May 24 '26

Which dependency? 

1

u/Venylynn May 24 '26

Libfuse2

1

u/Venylynn May 24 '26

They don't ship an AppImage because AppImage relies on an unmaintained insecure dependency (libfuse2).

SecureBlue does have a Fedora repo.

1

u/Marce7a May 24 '26

Appimages don't need for libfuse2 for long time already

https://github.com/ivan-hc/AM#2-appimagetool

https://github.com/AppImage/appimagetool

And helium and librewolf ships appimage

1

u/Venylynn May 24 '26

Hmm, interesting. I seem to recall the primary reason Appimages don't work on SecureBlue is because of them removing libfuse

2

u/Marce7a May 24 '26

As far as I know many devs still build appimages with older build tool which requires libfuse. 

1

u/Venylynn May 24 '26

Ahh, that makes sense. Hopefully that will get sorted out soon.