So, Snaps are bad, Flatpak is bad. What's good?
BTW, I used to think that we can just provide a prebuilt binary to let user download from a website, but finding that isn't easy to achieve unless you use a language like Go, Rust... because I found that many C program are hard to compile with full static linking.
Snap/Flatpak were meant to solve that issue.
Edit: There's also the fact that practically most packages on Ubuntu or Debian, for example, are outdated.
This "issue" was already solved by static executables. Snap and flatpack are the work of computer illiterates.
What I value most is having every software or library available through some form of package manager. Downloading static binaries off the internet without auto-update just doesn't make it which is why I like having Flatpak as a fallback.
It also makes it easier for the common user to have every piece of software available through one store. They don't need to know whether it's a .deb or a Flatpak underneath, it just needs to be there and work reasonably well.
There's really no other option: either distro maintainers include every single piece of software in the repositories (unlikely), or we need a common format that works on all distros (already the case with Flatpak).
On the maintainer/author side, yes, I think static binaries largely perform the same.
And they do? Just because they have some flaws doesn't mean that they're completely unusable. If you need an app that isn't on your distro but is on Flatpak, by all means use it.
Some reasonable level of quality control does take time. There are distros that are much more up to date with upstream versions (Arch Linux, Gentoo, etc), but by living on the bleeding edge, you will eventually get cut.
Now, it's certainly debatable if flatpak could or should push more in that direction, like apple did when they introduced the sandbox for app store applications, but flatpak certainly does not have leverage to the same extend as apple has. So it's up to the app to opt in to a suitable sandbox set. It's a sad state of affairs, but I don't see a viable path for the flatpak folks to change that.
Whether flatpaks is better or worse than packages depends on many other factors. Flatpaks allow software providers to package for multiple operating systems in one package, for example. This makes software available that otherwise wouldn’t be. Whether that’s worth it or not is debatable, but raising clearly invalid points to attack flatpaks is disingenuous.
And it is easy to fix - publish capabilities in the gallery. Apple iOS "request location" shows that people care if they know. Sandbox certainly is a good thing. Without it Flatpak is just another package manager.
> It is advertised as offering a sandbox environment in which users can run application software in isolation from the rest of the system.
https://en.wikipedia.org/wiki/Flatpak
> flatpak(1):
> ... isolated from the host system ('sandboxed') to some degree, at runtime.
> One of Flatpak’s main goals is to increase the security of desktop systems by isolating applications from one another. This is achieved using sandboxing and means that, by default, applications that are run with Flatpak have extremely limited access to the host environment.
https://docs.flatpak.org/en/latest/sandbox-permissions.html
And a lot more
Maybe we can trust big names, just like on Android — Google, Amazon. We may think that it is safer with paid software — they have something to loose. But free - I'd bet on maintainers.
The old thinking was that software was a user agent, serving the user's needs and interests. Some OSes (Debian comes to mind) explicitly acknowledge this.
Increasingly it's simply a naive and unjustified belief. Applications must be considered as untrusted necessary evils. Allocating them a minimum level of access is prudent.
Flatpak promises this, but fails to deliver.
Package managers offer this by convention, but rely on users (and security researchers) discovering and reporting malicious behaviour. Mitigation is retroactive: fixed behaviours or packages removed from the distro's repository, but the damage is done and existing deployments remain.
The underlying issue is one of packaging, updating, and distributing sandboxed apps.
And in recognising that packaging systems serve users, not developers.
What at least some people don't understand, is that PPAs make the source available, so one is not downloading a black box.
Plus, they also add reproducibility, which is not to underestimate.
Also, PPAs do absolutely nothing about sandboxing. It's a different kind of concern.
Therefor we use opensource. Anything you dont trust is even hard to run safely in a sandbox.
BTW +1 for PPA culture.
What If you install script has a bug that lets an attacker place arbitrary SUID binaries? Or it has a bug that deletes your entire system (Steam had this bug and the script was open and available, they weren't the only ones either).
You can distribute open source software via flatpak or snap. And you can create a build system that takes open source software as a source and creates a flatpak or snap distribution.
It's totally possible to hide a backdoor in an open source software.
A working sandbox will prevent certain attacks to your system, whether it was built from an open source or not. This already works on most (all?) mobile operating systems.
not having a sandbox is less of a problem when you run FLOSS (in the context of PPAs that's relevant i think)
I disagree. Source auditing is irrelevant for day-to-day software use.
Fedora has such repositories (RPM Fusion, Copr). Arch does, too (AUR). Other distributions, including Debian, can use them as well, so long as there exists a community.
Compared to that Copr is a real PPA where you can build stuff into personal repo (as long as its built from source, licensing is fine & the thing is not patent encumbered).
Most popular distors provide similar stuff to PPA, the AUR in Arch for example.
It is rpm-specific, but not Fedora-specific.
With PPAs, everytime someone runs sudo apt upgrade, they are giving root privileges to their machine to some random person on the internet. No, having users scan the source code every time a package is upgraded is awful.
I reiterate, the most popular PPA is an old 3rd party Java PPA which doesn't even offer Java anymore. That PPA has root access to thousands of machines.
Relying on extremely incompetent users to make a general point is a strawman, not to talk about defining PPAs as "random people", as many software products have official repositories or affiliations (I take you don't use PPAs).
If one likes to scream about administrative privileges to get attention, they're forgetting that any Linux user is giving root access to thousands of packages. So the point is really the web of trust.
If we talk about the past and present, there has been no malicious attacks (or in number so small, that it's hard to find reports). So much for the "worst of the worst".
If we talk about the future, there's no reason why a web of trust can't be built. "To reiterate", lots of PPAs are official, including the OpenJDK one, so if the PPAs approach happened to get traction, it'd be really a matter of software authors to build their own or to appoint somebody to do.
This is really the concept of maintainers and their network, it's applying to the distro you're using, and it's nothing fundamentally different.
It was from a podcast from Canonical's apopey who described precisely some of the technical decisions behind snap and why they never bothered to open source it after the disaster that was open sourcing launchpad. He knows the statistics because most of these 3rd party PPAs were hosted on Launchpad that was only run by Canonical.
>Relying on extremely incompetent users to make a general point is a strawman, not to talk about defining PPAs as "random people", as many software products have official repositories or affiliations (I take you don't use PPAs).
Systems like this should be designed for 99% of users. PPAs were designed for 0.1% of system admins, and developers, not users. They are absolutely awful UX design, they are inherently unsafe, and unreliable.
Expecting users to vet that software is safe just because the source code is available is flatly a stupid idea. 99% of users for any piece of software will have no idea what they are looking at and are incapable of vetting it. Have you vetted manually chromium, vlc, firefox, vscode etc?
Publishers on PPAs don't test against every distribution, and if they publish a package or dependency that breaks system libs than users are stuffed. Users would have little recourse. I doubt every ppa owner tests 14.04, 16.04, 18.04, 20.04 and 20.10 builds to check their ppa won't break anything.
>If we talk about the past and present, there has been no malicious attacks (or in number so small, that it's hard to find reports). So much for the "worst of the worst".
Which has inspired both RedHat and Canonical to try and move towards flatpaks/snaps instead? The reason malicious attacks aren't there is because ppas aren't that popular because for good reason people tend to main repos.
Already on snap there was evidence of people bundling a cryptominer that was detected by Canonical. You think nobody has ever attempted to build/publish malware through ppas? Please.
>If we talk about the future, there's no reason why a web of trust can't be built. "To reiterate", lots of PPAs are official, including the OpenJDK one, so if the PPAs approach happened to get traction, it'd be really a matter of software authors to build their own or to appoint somebody to do.
My web of trust is purely Canonical. I chose it when I downloaded their OS. I trust their repos and snap store. I don't need to trust random Russian PPA for any reason. If a dev wants to publish something newer, put it on the snap or flatpak store or I won't use it.
I mean, Launchpad could be modernized and brought to the 21st century but all the functionality is there. I'd love to hear arguments against it though :)
FlatPak has Runtimes/SDKs for this, Snap has the one true Canonical-controlled base snap.