* 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.
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.
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.
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.
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).
They actually do employ developers: https://www.sovereign.tech/programs/fellowship
> The projects need to apply repeatingly for funding.
Still better than no funding at all.
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.
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.
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.
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.
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?
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 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...
On your last point, I'd love one day to see that OSS developers are paid because society benefits from their work.
No. And, I'm confused why you'd think that's the problem "we" have with Microsoft or any other monopolist.
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
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.
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.
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)
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).
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
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.
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.
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.
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 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?
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.
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.
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.
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.
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'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.
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.
Given that X11 is becoming more and more obsolete over time, what's the Wayland option?
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.
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.
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
If you want to sandbox your programs highly recommend looking at firejail.
The box' cost already topped the project's budget so no new disk for it. I'm back to "proper .deb packaging please"
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.
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.
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.
This is just wrong. Clients like the flathub website or gnome software show the risk posed by wide ranging access to local files, but Flatpak has to support legacy applications that don't use portals yet and thus they can't block applications having those permissions
https://flathub.org/en-GB/apps/com.calibre_ebook.calibre
> calibre is potentially unsafe
> Full file system read/write access
> Can read and write all data on the file system
What it looks like in the CLI:
com.calibre_ebook.calibre permissions:
ipc network fallback-x11 pulseaudio
wayland devices file access [1] dbus access [2]
system dbus access [3]
[1] host, xdg-config/kdeglobals:ro, xdg-data/Trash, xdg-run/speech-dispatcher:ro
But does bubblewrap also use them?
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.
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.
You also can have separate portals implemented with different processes if you, you know, use d-bus properly.
My solution: I'm very careful about what I run, but when I do run it, I just do. No fanfare. No security theater.
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.
"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.
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.
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.
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.
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.
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.
A waste of money if you ask me.
I think there are much more important issues that should deserve money and attention.
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.