I mean, there's an argument that this is worse. If a security bug is found in libc, in the "old world," your distro would have an update out in a day, and you'd be completely safe. With flatpak, you also depend on whoever's maintaining the GIMP flatpak (and all your other apps), who may not be motivated to do updates any faster than GIMP's normal release schedule, potentially leaving you vulnerable for much longer.
> your distro would have an update out in a day, and you'd be completely safe
If you do not restart your services after updating the package, your services continue to run against the exact libs they were started with, even though the library is updated on disk and anything new that starts will use the fixed version. For something like the libc, that is pretty much every service bringing it in and still running the unpatched version of the library.
Updating distro packages is of course usually a good thing, but alone it does not make you "completely safe".
Also they have a patched version "in a day" because they embargoed public release of the vuln details usually for months, creating a gap where a (growing...) set of people know a secret that can compromise your system and you don't. When I get that update I don't feel "completely safe".
And for a lot of smaller apps, they're unable to realistically support being distributed in many different distributions. Flathub is cross-distro and easier for the app author/developer/maintainer to support.
Is it perfect, no... is it actually much more secure, not usually. All of that said, is it available in pretty much every linux distribution and often a newer version than what would be in the repositories, absolutely.
This is also the case for server containers, and I do worry about the day that some critical low level library that is in thousands of containers has a security bug. Yes, many shops are using CI to push out new containers regularly. Others are deploying containers from third-parties, without any regular updates or path to fixing security problems.
> > Look ma, I've discovered a program can do nefarious things
> What else is new?
I think that this dismissal (which presents as a quote something that doesn't seem to appear in the original article) is too hasty. Surely exactly the same could be said of any submission involving, say, privilege escalation? Of course every program and means of distribution has security risks, and their existence isn't news; but documenting the specific risks is surely worth it.
Well, as every direct reply said, it is true that these App Store models suffer from possibly outdated libraries with unpatched security bugs. But it's nothing new. Everybody knows that. It's case with Docker and all other fat bundle formats.
> Sadly, it's obvious Red Hat developers working on flatpak do not care about security
Presenting it as a novel privilege escalation with such wording IMO deserves hasty dismissal. These kinds of "hype-ridden disclosures" (i.e. allocating domain name) deserve to be ridiculed because they're meaningless distractions. See [1] for discussion.
All the other formats talk about how easy they are to use, and when you mention security, they throw up their hands and say "I dunno". Flatpak, on the other hand, its entire shtick is how applications are sandboxed for security.
And flatpak is actually sandboxed for security. So what's your point?
The only news the author of this hype website told us is that
1) there was a vulnerability,
2) lots of application have broad privileges and
3) apps have bundled dependencies.
--
1) Bugs happen. Deal with it.
2) Flatpak actually tells you which privileges an app is going to use. What do you suggest as a solution? Is it technical problem or social problem? What is the state of art? I'd say the state of Art is Android in that it asks for permissions individually as they're required. Still, this problem is not fundamental issue in Flatpak. It certainly doesn't deserve "Flatkill" logo and domain.
3) Is Flatpak actually an exception to the rule?
- Making Python app? Use pyenv, pipenv, venv or ${popular_venv_of_the_year} and bundle all your dependencies!
- Making .NET app? Use NuGet and bundle all your DLLs!
- Making Java app? Use Maven, Gradle, SBT and bundle all your JARs!
- Making Rust app? Use Cargo and glue everything together.
- Etc. Etc.
So yeah, for every programming language we're encouraged to treat our dependencies as unique, fix their versions to prevent possible breakages and take the responsibility for monitoring security issues. Developers just like it. I don't like it but it's everywhere.
And as other posters said, Flatpak actually have runtimes which carry core dependencies like libc that get updated independently of the app.
So what is the novelty here deserving the flatkill domain? Where is that juicy security vulnerability?
Aside from security updates being delivered between late and never if they are ever compromised 1/3 of users will be effected in the first hour and 100% effected within 24 hours even if on the 25th hour they discover it and take it down.
In the old school situation distributions would still be between days to weeks deciding to pull in a new version released through normal channels.
> Look ma, I've discovered a program can do nefarious things
What else is new?