5 ms·

Sovereign Tech Agency invests €500k in Flatpak

274 points by eigenspace 1mo ago

TekMol 1mo ago
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.
- kodoman 1mo ago
  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.
  - jbstack 1mo ago
    > Xephyr Given that X11 is becoming more and more obsolete over time, what's the Wayland option?
    - kodoman 1mo ago
      Not using Wayland I am not 100% sure, I think Xephyr works in XWayland and I think their is a similar tool to Xephyr for setting up an embedded Wayland session (I would have thought this is even easier and more elegant in wayland but not sure). So could be even better. I personally use X11 as I am on exwm and exwm does not support wayland and no alternative to it does AFAIK (I think theirs a POC floating around somewhere). Also I know X11 even though it's a bit crap in many ways it's the devil I know.
  - Timon3 1mo ago
    I've had very good experiences with desktop applications in containers using Distrobox & podman. It handles all the integration into the host system, so video, audio etc. just work. The default configuration is probably too well-integrated if you're looking to use it as a sandbox, but there should be ways to turn parts off.
- schmorptron 1mo ago
  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?
- vaylian 1mo ago
  > 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.
  - alkonaut 1mo ago
    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?
    - weiran 1mo ago
      It’s how sandboxed Mac apps work today.
    - danielheath 1mo ago
      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?
      - alkonaut 1mo ago
        I'm assuming that the config scenario can be re-routed so the app thinks its opening that file but instead gets routed to different ones transparently. If the file picker enumerates N different directories immediately (which aren't the active one) that causes a problem yes. I guess allowing enumeration access _anywhere_ (but not file read access) isn't a necessarily a problem.
      - 1mo ago
- lunar_rover 1mo ago
  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.
- meibo 1mo ago
  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.
  - Gigachad 1mo ago
    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.
    - mike_hearn 1mo ago
      Apple has much better backwards compatibility than Linux. The APIs haven't changed much since the Carbon->Cocoa transition 25 years ago, and SwiftUI (but that's optional). The impact of app sandboxing on developers was small - and sandboxing is universal on macOS now, there are only different levels of sandboxing but no such thing as unsandboxed apps anymore. Apple's introduction of sandboxing to an app ecosystem designed without it was a masterclass in OS design that goes unappreciated in our industry. Nobody else pulled that off. It's no exaggeration to say that macOS is the most secure desktop OS by a long way, it's not even close. Linux trails far behind in third place. They achieved this via: • Extremely long term planning (multi-decade timescales). • Extremely good systems design. • Incremental change, so developers always had a digestable chunk of work at any given point. The work needed was smeared out over decades, not drop-kicked onto people in ways that left them flailing. • Good developer relations work to ensure devs got help quickly if they hit issues. At no point has Apple's security team had to change course, reverse a prior decision, redesign a subsystem or fail to meet their goals. Everything has slowly clicked together so smoothly most people, even devs, didn't even notice it happening. The sad thing is, the engineers who pulled this off are largely unknown. The head of Apple Security came from the One Laptop Per Child project and deserves a lot of credit, but much of the careful detailed design that makes the Apple security architecture work is done by unsung heroes. One guy was known only by the name "Perry the Cynic"! Edit: I did some searches. Perry the Cynic was Peter Kiehtreiber, who seems to now be retired.
- bashZorina_09 1mo ago
  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.
- kalaksi 1mo ago
  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
  - cassianoleal 1mo ago
    > The fact that many apps choose to require excess permissions and can then bypass standard locations is a different matter It's not when that choice is never presented to the user.
- pinkwah 1mo ago
  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.
  - hattar 1mo ago
    > 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)
    - NekkoDroid 1mo ago
      > 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).
- 654wak654 1mo ago
  I think most people making a good ol' desktop program these days do it because they need very liberal access to the filesystem, or access to weird hardware peripherals. If they don't need either they could just put their app on the web! Looking at the top apps on Mint's "app store" shows this trend too, everything is an editor of sorts (code editors, photo editors, video editors, audio editors, painting, modelling etc.)
- VCFundedGenYer 1mo ago
  This is false. $HOME/.var/app is where it's stored. Use flatseal (or terminal) to adjust permissions.
- Shorel 1mo ago
  As everyone else has written, two very different things are being mentioned n your last paragraph: First, the application should be just a directory on disk. I wholeheartedly agree, this should be the way to install applications, and OSX has shown that this works wonders. Second: it being limited to only read and write files in that directory. No, that's the wrong idea, the application should be associated with some extensions and should be able to edit documents in your Documents directory. It makes no sense otherwise.
koe123 1mo ago
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
- andsens 1mo ago
  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!
- kodoman 1mo ago
  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.
- tancop 1mo ago
  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.
blizdiddy 1mo ago
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.
znpy 1mo ago
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.
- moooo99 1mo ago
  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
Nux 1mo ago
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.
- omnimus 1mo ago
  This is focus on desktop. They just want as good app sandboxing as it is on mobile platforms.
- deleted 1mo ago
  [deleted]
- akaliff 1mo ago
  I don't think the point is to create mobile apps, rather than reaching the same level of sandboxed separation between the apps and other components of the OS that exists on iOS and android. Including easily handling permissions for apps etc.
minimeow 1mo ago
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.
- jarym 1mo ago
  That’s what the kasmweb images on dockerhub are - desktop apps containerised
- kalaksi 1mo ago
  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
  - WhyNotHugo 1mo ago
    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.
    - kalaksi 1mo ago
      It's explicit in the sense that you choose to grant those permissions, but I get what you mean. Android apps also used to be more like that but nowadays you can have more control when to grant access to what. Flatpak apps can also explicitly request access through portals, but many apps probably haven't put the effort to properly use the sandboxing features and instead try to request excessive permissions beforehand.
j1elo 1mo ago
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"
- Anonyneko 1mo ago
  Use cases naturally differ, but I'd much rather use more storage than hit yet another unresolvable dependency issue.
  - skydhash 1mo ago
    I think projects today are too trigger happy about updating dependencies and using dependencies that are too volatile. IIRC, the task runner just couldn’t be built on debian 12 because its rust package was too “old”. Just two years have passed since the version freeze.
  - dbdr 1mo ago
    Nix offers the best of both worlds on this aspect: each program can depend on the exact version of a library it needs and several versions can coexist on the disk, but if two programs depend on the exact same version, it is stored only once.
    - bronson 1mo ago
      Same with Flatpak.
sdcfgy 1mo ago
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).
- omnimus 1mo ago
  So what? I would rather they made Flatpak better so we have unified gui app system.
JanisErdmanis 1mo ago
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.
- yjftsjthsd-h 1mo ago
  I do tend to agree that in an deal world it should be possible to cross-build flatpaks, but: 1. You can't then test the output to make sure it even works. 2. As a practical point, you could just do it in a VM
regexorcist 1mo ago
I use bubblewrap directly, never liked Flatpak.
- a-french-anon 1mo ago
  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).
  - ximm 1mo ago
    I have bad news for you: The flatpak developers plan to stop using bubblewrap. They say it is no longer necessary because most distros now support unprivileged user namespaces. https://youtu.be/NsVhkz2Xl0E?si=-ypxvTlRukCZLql9 https://youtu.be/NsVhkz2Xl0E?si=-ypxvTlRukCZLql9
    - internet_points 1mo ago
      I tried to find out what unprivileged user namespaces was, and all I can find is people talking loudly about how insecure they are, e.g. https://secureblue.dev/articles/userns https://secureblue.dev/articles/userns But does bubblewrap also use them?
    - a-french-anon 1mo ago
      Bubblewrap is a CLI interface for these, you know? It's been some time since bwrap recommended avoiding their SUID wrapper.
      - NekkoDroid 1mo ago
        From my knowledge its a yes and no. One of the "benefits" of bwrap was that it was a SUID binary and thus maximised compatibility with systems that disabled unprivileged user namespaces. With that barrier gone you can implement a more tailored sandbox to the usecase instead of working around limitations in bwrap. Like, all things considered, bubblewrap as a whole isn't that much code (quick check seems like ~6k LOC) and does somewhat limit the API you can work with.
banger180 1mo ago
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.
WhyNotHugo 1mo ago
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.
- Vogtinator 1mo ago
  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.
  - audidude 1mo ago
    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.
- 1mo ago
ho_schi 1mo ago
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.
- sdcfgy 1mo ago
  Well said. On your last point, I'd love one day to see that OSS developers are paid because society benefits from their work.
- jimbob45 1mo ago
  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?
  - hvb2 1mo ago
    > What is so bad about letting real customers decide which companies need funding? Because human nature means you won't get paid when something is free. There's donate options but those are not a reliable source of money. Unless your software is big enough that you can make money through support contracts, I don't see how you can keep the lights on while being paid
    - carlosjobim 1mo ago
      Then charge a fair price for your work (ie the software you deliver). That's the completely fair solution for all sides of the equation. People who don't want your stuff don't get stuck with the bill and people who do want your stuff aren't taking it for free.
oytis 1mo ago
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.
- ximm 1mo ago
  Flatpak itself might not survive, but the underlying protocols (portals, security contexts in wayland, pipewire, and d-bus, systemd-appd, …) are relevant for sandboxing on linux as a whole. While I do not personally with every design decision, I still think this is useful and valuable work.
- eigenspace 1mo ago
  Flatpak is proving to be a very important piece of underlying infrastructure if government agencies want to switch to Linux computers running distributed graphical applications for their workers. Yes, it has major problems, and you might be right it won't exist in 10 years, but the point of this grant is to fund their attempt at fixing their problems and getting it to a point where it's better infrastructure that can survive into the future.
goodpoint 1mo ago
flatpak is unsustainable
aussieguy1234 1mo ago
For these Flatpak improvements, are they also going to end up in bubblewrap?
robin_reala 1mo ago
The Soverign Tech Agency are currently hiring for a Director of Technology. Definitely a dream job for someone. https://www.sovereign.tech/jobs/director-of-technology https://www.sovereign.tech/jobs/director-of-technology
- xyzelement 1mo ago
  "Director of Technology (all genders)" I guess I hadn't looked at German want ads ever. Is mentioning the gender as the most important qualification - literally in the headline - standard practice? Also I guess Berlin is cheaper but seeing 99.5k EUR as the upper bound salary for a director role is a bit jarring. I guess it's just the "otherness" of it but the DEI statement is shaped oddly to an American eye too. Please tell us if you are black or disabled but not if you are old or married.
  - herrherrmann 1mo ago
    The “(all genders)” bit is probably just based on the fact that they translated the German job ad (in German you have to be more explicit with the male/female/all versions of titles, because the default is usually just the male form). So, it’s not a qualification, but just a way to be inclusive to applicants of all genders (we have a diversity problem in our industry). The salary is bound to the limits of the public salary bands (collective agreement), that’s where the maximum comes from. (And, you can live quite well in Berlin with ~100k € per year.)
    - xyzelement 1mo ago
      Thank you!
    - robin_reala 1mo ago
      Yep, the German version’s heading is a bit of a mouthful: Technische*r Direktor*in (m/w/d/x) Wir suchen eine*n technische*n Direktor*in, der*die die Technologie- und Forschungsstrategie der Sovereign Tech Agency federführend gestaltet und vorantreibt. https://www.sovereign.tech/de/stellenangebote/technische_r-direktor_in* https://www.sovereign.tech/de/stellenangebote/technische_r-d...
vrighter 1mo ago
Flatpak: adjust permissions here, workaround there, different workaround for a different DE. My solution: I'm very careful about what I run, but when I do run it, I just do. No fanfare. No security theater.
aradar46 1mo ago
And Omarchy gets 7mi for being ....you know
- metaltyphoon 1mo ago
  10… it is 10 now
EffrafaxOfWug 1mo ago
I avoid flatpaks and snaps as much as I can. Here is a little blog post from 2021 that lists some of the huge issues flatpaks have https://ludocode.com/blog/flatpak-is-not-the-future https://ludocode.com/blog/flatpak-is-not-the-future If you want to sandbox your programs highly recommend looking at firejail.
megous 1mo ago
Dunno why people try to push app isolation on Linux desktop. It'd be better and more comfortable to make task/workspace isolation easier. You have all your apps installed system wide as usual, and you isolate processes in sandbox per your current task. Isolating individual apps and having to deal with permission prompts and protals, and persistence of permissions is uh, not very user friendly anyway. Feels like this whole flatpak and similar mechanisms is more oriented on bringing in untrusted apps, rather than anything actually comfortable and useful as far as "work" isolation needs go.
- bronson 1mo ago
  > ... and you isolate processes in sandbox per your current task. Oh is that all? If you start writing up the requirements to make that happen (without permission prompts and portals, right?), I think you'll find that would be even more difficult than app isolation and have even more backward compatibility issues.
  - megous 1mo ago
    Actually I use that approach daily and it has very few usability issues, at least in my mostly terminal based workflow. GUI apps show me environment to which they belong in the title bar. Happy with that. Can't imagine how per-app isolation would even work for me. Sounds like something inspired from android world where there's no such thing as having the same app run mutliple times on different workspaces/windows, etc. and the usability correspondingly suffers. Portal thing even bit me recently. I leave dbus and window manager socket in the sandbox, so I can use GUI apps without too much trouble, and a few months back firefox started showing me files from outside the sandbox and hiding files in the sandbox in file save dialog, which confused the hell out of me, until I found out someone decided to add a remote file access via some dbus service or whatever. Dangerous. I had to remove dbus socket sharing completely from the sandbox at some inconvenience.
trlphj 1mo ago
No one has been fired for sponsoring an IBM (RedHat) project. Well done!
kombine 1mo ago
Better money spent than on Omarchy.
ndiddy 1mo ago
It's great that there's more investment being put into Flatpak development. The page mentions adding more granular permissions, which is nice to see. However, another necessary improvement is actually making it possible for software to incorporate these new granular permissions in a backwards compatible manner. As one example, I maintain a game on Flathub that supports game controllers as an input device. By default, access to game controllers are blocked in the sandbox just like access to any other piece of hardware. The only way to use game controllers is to mark your software as requiring a blanket permission that grants access to all devices connected to the user's system. The Flatpak maintainers realized this is problematic, so a few years ago they added a permission to specifically request access to input devices (https://github.com/flatpak/flatpak/pull/5481 https://github.com/flatpak/flatpak/pull/5481). However, because the permissions aren't backwards compatible, and because there's LTS distros under active support with old Flatpak versions released before the permission was added, you aren't allowed to use this permission on Flathub, only the blanket "all devices" permission. As a result, Flathub lists my game as "potentially unsafe" because it "can access hardware devices such as webcams and game controllers" since the only other option was disabling controller support on the Flatpak version of the game. If they figure out a way to implement the new permissions so they can fall back to the broader kind on old Flatpak versions, this would be a massive improvement over the current situation. Otherwise you'll have to wait 10+ years before you can use newly added permissions because the only other option is breaking Flatpak on whatever ancient Ubuntu or RHEL version is still under support.
redsocksfan45 1mo ago
[dead]

274 points by eigenspace 1mo ago

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.

kodoman 1mo ago
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.
- jbstack 1mo ago
  > Xephyr Given that X11 is becoming more and more obsolete over time, what's the Wayland option?
  - kodoman 1mo ago
    Not using Wayland I am not 100% sure, I think Xephyr works in XWayland and I think their is a similar tool to Xephyr for setting up an embedded Wayland session (I would have thought this is even easier and more elegant in wayland but not sure). So could be even better. I personally use X11 as I am on exwm and exwm does not support wayland and no alternative to it does AFAIK (I think theirs a POC floating around somewhere). Also I know X11 even though it's a bit crap in many ways it's the devil I know.
- Timon3 1mo ago
  I've had very good experiences with desktop applications in containers using Distrobox & podman. It handles all the integration into the host system, so video, audio etc. just work. The default configuration is probably too well-integrated if you're looking to use it as a sandbox, but there should be ways to turn parts off.
schmorptron 1mo ago
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?
vaylian 1mo ago
> 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.
- alkonaut 1mo ago
  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?
  - weiran 1mo ago
    It’s how sandboxed Mac apps work today.
  - danielheath 1mo ago
    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?
    - alkonaut 1mo ago
      I'm assuming that the config scenario can be re-routed so the app thinks its opening that file but instead gets routed to different ones transparently. If the file picker enumerates N different directories immediately (which aren't the active one) that causes a problem yes. I guess allowing enumeration access _anywhere_ (but not file read access) isn't a necessarily a problem.
    - 1mo ago
lunar_rover 1mo ago
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.
meibo 1mo ago
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.
- Gigachad 1mo ago
  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.
  - mike_hearn 1mo ago
    Apple has much better backwards compatibility than Linux. The APIs haven't changed much since the Carbon->Cocoa transition 25 years ago, and SwiftUI (but that's optional). The impact of app sandboxing on developers was small - and sandboxing is universal on macOS now, there are only different levels of sandboxing but no such thing as unsandboxed apps anymore. Apple's introduction of sandboxing to an app ecosystem designed without it was a masterclass in OS design that goes unappreciated in our industry. Nobody else pulled that off. It's no exaggeration to say that macOS is the most secure desktop OS by a long way, it's not even close. Linux trails far behind in third place. They achieved this via: • Extremely long term planning (multi-decade timescales). • Extremely good systems design. • Incremental change, so developers always had a digestable chunk of work at any given point. The work needed was smeared out over decades, not drop-kicked onto people in ways that left them flailing. • Good developer relations work to ensure devs got help quickly if they hit issues. At no point has Apple's security team had to change course, reverse a prior decision, redesign a subsystem or fail to meet their goals. Everything has slowly clicked together so smoothly most people, even devs, didn't even notice it happening. The sad thing is, the engineers who pulled this off are largely unknown. The head of Apple Security came from the One Laptop Per Child project and deserves a lot of credit, but much of the careful detailed design that makes the Apple security architecture work is done by unsung heroes. One guy was known only by the name "Perry the Cynic"! Edit: I did some searches. Perry the Cynic was Peter Kiehtreiber, who seems to now be retired.
bashZorina_09 1mo ago
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.
kalaksi 1mo ago
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
- cassianoleal 1mo ago
  > The fact that many apps choose to require excess permissions and can then bypass standard locations is a different matter It's not when that choice is never presented to the user.
pinkwah 1mo ago
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.
- hattar 1mo ago
  > 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)
  - NekkoDroid 1mo ago
    > 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).
654wak654 1mo ago
I think most people making a good ol' desktop program these days do it because they need very liberal access to the filesystem, or access to weird hardware peripherals. If they don't need either they could just put their app on the web! Looking at the top apps on Mint's "app store" shows this trend too, everything is an editor of sorts (code editors, photo editors, video editors, audio editors, painting, modelling etc.)
VCFundedGenYer 1mo ago
This is false. $HOME/.var/app is where it's stored. Use flatseal (or terminal) to adjust permissions.
Shorel 1mo ago
As everyone else has written, two very different things are being mentioned n your last paragraph: First, the application should be just a directory on disk. I wholeheartedly agree, this should be the way to install applications, and OSX has shown that this works wonders. Second: it being limited to only read and write files in that directory. No, that's the wrong idea, the application should be associated with some extensions and should be able to edit documents in your Documents directory. It makes no sense otherwise.

koe123 1mo ago

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

andsens 1mo ago
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!
kodoman 1mo ago
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.
tancop 1mo ago
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.

blizdiddy 1mo ago

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.

znpy 1mo ago

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.

moooo99 1mo ago
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

Nux 1mo ago

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.

omnimus 1mo ago
This is focus on desktop. They just want as good app sandboxing as it is on mobile platforms.
deleted 1mo ago
[deleted]
akaliff 1mo ago
I don't think the point is to create mobile apps, rather than reaching the same level of sandboxed separation between the apps and other components of the OS that exists on iOS and android. Including easily handling permissions for apps etc.

minimeow 1mo ago

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.

jarym 1mo ago
That’s what the kasmweb images on dockerhub are - desktop apps containerised
kalaksi 1mo ago
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
- WhyNotHugo 1mo ago
  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.
  - kalaksi 1mo ago
    It's explicit in the sense that you choose to grant those permissions, but I get what you mean. Android apps also used to be more like that but nowadays you can have more control when to grant access to what. Flatpak apps can also explicitly request access through portals, but many apps probably haven't put the effort to properly use the sandboxing features and instead try to request excessive permissions beforehand.

j1elo 1mo ago

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"

Anonyneko 1mo ago
Use cases naturally differ, but I'd much rather use more storage than hit yet another unresolvable dependency issue.
- skydhash 1mo ago
  I think projects today are too trigger happy about updating dependencies and using dependencies that are too volatile. IIRC, the task runner just couldn’t be built on debian 12 because its rust package was too “old”. Just two years have passed since the version freeze.
- dbdr 1mo ago
  Nix offers the best of both worlds on this aspect: each program can depend on the exact version of a library it needs and several versions can coexist on the disk, but if two programs depend on the exact same version, it is stored only once.
  - bronson 1mo ago
    Same with Flatpak.

sdcfgy 1mo ago

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).

omnimus 1mo ago
So what? I would rather they made Flatpak better so we have unified gui app system.

JanisErdmanis 1mo ago

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.

yjftsjthsd-h 1mo ago
I do tend to agree that in an deal world it should be possible to cross-build flatpaks, but: 1. You can't then test the output to make sure it even works. 2. As a practical point, you could just do it in a VM

regexorcist 1mo ago

I use bubblewrap directly, never liked Flatpak.

a-french-anon 1mo ago
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).
- ximm 1mo ago
  I have bad news for you: The flatpak developers plan to stop using bubblewrap. They say it is no longer necessary because most distros now support unprivileged user namespaces. https://youtu.be/NsVhkz2Xl0E?si=-ypxvTlRukCZLql9 https://youtu.be/NsVhkz2Xl0E?si=-ypxvTlRukCZLql9
  - internet_points 1mo ago
    I tried to find out what unprivileged user namespaces was, and all I can find is people talking loudly about how insecure they are, e.g. https://secureblue.dev/articles/userns https://secureblue.dev/articles/userns But does bubblewrap also use them?
  - a-french-anon 1mo ago
    Bubblewrap is a CLI interface for these, you know? It's been some time since bwrap recommended avoiding their SUID wrapper.
    - NekkoDroid 1mo ago
      From my knowledge its a yes and no. One of the "benefits" of bwrap was that it was a SUID binary and thus maximised compatibility with systems that disabled unprivileged user namespaces. With that barrier gone you can implement a more tailored sandbox to the usecase instead of working around limitations in bwrap. Like, all things considered, bubblewrap as a whole isn't that much code (quick check seems like ~6k LOC) and does somewhat limit the API you can work with.

banger180 1mo ago

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.

WhyNotHugo 1mo ago

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.

Vogtinator 1mo ago
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.
- audidude 1mo ago
  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.
1mo ago

ho_schi 1mo ago

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.

sdcfgy 1mo ago
Well said. On your last point, I'd love one day to see that OSS developers are paid because society benefits from their work.
jimbob45 1mo ago
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?
- hvb2 1mo ago
  > What is so bad about letting real customers decide which companies need funding? Because human nature means you won't get paid when something is free. There's donate options but those are not a reliable source of money. Unless your software is big enough that you can make money through support contracts, I don't see how you can keep the lights on while being paid
  - carlosjobim 1mo ago
    Then charge a fair price for your work (ie the software you deliver). That's the completely fair solution for all sides of the equation. People who don't want your stuff don't get stuck with the bill and people who do want your stuff aren't taking it for free.

oytis 1mo ago

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.

ximm 1mo ago
Flatpak itself might not survive, but the underlying protocols (portals, security contexts in wayland, pipewire, and d-bus, systemd-appd, …) are relevant for sandboxing on linux as a whole. While I do not personally with every design decision, I still think this is useful and valuable work.
eigenspace 1mo ago
Flatpak is proving to be a very important piece of underlying infrastructure if government agencies want to switch to Linux computers running distributed graphical applications for their workers. Yes, it has major problems, and you might be right it won't exist in 10 years, but the point of this grant is to fund their attempt at fixing their problems and getting it to a point where it's better infrastructure that can survive into the future.

goodpoint 1mo ago

flatpak is unsustainable

aussieguy1234 1mo ago

For these Flatpak improvements, are they also going to end up in bubblewrap?

robin_reala 1mo ago

The Soverign Tech Agency are currently hiring for a Director of Technology. Definitely a dream job for someone. https://www.sovereign.tech/jobs/director-of-technology https://www.sovereign.tech/jobs/director-of-technology

xyzelement 1mo ago
"Director of Technology (all genders)" I guess I hadn't looked at German want ads ever. Is mentioning the gender as the most important qualification - literally in the headline - standard practice? Also I guess Berlin is cheaper but seeing 99.5k EUR as the upper bound salary for a director role is a bit jarring. I guess it's just the "otherness" of it but the DEI statement is shaped oddly to an American eye too. Please tell us if you are black or disabled but not if you are old or married.
- herrherrmann 1mo ago
  The “(all genders)” bit is probably just based on the fact that they translated the German job ad (in German you have to be more explicit with the male/female/all versions of titles, because the default is usually just the male form). So, it’s not a qualification, but just a way to be inclusive to applicants of all genders (we have a diversity problem in our industry). The salary is bound to the limits of the public salary bands (collective agreement), that’s where the maximum comes from. (And, you can live quite well in Berlin with ~100k € per year.)
  - xyzelement 1mo ago
    Thank you!
  - robin_reala 1mo ago
    Yep, the German version’s heading is a bit of a mouthful: Technische*r Direktor*in (m/w/d/x) Wir suchen eine*n technische*n Direktor*in, der*die die Technologie- und Forschungsstrategie der Sovereign Tech Agency federführend gestaltet und vorantreibt. https://www.sovereign.tech/de/stellenangebote/technische_r-direktor_in* https://www.sovereign.tech/de/stellenangebote/technische_r-d...

vrighter 1mo ago

Flatpak: adjust permissions here, workaround there, different workaround for a different DE. My solution: I'm very careful about what I run, but when I do run it, I just do. No fanfare. No security theater.

aradar46 1mo ago

And Omarchy gets 7mi for being ....you know

metaltyphoon 1mo ago
10… it is 10 now

EffrafaxOfWug 1mo ago

I avoid flatpaks and snaps as much as I can. Here is a little blog post from 2021 that lists some of the huge issues flatpaks have https://ludocode.com/blog/flatpak-is-not-the-future https://ludocode.com/blog/flatpak-is-not-the-future If you want to sandbox your programs highly recommend looking at firejail.

megous 1mo ago

Dunno why people try to push app isolation on Linux desktop. It'd be better and more comfortable to make task/workspace isolation easier. You have all your apps installed system wide as usual, and you isolate processes in sandbox per your current task. Isolating individual apps and having to deal with permission prompts and protals, and persistence of permissions is uh, not very user friendly anyway. Feels like this whole flatpak and similar mechanisms is more oriented on bringing in untrusted apps, rather than anything actually comfortable and useful as far as "work" isolation needs go.

bronson 1mo ago
> ... and you isolate processes in sandbox per your current task. Oh is that all? If you start writing up the requirements to make that happen (without permission prompts and portals, right?), I think you'll find that would be even more difficult than app isolation and have even more backward compatibility issues.
- megous 1mo ago
  Actually I use that approach daily and it has very few usability issues, at least in my mostly terminal based workflow. GUI apps show me environment to which they belong in the title bar. Happy with that. Can't imagine how per-app isolation would even work for me. Sounds like something inspired from android world where there's no such thing as having the same app run mutliple times on different workspaces/windows, etc. and the usability correspondingly suffers. Portal thing even bit me recently. I leave dbus and window manager socket in the sandbox, so I can use GUI apps without too much trouble, and a few months back firefox started showing me files from outside the sandbox and hiding files in the sandbox in file save dialog, which confused the hell out of me, until I found out someone decided to add a remote file access via some dbus service or whatever. Dangerous. I had to remove dbus socket sharing completely from the sandbox at some inconvenience.

trlphj 1mo ago

No one has been fired for sponsoring an IBM (RedHat) project. Well done!

kombine 1mo ago

Better money spent than on Omarchy.

ndiddy 1mo ago

It's great that there's more investment being put into Flatpak development. The page mentions adding more granular permissions, which is nice to see. However, another necessary improvement is actually making it possible for software to incorporate these new granular permissions in a backwards compatible manner. As one example, I maintain a game on Flathub that supports game controllers as an input device. By default, access to game controllers are blocked in the sandbox just like access to any other piece of hardware. The only way to use game controllers is to mark your software as requiring a blanket permission that grants access to all devices connected to the user's system. The Flatpak maintainers realized this is problematic, so a few years ago they added a permission to specifically request access to input devices (https://github.com/flatpak/flatpak/pull/5481 https://github.com/flatpak/flatpak/pull/5481). However, because the permissions aren't backwards compatible, and because there's LTS distros under active support with old Flatpak versions released before the permission was added, you aren't allowed to use this permission on Flathub, only the blanket "all devices" permission. As a result, Flathub lists my game as "potentially unsafe" because it "can access hardware devices such as webcams and game controllers" since the only other option was disabling controller support on the Flatpak version of the game. If they figure out a way to implement the new permissions so they can fall back to the broader kind on old Flatpak versions, this would be a massive improvement over the current situation. Otherwise you'll have to wait 10+ years before you can use newly added permissions because the only other option is breaking Flatpak on whatever ancient Ubuntu or RHEL version is still under support.

redsocksfan45 1mo ago

[dead]