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). 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.
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.
I don't really agree here. I think what they are doing is pretty strategic, especially given the relatively limited money they have.
There's basically two sides to funding software that are actually rather different
1. Accelerator phase: getting the software to a point where it can reasonably replace some foreign closed source enterprise option (i.e. feature devlopment). This sort of thing is often highly speculative. It should be project based, with concrete deliverables, and done with a non-permanent grant. If things go reasonably well, then there can be followup grants. This is what the STA focuses on, and is a major gap in the FOSS world.
2. Established phase: Once the software is actually ready for adoption (thanks to help from the STA!), and gets integrated into government functions, then the agencies that *use* the software should be setting up enterprise support contracts that give long-term support and stability to the projects they've adopted. A good example of this would be Nextcloud who has multiple such contracts with different parts of Germany (also other European organizations). This part is better off being done by the agency that *uses* the software, rather than having the STA do it. Some of these agencies do in fact also have internal software developers that work on Nextcloud.
I don't think it's a shortcoming of the STA that they're focused on point 1 rather than point 2, I think if they were forced to do both, they'd actually be less effective at what they're doing.
The STA is basically trying to fill the role that venture capital plays in getting a startup ready to take on customers, except the STA doesn't take an ownership stake, and they focus on FOSS.
> They don’t employ software-developers. No safety for the developers. No control over developers.
Thank god they don't employ them. It would be terrible for everyone involved, especially for the developers. The government in Germany is a terrible employer for someone with high work ethics and a dedication to their craft. They crush your soul with bureaucracy and drain your spirit with rules and regulation. On top of that, they pay is ridiculously bad. I'm a principle engineer at a private company and some government agency thought they could poach me with 4k a month, LOL, that's not enough to pay rent and put food on the table for a family of 3 in my city (remember, we pay ~50% in tax and social contributions).
The construction would be a private company that works with the government. That exists already - I had applied for one before - and the pay was completely competitive, for German salaries. 80K.
What kind of program was that? Permanent employment contract (no "Befristung") without any co-financing through private investors, private grants, or the company's revenue?
This might be possible with public grants, but I've never seen it. They usually come with additional strings attached, such as being a de minimis subsidy (limited to 300k in a rolling 3 year window), requiring private co-funding (e.g. 50% for the whole project), being limited to a couple of months or maybe 2-3 years max, etc., so for competitive pay, you must almost always rely on some kind of "mixed financing": every penny above the salary that TVöD allows must be acquired from sources other than the gran. ymmv, part of the lack of attractiveness of public funding is the fact that each program differs in a million different ways.
It was a normal developer position (with PhD bonus possibly) at a private enterprise that only worked on public projects. No Befristung, no other surprises I got aware of. I was also a bit surprised that this existed, because with private-public constructs like Fraunhofer there usually are the limitations you mentioned (and the low salary). Here the limitations probably didn't exist as the company was 100% private.
I don't think the Fellowship qualifies as "working for STF". These people are being paid/supported for the work they do in their own projects. They're not being paid to work on/work for STF to help them steer/analyze/control the other projects that are being funded.
EDIT: OPs comment can be understood in multiple ways: Should STF hire Developers to work on their own projects, or should they hire Developers to understand/guide/manage the funded projects in a better way.
>> The projects need to apply repeatingly for funding.
> Still better than no funding at all.
Exactly, plus no grantor I know operates on a blank check basis, its always budgeting, prioritisation, and new applications and grants are for a specific period, can come in tranches, etc. Just how these things work, Germany or not.
> Compensation is based on the collective agreement for the public sector in Germany (TVöD-Bund) and will range from €64,000 to €82,000 per year for a full-time position, including 30 days of vacation, depending on qualifications and experience.
LOL. That's €32,122 net for a full time position. And you're not even allowed to work from a place in southern Europe where you can actually live from that amount of money.
It's more like €40,000-50,000 after taxes and contributions to health care, social security and the German pension fund. Enough for a modest lifestyle in Germany. Many OSS contributors aren't motivated by money after all.
Go to https://www.nettolohn.de and enter 64000€, choose Berlin, keep the rest. That's not enough for a modest lifestyle for a family, proven by the fact that with such an income, you're already entitled for social benefits (Wohngeld) in an average German city of 200.000 inhabitants for a family of 4: https://www.wohngeld.org/einkommen/#Wohngeldtabellen_fuer_Mi...
This is the government telling you: you can come work full time for us, but you'll not be able to provide for your family, that's why you can stand in line with all those who don't work at all to claim your benefits.
The point isn't how much Google spends on stuff in general, it's their wallet. What's important is how much they contribute back to the development of the tools they actively use to fill that wallet.
They contribute a lot of open source software themselves, you can probably find a better example of a company benefitting from such but not contributing much
The crazy thing is that there is a model where governments / states / localities can migrate away from windows / Microsoft 365 ... and use part of the savings to fund open-source
if this was done across Europe we'd have sovereign open-source tech stack that is strong, well funded, and used by 10s of millions in the EU alone.
I have no idea why simple ideas like this are not persuade instead lots of incoherent, almost desperate distributed efforts are preferred.
ultimately I do believe that the bureaucrats in the EU are insanely disconnected from reality.
The process you're describing is underway. Schleswig-Holstein, Munich, Leon, and the Austrian military all come to mind as recent examples of that sort of migration, and then pivoting savings into support contracts for open source.
That process is super important yes, but what about cases where the relevant government bodies don't think the open source offering is ready yet for them?
That is where the STF steps in, and gives funding to open source projects so that they can develop to a point where their software is ready for stable adoption by governments.
this is what I mean by distributed, unconcentrated change.
you will never make meaningful progress by those initiatives, there should be an echo of the US investment in data centers or china's investment in EVs.
bigger, systematic, with immediate impact on the software / cloud stack in the EU first and globally.
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?
> is civil servants developing OSS commodities too much of a heresy
I see two problems here for Germany. First, the salaries of civil servants are regulated, and might be not what most developers, even German ones, expect. In addition civil servant status is bundled with privileges and duties that make it painful to lay it down. Most developers are used to job flexibility though, especially as, as I said, the salaries are not going to be great.
Second, there is a decision by the Constitutional Court that prohibits the state from competing with the market. Temporary grants to independent actors are among other things a way to work around it.
The first part boils down to any civil servant: inflexibility and lower wages aren't for everyone, but it should not be impossible to attract talent intrinsically motivated to contribute to public cause. Especially when it's OSS.
The second part is a bit closer to the heresy angle: new public management forbids competing with "free market". Of course, many EU governments have always found and used all kinds of loopholes to support "independent enterprises" like railways, airlines, power companies and banks once they become too big to fail.
Maybe commodity open source software has reached that level too...
I agree on the second point. I assume we all know that this weird EU free market religion is harmful. The EU would be 1000% better for us, without the economy stuff it was originally build upon.
Free markets are dysfunctional and never fair. How we now? Microsoft, Apple, Google, Amazon, Meta proof it every day. The US and China don’t even care about fairness. Why they should?
Someone mentioned above the limited money STF has. I agree. I did not considered it noteworthy.
There is also the option of structural funding (Strukturförderung in german) where important organizations receive multi-year contracts instead of short term project funding.
The STF is run by politologists with no clue. They fund flashy web apps that they "understand" and packaging.
All the industry money goes to packaging already. They should fund foundational small C/C++ projects that are not funded by the Linux Foundation etc.
Small C/C++ projects in general are treated like dirt. They get no funding but everyone relies on them. Occasionally champagne sipping SBOM industry shills draw a funny comic about the dependencies, cash in on their foundation salaries and treat the projects as "materials".
The whole OSS scene is dominated by grifters any hyenas.
The C/C++ projects should adopt the PyPI strategy: Insert exploits and segfaults, write huge mea culpa articles and then get industry funding.
> The STF is run by politologists with no clue. They fund flashy web apps that they "understand" and packaging.
That is complete nonsense. Where do you get this "information"?
https://www.sovereign.tech/tech lists OpenSSL, rusttls, Junit, pipewire, samba, varnish-cache, curl, Fortran, even friggin GNU coreutils and others. None of those are "flashy web apps".
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?
Governments are real customers. The German government, I guess, pays about 30 times more annually to Microsoft than the budget of the STF. The other component of sovereign tech is that governments are actually using FOSS. There is some room there for improvement.
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.
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)
You don't get such prompts on macOS if the app uses the system file picker, which they nearly all do.
You will get prompts for certain sub-directories of $HOME if the app directly opens them using POSIX or similar, so for example, anything running in a terminal emulator, or inside a virtual machine. Developers will see these prompts a lot more often than regular users do. MacOS doesn't let apps read directories but not files.
This is the sane solution. And not unlike what Android does in the end, with the difference that they have a share panel instead of an open panel: so you initiate the process from the app that owns the file rather than the one that wants to access it.
But GUI apps on Linux are so fragmented that getting everyone to use the same open panel is hopeless.
> 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).
And what is even the concern about that? I don't mind software knowing that my ssh key is in ~/.ssh/id_ed25519. Maybe if you see a 500 byte ~/.ssh/id_rsa that's an issue, but then the real issue is the tiny key
Thinking about threat scenarios of directory structure access, I'd be much more concerned about exposing that I have ~/documents/work/mergers/2027/[secret]_WarnerBros-Fox.docx
But only being able to see the file name would still be a huge improvement over being able to open the document and exfiltrate it
macOS does this for select directories. You either give access to all of `Documents` or none. It's also not great for notification fatigue, as you get like 8 popups at once in iTerm2. If you choose not to give access to a directory, you'll need to go to system settings to change this.
So, for a "better" system, we'd need to ask for every directory and you better hope the program doesn't try to glob all files in every directory and overload the user in prompts. Or you can "Allow all" or something, and then we're back at square one where the program has too much access.
If only flatseal could set defaults for all future installed apps too…
One thing I could imagine would be a kind of "Firefox tab containers" but for flatpak apps. On first launch, you'll have to select what folder will be ~ for it. Folder sharing between those is manual.
(And yeah, often forgotten but you can have several users on linux. Sadly, permissions and switching are pain.)
> 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.
If it's technically.implemented uniformely without thought of user access patterns, then yes it's a bad idea causing friction and frustration.
If I drag&drop a file in an app or it's icon, or by right click. The permission would be implicit.
For configuration files they could be part of allow rules, since they are so common if they follow the XDG specification.
For saving files, flatpak apps could be allowed to save anywhere in the users home sub-directories (not home top-level) as long as it doesn't overwrite any existing file. There are downloads, public, documents pictures, videos, that are barely used by default.
There is plenty of room for better desktop based integration, while of course lacking funding and care for users (thinking of particular devs in this case).
Currently it's a mishmash of separately using flatseal (and equivalents) and having your fingers crossed if you're likely to exfiltrate or not your data.
The list of files that such app would try to access by default on initial startup would be finite and well defined. So, a Flatpak package of such app should already, if done "properly", (I'm just imagining here, not an expert) include allowed access to those paths by default.
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.
Exactly, and for many productivity tasks there can be even more applications involved. There is a reason why the restricted model was introduced on consumption-oriented mobile platforms first.
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.
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.
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 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.)
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.
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?
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.
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.
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'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.
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.
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"
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.
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.
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.
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.)
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.
Huh funny, now that you mention it: at least in the Netherlands, job listings have had "(m/v)" (male/female) in the title since forever, i.e. way before woke was a thing, but that indeed is kinda weird. "All genders" is probably just a modern ("woke") version of that same old practice.
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.
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.
Had similar concerns about the default sandboxing, so had to use `--sandbox` with every app and then carefully engineer the permissions so the apps would actually work.
After reading about potential future problems with Flatpak on my distro, I decided to experiment more with Bubblewrap. It turned out to be surprisingly easy to build a minimal container manager around it (here comes the shameless self-plug): https://github.com/pakstak/pakstak
Although for desktop apps, it is not as easy as just packing an app into an OCI container and expecting it to work. Since you are basically building on top of the kernel, which brings true portability between distros, you have to provide the userspace part of the drivers, and this layer depends on your hardware. Overlaying an app container on top of a "driver container" can help with this though.
> 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 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).
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
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.
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
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.
> 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.
You can use a pretty big portion of the sandbox separately, because it's just bubblewrap.
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.
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.
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.
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.
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.
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.
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.
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!
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.
> ... 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.
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.
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
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.
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). 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.
reply