I can’t agree with that. Flatpak’s opaqueness makes any potential security advantage meaningless, while the transparency of the AUR makes any potential security risk avoidable. It is always the packager who is reponsible for security, with the AUR the packager is the user, so it’s as secure as the user wants it to be secure.
Besides, flatpaks are statically linked, which means they do not use the system libraries, which means they can be linked with an outdated library which might have critical security vulnerabilities which haven’t been fixed. Packagers often neglect to update the flatpaks, leaving these vulnerabilities for who knows how long. Properly installed software on Arch Linux uses dynamic linkage to system libraries, thus benefiting from latest security updates the moment the system is updated. There is also another annoyance about flatpaks: they can use an order of magnitue more disk space, multiple flatpaks can be linked to include multiple versions of the same libraries, causing duplication of binaries and redundancy.
I’m not saying that flatpaks have no place, there are situations when I would prefer a flatpak over any other packaging format. But such examples are very, very rare.
They are linked with the libraries they need. That is the whole point of flatpaks. To have packages that work on any system, regardless of the system libraries. I never quite get the “more disk space” argument. Disk space is cheap and 100 mb more or less won’t hurt anyone. Keeping things clean is nice and all, but if you want your software to always work, you will not choose an AUR package over a flatpak package.
Some of my AUR packages used to break all the time when system libraries got updates. The AUR has many downsides if you really want to be sure things work. That is fixed by flatpaks.
But let’s just put it to rest. I personally think flatpaks have security advantages compared to AUR.Not that I don’t think being able to look at the PKGBUILD is a disadvantage. But I don’t see how that will affect anyone with official packages.
Because the “official” software, packaged by the developer, is often full of malware.
VS Code built by Micro$oft (can’t get any more official than that) vs. VS Code in the Arch repos or VS Codium in the AUR is a perfect example.
For open source software, flatpaks make no sense at all, because it’s always safer to build them yourself from source code. Which is what you do when you install something from the AUR. The exception is binary distributions of open source software (like web browsers) which are impractical to build locally, but in that case, you have to be very careful you trust the person who built it for you. Again, with the AUR, you know where that binary comes from.
Yeah, and how do you know it’s not full of spyware? You don’t, you just have to trust whoever packaged it. You can’t look into it and see what’s inside. It could be even worse than the official Micro$oft version. How do you know the libraries it is linked with are up to date and have no security vulnerabilities? It contains the entire source code of Chromium (as it is an Electron project), with dozens of dependencies, everything statically linked.
Yes, if you build your flatpack locally, if you are the packager of it, then it is as transparent as the AUR, so it has the exact same security benefits. You would also have to rebuild it every time its dependency gets updated, to get the advantages of security fixes in those libraries (which somewhat defeats the point of flatpak, being self-contained unit). The thing is, barely anyone ever does that (unlike the AUR users who do it all the time), but if they did, then yes, it would be a perfectly secure packaging format (or at least as secure as the user cares to make it secure).
That is as secure as it gets, because it requires no trust in anyone but the user.
So in the end you are worried flatpak doesn’t do the things it’s designed to do. The maintainers of the manifest don’t build it on their own and upload it to the flathub. The flathub uses the manifest given. And if the manifest is given, flatpak would ruin their whole concept if they tamper with it. You can always check the current manifest.
Flatpak does pretty much the same thing the official arch repo does. Take a PKGBUILD and build it. The PKGBUILD and the manifest is transparent for us. It is all the same, man.
It’s not the same, it’s more like the Chaotic AUR, where you have some server build PKGBUILDs from the AUR and present them as a repo, so you just download the built package and install it. This is not safe at all.
Flatpak allows apps to declare that they need full access to your filesystem or your home folder, yet graphical software stores still claim such apps are sandboxed.
This has been discussed before. Here’s what happens when I search GIMP in the Software app on a fresh install of Fedora 34:
Fedora claims GIMP is sandboxed. If you click “High” next to “Permissions”, you see a little exclamation mark saying it has “File system” permissions.
Such an app can drop a malware executable anywhere in your home folder and add a line to your ~/.profile or a desktop entry to ~/.config/autostart/ to have it auto-started on your next login. Not only will it run outside of any container, it will even persist after the app is uninstalled.
This is exactly what a nefarious app would do to break out of its sandbox. This is also what a virus would do that exploited a security vulnerability in a sandboxed app.
Suppose libjpeg has a zero-day remote code execution vulnerability. You open a seemingly innocuous JPEG in Flatpak GIMP and it drops its payload set to autostart in your home folder. How did the sandbox help here? The behaviour of this virus is identical regardless of whether GIMP is sandboxed. The only differences are that a) the libjpeg in the alternate runtime is likely to stay out-of-date longer than the one from your Linux distribution; and b) the virus is more likely to work against the sandboxed app because all installations will be using the exact same binary of libjpeg.
The Snap Store app, to its credit, displays a warning: “This application is unconfined. It can access all personal files and system resources.” Which apps display this warning, you ask? All of them. KCalc has it. All of the Editor’s Picks have it. In my testing for this blog post I could not find an app that does not display the warning.
It is. Both flatpak and the official(!) arch repos have a PKGBUILD/manifest and that is used to build/distribute the binaries. There is no real difference. You don’t know anything about the build process itself of the official arch linux packages and you don’t know anything about the build process of flatpak packages.
If you don’t trust flatpak, then you don’t trust the official arch repos.
Yes, for packages in the official Arch repos, you have the PKGBUILD files published on Github. However there is no guarantee that these PKGBUILDs were used to build the packages in the official repos. You trust trust the Arch Linux TUs that they are. That’s why they are called TUs. By using Arch Linux, you trust that Arch developers are not malicious.
And by using flatpaks you are trusting the flathub and the app maintainers. It’s the same in principle. Pretty selective thinking considering you don’t really know arch or flatpak packagers.
It’s a different meaning of the word “official”. With Flatpak “official” means it was packaged by the application developer.
In the official Arch repos, the “official” means it was packaged by an Arch TU (a person you unconditionally trust, otherwise you wouldn’t be using Arch), and not some application developer, like Micro$oft.
And if I use flatpaks I trust the packagers. You don’t seem to understand that it’s the same thing. I can trust TU in arch and I can trust flatpak packagers. Those are not exclusive. You simply choose to trust TU unconditionally and not trust flatpak packagers, even considering they may be the official maintainers of a project.
Again, we are running in circles. You desperately don’t want to acknowledge the hypocrisy in what you are saying. flatpaks and official arch repos are the same in principle. You just choose to trust one and not the other, which is highly subjective and not objective behavior.
Ah well, I’ll call it a day. In the end it makes no real difference. People who want to use flatpak (especially official packages) will never have any problems and usually have a bit more transparency what a program is able to do on your system. I use both AUR and flatpak. Both have upsides and downsides.
Because it’s not the same thing. Not even close! Anyone can be an official flatpak packager. If I want to make a flatpak for my game Snek , I am the official packager. You have to trust me if you’re going to use that flatpak (which effectively turns Snek into proprietary software!). If I put the PKGBUILD for Snek on the AUR, you don’t have to trust me at all, you just have to be sure to check what you’re installing.
If you use the official package VS Code flatpak, you have to trust Micro$oft. For every flatpak, it’s potentially a different packager. This is potentially thousands of people you need to trust. You need to decide for every flatpak whether the packager is trustworthy or not.
With the official repos, it’s only a handful of people (sixty or so) which you trust anyway if you’re using their operating system. Given that the average Arch Linux system contains close to 2000 installed packages, that’s not such a big number of people you need to trust.
Not even close! Anyone can be an official flatpak packager. If I want to make a flatpak for my game 