Great to see open source projects funded, but the value of Flatpak for tech sovereignty evades me somewhat. It's a pretty niche and questionable piece of technology, and likely won't be there in 10 years. Some grants by STF, like Mastodon, Openstreetmaps, Let's Encrypt, rustls are spot on, but there are many questionable ones.
I never understood why a program installed in Flatpak is not just a directory on disk.
When you install something via Flatpak, it still changes data in god-knows-what places on my disk. And the software itself has read/write access to god-knows-where on my disk.
The answer is probably "convenience and efficiency". But I would much prefer a "An application is a directory and by default cannot access anything outside of that directory" approach.
By default, software has a sandboxed location that is exposed to the host in `~/.var/app/[APP]`.
Most software needs access to user files. Since most applications aren't written with Flatpak in mind, they will attempt to load files using their own file browser, meaning that for the application to function at all it needs to have access to swaths of extra data. You can see what data the application can access either via FlatSeal or in whatever "app store" you're using. Often it'll be your entire home directory.
The software that is designed with Flatpak in mind will use XDG Desktop Portals, where the host displays a file browser and then hooks it up to the sandboxed app so it has access only to that file or directory.
Note that you can't magic your way out of this. You can't eg. wait for the program to request access to a file before displaying a "Program wants access to this file. Allow/Deny" because the program doesn't know if this file exists, and the user wouldn't be able to navigate to it via the program's bespoke file browser since it doesn't have access to directories or their contents.
> Note that you can't magic your way out of this. You can't eg. wait for the program to request access to a file before displaying a "Program wants access to this file. Allow/Deny" because the program doesn't know if this file exists, and the user wouldn't be able to navigate to it via the program's bespoke file browser since it doesn't have access to directories or their contents.
What stops the OS from granting access to read the directory structure by default, but not read/write its contents? It’s imperfect, but better than the alternative.
Also, macOS does it somehow, or at least seems to. I get the prompt you’re describing all the time as of a few years ago (I’m fuzzy on when it started)
> What stops the OS from granting access to read the directory structure by default, but not read/write its contents? It’s imperfect, but better than the alternative.
Not much, it is entirely possible to do. But it also does have security implications like exposing SSH keys and such, which is why something like this isn't the default for flatpak. Though IIRC in a recent GUADEC or LAP(? too many talks recently happened) there were talks about moving "flatpak v2" to be either fully sandboxed and portal usage is a hard requirement or having the app basically be entirely unconstrained with probably only /usr/ or /opt/ mounted over or something like that (I think).
It's up to you, really, to only use flatpaks that declare tight permissions and implement the proper protocols to safely access resources they don't declare.
This isn't always easy and a lot of software on flathub is old-ish, so people tend to open up permissions since it's difficult to implement all these features properly. In my experience people will rarely stand in your way if you try to improve a package.
It’s also just hard to make breaking changes on Linux. Apple can declare something is changing and you have 1 year to get with the program. In Linux you have to bargain and plead with devs over 10 years to change something.
Restricting an app to not have file system access is a breaking change. It would have been dead in the water if they didn’t meet half way and make file system access an optional permission.
> But I would much prefer a "An application is a directory and by default cannot access anything outside of that directory" approach.
That makes sense if the application is the only program that needs to interact with the data. For example: If you have a drawing or photo editing program. You might have downloaded an image from the internet or from your camera. Then you make some edits. Afterwards you want to send the image to someone else via e-mail, which is another program.
Can't it request and be granted that permission, transparently to the app?
E.g. the app does EnumerateDirectories("~/photos") then without requiring modification to the app, the call is interecpted, the user is presented with a permission request UI, and once granted, the app continues?
At least that's how I'd thought it would work. Perhaps this isn't viable?
Apps built with a toolkit which ships its own filepicker will immediately attempt to enumerate directories in `/`, `/home`, and probably a few other places.
Apps with a config file will often try to read `~/.config/myapp` and also `~/.myapp/config` and maybe one or two other places.
Tech debt, primarily. Flatpak is designed to be able to package apps not designed with it in mind.
If neither compatibility nor resources are of concern then integrating true Mandatory Access Control into both the UX and the entire tech stack would be the best way forward.
Same prefer, although I'm not sure what you mean by "installing changes data in places on my disk"?
Nothing should change, all installations and addons go to the ~/.var directory. When you launch the application, yes it can start reading and writing to arbitrary places on disk, which is why I make it a habit of first launching Flatseal to modify permissions and know exactly what it can and can't do and reach.
I actually vastly prefer this methodology with what we have right now, but if it or something else adopted an application/directory methodology as you described I'd be elated.
I'd prefer that too. Preferrably with permission popups for requesting folder access outside of it. Shared libraries / whatever flatpak calls them could live at a central symlinked location?
Isn't that exactly how it's supposed to work, though? When I install a flatpak app for my user, it gets put into a standard location as a directory and by default has no access to filesystem other than the apps own config and data dirs (can't remember the paths). The fact that many apps choose to require excess permissions and can then bypass standard locations is a different matter
I use podman for things like this, works perfect until you want desktop applications but you can hack it about a bit to work fine with pipewire and Xephyr and you have. I feel like a lot of these desktop container systems are horrible and are quite hostile to configuring in the way you want around permissions and such and podman or docker does a better job.
I’m thankful for the STF. Germany is one of the few countries doing something. But it is not strategic software-development.
* They don’t employ software-developers. No safety for the developers. No control over developers.
* It is only temporary.
* The projects need to apply repeatingly for funding. Wasting time and resources and chausing worries.
The how planet needs Linux, BSD, cURL, ffmpeg, Flatpak. We need to ensure that this work for the people.
We feed for 30 years constantly money into monopolies. We shall feed the next century constantly money into things the people need.
Many developers of Linux and GCC are paid. Because companies decided it is necessary.
Would it make more sense if this Sovereign Tech Agency behaved less like a Sovereign Tech Fund and simply hired the developers? Or is civil servants developing OSS commodities too much of a heresy?
We do all this self-congratulation around funding OSS companies and then end up with OSS companies that exist only thanks to government subsidization. Why? Isn’t governmental control over funding what we hate about Microsoft? What is so bad about letting real customers decide which companies need funding?
I loved Flatpak until I started building a MiniPC with a 112 GB internal disk for HTPC usage... Then I felt the pain of having to get all slightly different dependency versions for each little program I wanted.
The box' cost already topped the project's budget so no new disk for it. I'm back to "proper .deb packaging please"
A lot of Flatpak's design is a great prototype, but it's somewhat worrying (for the ecosystem in general) that this was taken as a final design and being pushed out in all directions.
Portals are just a terrible design for a security boundary: all interfaces clobbered up into one huge daemon, which also deals with a lot of the internals of Flatpak/Snap. If you want your sandbox to use portals, you can't, because it relies on internals of both of these sandboxing mechanisms. The devs have confirmed they won't implement an API for other sandboxing engines to integrate with them.
The whole system also deeply intermixes the package manager and sandboxing engine — to the point where you can't use the sandboxing engine with your favourite package manager, and you can't use the package manager without the sandboxing engine.
It seems that the mentality is: all other distributions are irrelevant, all other sandboxing engines are unsupported.
And then desktop applications start having first-class integration with Flatpak, and start having issues everywhere else.
You already need to set up Flatpak's daemons for using some features in Firefox (like screen sharing, where the native interfaces aren't supported), and it seems that the plan is to do the same for other features.
In the beginning, Flatpak was seen as savior for the Linux desktop ecosystem by making more applications available for more distributions, possibly packaged by the upstream maintainer, but they didn't realize that Flatpak resp. Flathub are actually just another distro with its own builds, repository, package manager, package format and community.
On the security side it was also seen as the only way forward, but it's just opt-in sandboxing. That's still possible to achieve without flatpak by using the underlying sandboxing tool (bubblewrap), but not as user friendly as using the flatpak provided defaults.
This is true. I wrote a sandbox for applications shipped on an immutable distro last month and it uses all the same portals just fine but no ostree/flatpak whatsoever.
You also can have separate portals implemented with different processes if you, you know, use d-bus properly.
My trust in Flatpak diminished after installing the book reader Calibre and finding that despite the sandboxing Calibre was given blanket access to my drive. Apparently a quirk of the developer behind Calibre insisting upon it. No warnings or communication of the exception were given. All trust I had in Flatpak was eroded from that moment on. Curious about the podman options or similar. Having desktop apps in a container with selective access to system resources seems like it would be more secure and configurable if configured correctly. Flatpak as it stands seems to be a legacy solution to what should be a container and namespacing solution.
Don't know how you installed it, but required permissions are usually shown and warned about. The CLI could be clearer, though, but shows that host filesystem access is granted to calibre when it prompts to install
Permissions being granted implicitly is awful for security.
During installation they're _mentioned_ but the you can't pick which permissions to grant. If the developer requested it, its granted by default.
There are third party tools to tinker with permissions, but even those tools follow a "implicit grant first, revoke later" model, mostly because of how Flatpak implicitly grants permissions.
> No warnings or communication of the exception were given. All trust I had in Flatpak was eroded from that moment on
This is just wrong. Clients like the flathub website or gnome software show the risk posed by wide ranging access to local files, but Flatpak has to support legacy applications that don't use portals yet and thus they can't block applications having those permissions
I really like flatpaks to install desktop applications, as mentioned in some other comments the sandbox is sometimes poked full of holes because some applications don't use XDG desktop protals and need full filesystem access. If you are really concerened about this, you can use flatseal to limit the access that the application has.
If you prefer other ways of installing your software, that fine. But I really hope flatpaks continue improving and become the de facto way of installing desktop applications across all Linux distributions. For a normal, non-technical user installing and updating software should be easy, and I believe that flatpak provides this.
I like the idea behind Flatpak and the ability to sandbox applications. What I don't understand is why they chose to lock the build process so tightly to Linux.
I'm currently on macOS, and while I can cross-compile applications, I can't actually bundle them as Flatpaks. For that, I need `flatpak-builder`, which is so deeply coupled to Linux itself that I don't think it can realistically run on other platforms.
Snaps have a similar issue with `snapcraft`. However, you can still build a snap manually with `mksquashfs`, whereas I haven't found an equivalent low-level option for Flatpak. I may be missing something, though, and I'm still looking.
Same except for Steam. Hope this money revitalizes bubblewrap's development, it'd be nice to get proper signal handling cleanup up then merged (even util-linux's unshare has it, these days).
Only issue is with Nix as a long time user, it does not provide a standard way to run your nix builds in some kind of container, there are so many different competing third party systems and some first party systems built in nixpkgs it's self like building oci or docker containers or running systemd containers or even building qcow2 images, each with their own draw back and positives.
More and more I have found myself simply using podman and dockerfiles finding that building nix systems simply gets error prone and annoying and all the containerization systems leave a lot to be desired. Though I have some custom scripts for utilizing btrfs snapshots to create different nix store snap shots for containers or vms running with nix stores with virtiofs. This works quite well but not ready to be released and fiddly when things break and requires BTRFS.
I do agree flatpak and friends are not great though.
Nix is always doing its own thing. The community is fragmented and there are no enforced packaging conventions. They have a "best practices" page that lists language features you're not supposed to use because they break reproducible builds, aka the whole point of Nix. And they don't even restrict network access by default.
It's also not doing runtime sandboxing at all. Isolated builds protect you from supply chain attacks but not malware or vulns in the actual code, and they don't do anything for closed source apps.
Flatpak runs everything in a container with access limited to what is declared in the manifest and you can restrict it even more with Flatseal. It's not as secure as a Firecracker VM but it works way better than any other package system on Linux when it comes to security and distro independence.
Yes because both flatpak and nix use bubblewrap and linux. So it is indeed possible to build it with bubblewrap.
GUI apps on NixOS rarely care about sandboxing so while you can do it yourself i bet almost noone does. Flatpak is trying to give you basic protections out of the box.
Agreed. With all the improvements in namespacing I’m seeing the potential of all desktop apps being namespaced in a reasonable way, where filesystem access to e.g. /home is controlled through a kernel-hook prompt callback, with something like “always allow for this directory” etc.
That’d be so awesome!
Flatpak is great for installing, but as a happy Aurora user, it’s annoying and it breaks things all the time. Every desktop app i use has some broken feature. Sandboxes as another permissions panel suck. Simple browser-like permissions that allow prompted overwrite would be WAY better!
Now i have media organizer programs that deletes my files if i try to write on a networked drive. Games that can’t see the controller. Chat apps that can’t see attachments. Music app that can’t save at all. Good luck accessing any binary and using it in a script.
Flatpaks are a common packaging mechanism used on immutable systems. They are very attractive (conceptually) for large org deployments, so I can totally see the appeal here
Great to see open source projects funded, but the value of Flatpak for tech sovereignty evades me somewhat. It's a pretty niche and questionable piece of technology, and likely won't be there in 10 years. Some grants by STF, like Mastodon, Openstreetmaps, Let's Encrypt, rustls are spot on, but there are many questionable ones.
I never understood why a program installed in Flatpak is not just a directory on disk.
When you install something via Flatpak, it still changes data in god-knows-what places on my disk. And the software itself has read/write access to god-knows-where on my disk.
The answer is probably "convenience and efficiency". But I would much prefer a "An application is a directory and by default cannot access anything outside of that directory" approach.
By default, software has a sandboxed location that is exposed to the host in `~/.var/app/[APP]`.
Most software needs access to user files. Since most applications aren't written with Flatpak in mind, they will attempt to load files using their own file browser, meaning that for the application to function at all it needs to have access to swaths of extra data. You can see what data the application can access either via FlatSeal or in whatever "app store" you're using. Often it'll be your entire home directory.
The software that is designed with Flatpak in mind will use XDG Desktop Portals, where the host displays a file browser and then hooks it up to the sandboxed app so it has access only to that file or directory.
Note that you can't magic your way out of this. You can't eg. wait for the program to request access to a file before displaying a "Program wants access to this file. Allow/Deny" because the program doesn't know if this file exists, and the user wouldn't be able to navigate to it via the program's bespoke file browser since it doesn't have access to directories or their contents.
> Note that you can't magic your way out of this. You can't eg. wait for the program to request access to a file before displaying a "Program wants access to this file. Allow/Deny" because the program doesn't know if this file exists, and the user wouldn't be able to navigate to it via the program's bespoke file browser since it doesn't have access to directories or their contents.
What stops the OS from granting access to read the directory structure by default, but not read/write its contents? It’s imperfect, but better than the alternative.
Also, macOS does it somehow, or at least seems to. I get the prompt you’re describing all the time as of a few years ago (I’m fuzzy on when it started)
> What stops the OS from granting access to read the directory structure by default, but not read/write its contents? It’s imperfect, but better than the alternative.
Not much, it is entirely possible to do. But it also does have security implications like exposing SSH keys and such, which is why something like this isn't the default for flatpak. Though IIRC in a recent GUADEC or LAP(? too many talks recently happened) there were talks about moving "flatpak v2" to be either fully sandboxed and portal usage is a hard requirement or having the app basically be entirely unconstrained with probably only /usr/ or /opt/ mounted over or something like that (I think).
It's up to you, really, to only use flatpaks that declare tight permissions and implement the proper protocols to safely access resources they don't declare.
This isn't always easy and a lot of software on flathub is old-ish, so people tend to open up permissions since it's difficult to implement all these features properly. In my experience people will rarely stand in your way if you try to improve a package.
It’s also just hard to make breaking changes on Linux. Apple can declare something is changing and you have 1 year to get with the program. In Linux you have to bargain and plead with devs over 10 years to change something.
Restricting an app to not have file system access is a breaking change. It would have been dead in the water if they didn’t meet half way and make file system access an optional permission.
> But I would much prefer a "An application is a directory and by default cannot access anything outside of that directory" approach.
That makes sense if the application is the only program that needs to interact with the data. For example: If you have a drawing or photo editing program. You might have downloaded an image from the internet or from your camera. Then you make some edits. Afterwards you want to send the image to someone else via e-mail, which is another program.
Can't it request and be granted that permission, transparently to the app?
E.g. the app does EnumerateDirectories("~/photos") then without requiring modification to the app, the call is interecpted, the user is presented with a permission request UI, and once granted, the app continues?
At least that's how I'd thought it would work. Perhaps this isn't viable?
Apps built with a toolkit which ships its own filepicker will immediately attempt to enumerate directories in `/`, `/home`, and probably a few other places.
Apps with a config file will often try to read `~/.config/myapp` and also `~/.myapp/config` and maybe one or two other places.
How many permission prompts will users tolerate?
It’s how sandboxed Mac apps work today.
Tech debt, primarily. Flatpak is designed to be able to package apps not designed with it in mind.
If neither compatibility nor resources are of concern then integrating true Mandatory Access Control into both the UX and the entire tech stack would be the best way forward.
Same prefer, although I'm not sure what you mean by "installing changes data in places on my disk"?
Nothing should change, all installations and addons go to the ~/.var directory. When you launch the application, yes it can start reading and writing to arbitrary places on disk, which is why I make it a habit of first launching Flatseal to modify permissions and know exactly what it can and can't do and reach.
I actually vastly prefer this methodology with what we have right now, but if it or something else adopted an application/directory methodology as you described I'd be elated.
I'd prefer that too. Preferrably with permission popups for requesting folder access outside of it. Shared libraries / whatever flatpak calls them could live at a central symlinked location?
Isn't that exactly how it's supposed to work, though? When I install a flatpak app for my user, it gets put into a standard location as a directory and by default has no access to filesystem other than the apps own config and data dirs (can't remember the paths). The fact that many apps choose to require excess permissions and can then bypass standard locations is a different matter
I use podman for things like this, works perfect until you want desktop applications but you can hack it about a bit to work fine with pipewire and Xephyr and you have. I feel like a lot of these desktop container systems are horrible and are quite hostile to configuring in the way you want around permissions and such and podman or docker does a better job.
I’m thankful for the STF. Germany is one of the few countries doing something. But it is not strategic software-development.
The how planet needs Linux, BSD, cURL, ffmpeg, Flatpak. We need to ensure that this work for the people.We feed for 30 years constantly money into monopolies. We shall feed the next century constantly money into things the people need.
Many developers of Linux and GCC are paid. Because companies decided it is necessary.
Well put.
Would it make more sense if this Sovereign Tech Agency behaved less like a Sovereign Tech Fund and simply hired the developers? Or is civil servants developing OSS commodities too much of a heresy?
Well said.
On your last point, I'd love one day to see that OSS developers are paid because society benefits from their work.
We do all this self-congratulation around funding OSS companies and then end up with OSS companies that exist only thanks to government subsidization. Why? Isn’t governmental control over funding what we hate about Microsoft? What is so bad about letting real customers decide which companies need funding?
I loved Flatpak until I started building a MiniPC with a 112 GB internal disk for HTPC usage... Then I felt the pain of having to get all slightly different dependency versions for each little program I wanted.
The box' cost already topped the project's budget so no new disk for it. I'm back to "proper .deb packaging please"
A lot of Flatpak's design is a great prototype, but it's somewhat worrying (for the ecosystem in general) that this was taken as a final design and being pushed out in all directions.
Portals are just a terrible design for a security boundary: all interfaces clobbered up into one huge daemon, which also deals with a lot of the internals of Flatpak/Snap. If you want your sandbox to use portals, you can't, because it relies on internals of both of these sandboxing mechanisms. The devs have confirmed they won't implement an API for other sandboxing engines to integrate with them.
The whole system also deeply intermixes the package manager and sandboxing engine — to the point where you can't use the sandboxing engine with your favourite package manager, and you can't use the package manager without the sandboxing engine.
It seems that the mentality is: all other distributions are irrelevant, all other sandboxing engines are unsupported.
And then desktop applications start having first-class integration with Flatpak, and start having issues everywhere else.
You already need to set up Flatpak's daemons for using some features in Firefox (like screen sharing, where the native interfaces aren't supported), and it seems that the plan is to do the same for other features.
In the beginning, Flatpak was seen as savior for the Linux desktop ecosystem by making more applications available for more distributions, possibly packaged by the upstream maintainer, but they didn't realize that Flatpak resp. Flathub are actually just another distro with its own builds, repository, package manager, package format and community.
On the security side it was also seen as the only way forward, but it's just opt-in sandboxing. That's still possible to achieve without flatpak by using the underlying sandboxing tool (bubblewrap), but not as user friendly as using the flatpak provided defaults.
This is true. I wrote a sandbox for applications shipped on an immutable distro last month and it uses all the same portals just fine but no ostree/flatpak whatsoever.
You also can have separate portals implemented with different processes if you, you know, use d-bus properly.
flatpak is unsustainable
My trust in Flatpak diminished after installing the book reader Calibre and finding that despite the sandboxing Calibre was given blanket access to my drive. Apparently a quirk of the developer behind Calibre insisting upon it. No warnings or communication of the exception were given. All trust I had in Flatpak was eroded from that moment on. Curious about the podman options or similar. Having desktop apps in a container with selective access to system resources seems like it would be more secure and configurable if configured correctly. Flatpak as it stands seems to be a legacy solution to what should be a container and namespacing solution.
Don't know how you installed it, but required permissions are usually shown and warned about. The CLI could be clearer, though, but shows that host filesystem access is granted to calibre when it prompts to install
Permissions being granted implicitly is awful for security.
During installation they're _mentioned_ but the you can't pick which permissions to grant. If the developer requested it, its granted by default.
There are third party tools to tinker with permissions, but even those tools follow a "implicit grant first, revoke later" model, mostly because of how Flatpak implicitly grants permissions.
That’s what the kasmweb images on dockerhub are - desktop apps containerised
> No warnings or communication of the exception were given. All trust I had in Flatpak was eroded from that moment on
This is just wrong. Clients like the flathub website or gnome software show the risk posed by wide ranging access to local files, but Flatpak has to support legacy applications that don't use portals yet and thus they can't block applications having those permissions
https://flathub.org/en-GB/apps/com.calibre_ebook.calibre
> calibre is potentially unsafe
> Full file system read/write access
> Can read and write all data on the file system
Waste of money.
"For Modal, a robust app sandboxing story is essential to creating a Free Software OS that is competitive with modern mobile platforms."
Why? Focus should be desktop, not mobile.
We have enough mobile stuff that creeped in already.
This is focus on desktop. They just want as good app sandboxing as it is on mobile platforms.
I really like flatpaks to install desktop applications, as mentioned in some other comments the sandbox is sometimes poked full of holes because some applications don't use XDG desktop protals and need full filesystem access. If you are really concerened about this, you can use flatseal to limit the access that the application has.
If you prefer other ways of installing your software, that fine. But I really hope flatpaks continue improving and become the de facto way of installing desktop applications across all Linux distributions. For a normal, non-technical user installing and updating software should be easy, and I believe that flatpak provides this.
I'd rather they invested €500k in contributing to the maintenance of distribution packages so I don't need to deal with Flatpak (on Debian here).
So what? I would rather they made Flatpak better so we have unified gui app system.
I like the idea behind Flatpak and the ability to sandbox applications. What I don't understand is why they chose to lock the build process so tightly to Linux.
I'm currently on macOS, and while I can cross-compile applications, I can't actually bundle them as Flatpaks. For that, I need `flatpak-builder`, which is so deeply coupled to Linux itself that I don't think it can realistically run on other platforms.
Snaps have a similar issue with `snapcraft`. However, you can still build a snap manually with `mksquashfs`, whereas I haven't found an equivalent low-level option for Flatpak. I may be missing something, though, and I'm still looking.
I use bubblewrap directly, never liked Flatpak.
Same except for Steam. Hope this money revitalizes bubblewrap's development, it'd be nice to get proper signal handling cleanup up then merged (even util-linux's unshare has it, these days).
Maybe I am too propagandized, but honestly after going Nix I can’t help but feel like this stuff is fundamentally a waste of time
Only issue is with Nix as a long time user, it does not provide a standard way to run your nix builds in some kind of container, there are so many different competing third party systems and some first party systems built in nixpkgs it's self like building oci or docker containers or running systemd containers or even building qcow2 images, each with their own draw back and positives.
More and more I have found myself simply using podman and dockerfiles finding that building nix systems simply gets error prone and annoying and all the containerization systems leave a lot to be desired. Though I have some custom scripts for utilizing btrfs snapshots to create different nix store snap shots for containers or vms running with nix stores with virtiofs. This works quite well but not ready to be released and fiddly when things break and requires BTRFS.
I do agree flatpak and friends are not great though.
Nix is always doing its own thing. The community is fragmented and there are no enforced packaging conventions. They have a "best practices" page that lists language features you're not supposed to use because they break reproducible builds, aka the whole point of Nix. And they don't even restrict network access by default.
It's also not doing runtime sandboxing at all. Isolated builds protect you from supply chain attacks but not malware or vulns in the actual code, and they don't do anything for closed source apps.
Flatpak runs everything in a container with access limited to what is declared in the manifest and you can restrict it even more with Flatseal. It's not as secure as a Firecracker VM but it works way better than any other package system on Linux when it comes to security and distro independence.
Maybe I am vastly underestimating it, but I could imagine this being buildable atop of nix quite straightforward?
Yes because both flatpak and nix use bubblewrap and linux. So it is indeed possible to build it with bubblewrap.
GUI apps on NixOS rarely care about sandboxing so while you can do it yourself i bet almost noone does. Flatpak is trying to give you basic protections out of the box.
Agreed. With all the improvements in namespacing I’m seeing the potential of all desktop apps being namespaced in a reasonable way, where filesystem access to e.g. /home is controlled through a kernel-hook prompt callback, with something like “always allow for this directory” etc. That’d be so awesome!
Flatpak is great for installing, but as a happy Aurora user, it’s annoying and it breaks things all the time. Every desktop app i use has some broken feature. Sandboxes as another permissions panel suck. Simple browser-like permissions that allow prompted overwrite would be WAY better!
Now i have media organizer programs that deletes my files if i try to write on a networked drive. Games that can’t see the controller. Chat apps that can’t see attachments. Music app that can’t save at all. Good luck accessing any binary and using it in a script.
To be honest i don't see how having flatpack going to help the (european/german) "sovereign tech" initiative.
A waste of money if you ask me.
I think there are much more important issues that should deserve money and attention.
Flatpaks are a common packaging mechanism used on immutable systems. They are very attractive (conceptually) for large org deployments, so I can totally see the appeal here