Flatpak and Snaps are a great step forward for Linux packaging and usability.
I think there's a vocal segment of the Linux community that doesn't understand what a major roadblock it is for the general user having different distributions having completely different ways of packaging, distributing, and updating applications. Don't worry, no one's taking away your apt-get, pacman, rpm, eopkg, makefiles, etc.
Snap needs to fix their non-standard directory placement. They ignore the FHS [1] by creating /snap at the root level. And they ignore XDG [2] by persistently creating ~/snap in your home directory. I've heard Flatpak is better in this regard.
I'm sure it could help with application delivery so long as it's constrained to that. I don't want half of my standard libraries or utilities suddenly becoming sandboxed. For full blown applications sandboxing would be welcomed.
For flatpak, the installed apps go to /var/lib/flatpak for system-wide, ~/.local/share/flatpak for user-specific.
Then there's the question of app-created data, that would normally go into some dot-directory. Flatpak by default redirects all XDG dirs into ~/.var/app/${appid}, but as a part of the required permissions, the apps can request access to the user homedir or specific subfolders.
Some apps abuse it. Yes, I do mind, when an app liters into ~/Documents/. I'm looking at you, Viber.
An /app isn't any better. If they insist on having a fully realized file-system, they can put it under /opt. Or, they could use symlinks to construct it under /run/{app,snap} similar to a chroot setup.
I installed Ubuntu 18.04 the other day and was prompted to install some common software such as Slack, Discord and Spotify . I installed all of them, and it mostly worked (navigating to another page in the software centre cancels an ongoing install with no warning).
When I ran mount, I noticed that every package I'd installed had it's own entry in the mount list. After I rebooted the machine, these mounts were no longer listed and the software I'd "installed" was no longer available through the gnome menu.
I'm not against finding new and better ways to package software but this experience left me with the expression that the technology is not quite ready to be rolled out and adopted en masse.
The technology has existed since the 80s, it's just that the stuff people are building today is ridiculously over complicating the solution. MacOS classic had simple single-file programs you just dragged and dropped anywhere you wanted on a disk and ran them. The same was true of DOS (it was a folder, but otherwise the same), RISCOS, NeXTStep and modern MacOS via NeXTStep.
Even Linux has had several: NeXTStep style Application Bundles in GNUStep, AppDirs in ROX filer, and AppImage today. They're just not over-engineered enough for the Linux Desktop community to embrace or something.
What you call “over-engineering”, the developers of Snap/Flatpak call “security.”
Portable app bundles are not the goal here. The goal is portable app bundles that the user can install from arbitrary sources on a whim without putting their OS at risk of malware or their data at risk of exfiltration.
Y’know, like on phones.
But also, since these designs aren’t for consumer electronics appliances with a central vendor, but rather are following the FOSS philosophy, you can’t just use a weak sandbox powered by nominal capability manifests signed by a central code-signer, where the app could do arbitrary things outside of its capabilities and the sandboxing wouldn’t catch it (i.e. the macOS approach.) Instead, you have to have a strong sandbox that will actually enforce the capability manifest to restrict what the app can do.
Oh, and the bundles can update by self-modifying their contents, creating new executable binaries in the process, so your sandbox can’t be based on signing the initial contents of the sandbox, but rather has to sandbox whatever is attempting to run in there right now.
If you can come up with a design that fits those criteria and is simpler than Snap or Flatpak, by all means, share.
" The goal is portable app bundles that the user can install from arbitrary sources on a whim without putting their OS at risk of malware or their data at risk of exfiltration."
This is not now nor will this ever be a thing. If you can run software on the host there will always be a way to compromise the host. It is not even 100% safe to run software in a vm because exploits have been found to break out.
Maintaining security on your phone requires the app store owner to invest time in proactively screening manually or automatically for malware or reactively removing it when found. It requires users to avoid stuff that looks like scammy bullshit or software from unofficial sources.
Both of these layers leak and when they do automated protections usually do as well because malware authors can easily test against existing protections, learn from one another, and distribute what works.
> If you can run software on the host there will always be a way to compromise the host. It is not even 100% safe to run software in a vm because exploits have been found to break out.
That's... inaccurate. More valid statements would be:
- In a sufficiently complex OS, it is unlikely you will be perfectly safe running untrusted executables even with reduced permissions.
- Popular modern OS desktop distributions are very complex out of the box.
- Sandboxing prevents certain classes of attacks effectively, but should not be relied upon as a sole line of defense.
- Vulnerabilities have been found in VMs and containers, but they afford greater protection and isolation than running a process directly on a host system.
IOW, don't go No-True-Scotsman on security. A vulnerability does not invalidate all benefits of an architecture.
What SELinux/AppArmor profile would allow an application to read exactly the one file in $HOME that the user selects in the file picker, but nothing else?
It isn't really that hard, just give the user the ability to determine if and how an application is sandboxed. Then it doesn't matter if the binary changes during an update, the user's level of trust in the vendor who provided that update has not changed (else they'd have disabled the updates), so there's no reason to change the sandbox permissions. You only really need to sandbox stuff you're unsure of, or stuff that misbehaves but you need to use anyway.
This condescending idea that users can't be trusted to determine this stuff for themselves and therefore we need a centralized signer and a bunch of complicated management framework to deal with it is part of the reason the FOSS philosophy has yet to produce a desktop anyone cares about.
I can determine whether an app is trustworthy, sure. But you know what? Sometimes I actually want to install an untrustworthy app. Sometimes an untrustworthy app is the only app that does what I need.
Your argument, by analogy, is “you should trust people to know not to sleep with people with STDs.” Well, you know what? Some people want to sleep with people with STDs. Sometimes those are their significant others. They still don’t want to catch something.
In both cases, the answer is the same: a condom.
A sandboxed App Store is, basically, a brothel where condom use is enforced. You can meet strange apps, play with them, and not worry about it. Because of the brothel’s policy, nobody the brothel hosts is risky. Your safety is enforced at the level of choosing the source.
Whereas something like Ubuntu’s PPAs, are more like a bar. Who knows what you’ll catch? Any individual app might decide to “wrap it up” with SELinux/AppArmor, but you can’t enforce it at the app-store level.
(Also, completely dropping the metaphor: the iOS App Store is frequently exposed—at least for free purchases—to children or even infants. This is actually a capability people want. This is certainly not a case where the user can determine for themselves whether an app is trustworthy.)
Apple who employs over 100k individuals has employees create automated tests, and manually test apps for inclusion in the store which requires a 99 usd fee for a developer to access.
A potential malware author must pay 99 usd to submit apps and pass certification for its apps. If apps are detected in review as malware that 99 usd is burned and will have to be spent again potentially repeatedly.
This is probably why there are millions of infected androids and comparatively few infected iphones.
Redhat with 10% of the staff and 1% of the annual revenue doesn't require any fee to release applications. This probably doesn't scale to android or ios proportions unless your sandboxing is perfect.
Unfortunately there is no 100% safe way to fuck disease ridden whores and no 100% safe way to run malware ridden apps. This is a dangerous fiction and an unworthy goal.
To be clear: clients run “malware-ridden apps” safely every day. They’re web-apps. Web browsers are actually-competent sandboxes. (Even PNaCl worked fine, despite nobody wanting to use it.)
Likewise, servers run “malware-ridden apps” every day as well. Do you think AWS or GCP is getting its infrastructure infected when customers run their arbitrary code on it? No. Not even on the shared clusters like Lambda/Cloud Functions. These are competent sandboxes.
There are numerous other examples—running everything from user-supplied DFA regexps to SQL queries on shared servers (complete with stored procedure definitions) to arbitrary Lua code, server-side, in an MMO.
We programmers know how to (automatically!) sandbox arbitrary untrusted code. We’ve done it successfully, over and over. We just haven’t done it for GUI desktop apps yet.
That fact is much more to do with the legacy of the architecture of these GUIs, than it has to do with any inherent problem in sandboxing desktop GUI apps.
Hackers bypass the $99 fee by releasing infected Xcode tools and having lots of individual developers unknowingly submit infected apps for approval. https://en.wikipedia.org/wiki/XcodeGhost
The FOSS of today is as much driven by buzzword bingo as the big corporations (perhaps so much of it is made by people working for big corporations now a days). And the really big buzzword in FOSS these days is containers. In large part thanks to the massive presence of cloud derived thinking (i have been told that basically all that mattered was cloud, as that was were the usage was).
I've noticed after updates I believe, the calculator app just won't open. It will sit there with the spinning wheel thing. After a reboot it will be fine. I noticed that the calc app is installed as a snap, never noticed this behavior before.
Wait, why is the calculator app installed as a snap? As a technology preview or proof of concept it's not very impressive—especially if it doesn't work!
Had a similar experience with flatpack. Installed some software 2 days ago and yesterday flatpak told me it is not installed. Teething problems i guess.
Perhaps not, I've had a good experience on Fedora 28. Even though I love Fedora, snap and flatpak needs to work on Ubuntu flawlessly before primetime, as its the most popular distro.
Eh, it's a step forward, I wouldn't call it a great one. A great step forward would be to remove all this complicated runtime garbage and keep things simple. GNUStep App Bundles, ROX AppDirs, and AppImage are much better ideas, if you ask me, and the wide adoption of one of those would be a great step forward.
Eh, it's a step forward, I wouldn't call it a great one. A great step forward would be to remove all this complicated runtime garbage and keep things simple. GNUStep App Bundles, ROX AppDirs, and AppImage are much better ideas, if you ask me, and the wide adoption of one of those would be a great step forward.
I go back and forth on this one.
On one hand I think it would make things much simpler for users who have enough storage and bandwidth.
On the other, when there is a vulnerability in a major library we would have to wait for every application to be updated, if they're even being maintained.
The thing is that package managers have mostly abstracted away the headaches of dependency hell, but have also raised the barrier to entry, so any software not participating seems suspect.
> On the other, when there is a vulnerability in a major library we would have to wait for every application to be updated, if they're even being maintained.
Yes, that's a drawback, but how often is there a major library that shouldn't be part of the set of libraries included as part of the base OS install? And for the ones that aren't, if the vendor chooses not to update at least you have the option of continuing to use, or not, the older version on your own terms instead of having it broken by the package manager when a dependant library is swapped out from under it.
We live with this sort of thing every day in real world business and it honestly hasn't been a big deal.
Just hoping the host never breaks ABI is why we are here in the first place, solutions like that simply don't work and you need a runtime to be portable.
The Linux Kernel ABI is incredibly stable, thanks to Linus, it's only the userland built up around it by other people that doesn't give a damn about compatibility. This isn't a significant issue for other OSs because they have a well defined base system and care about compatibility (because users care about compatibility).
I'm not entirely sure why you are being downvoted. The statements may not be entirely true and a bit volatile, but it's been my experience to a large extent. One of the things I like about docker, flatpak, etc. is that it allows for entire apps and dependencies to be encapsulated together. Less interruption and down time fixing things.
When I use Linux as my main OS, I lose about a day or so every other month to dealing with upgrade/update fallout. It's discouraging to say the least. With Windows, it's been about every other year, and macOS every major version gives me a little grief for something. Both far less frequent than any Linux distro I've used.
Don't get me wrong, I do enjoy using linux, that said, I still have very weak trust of it as my primary desktop/laptop OS. I use all three regularly.
> When I use Linux as my main OS, I lose about a day or so every other month to dealing with upgrade/update fallout.
One of the big benefits of Linux is you have control over this by picking your distribution. If you used, for example, Debian you wouldn't have this problem as updates don't break things. If, on the other hand, you don't mind dealing with the occasional update issue and want bleeding edge packages then something like Arch might be better.
But choosing a distro that doesn't update gives you other problems. Flatpak allows for a more hybrid approach where you get up to date software but a stable base. (Plus you can rollback software if those updates lead to problems)
Yes. I wasn't arguing against Flatpak, just the impression that Linux was unstable. Personally I'm very much looking forward to Flatpak or Snap taking off... I run Debian stable on my main system and there are always a few packages I have to personally backport.
I'm not saying it can't be stable.. but by your own statement there's packages you have to backport yourself at times. There's a pull between current and stable, and Linux distros in general don't do as good a job as macOS or Windows on that imho. Doesn't mean I don't use it, just pointing out the flaws that cause me pain.
>I think there's a vocal segment of the Linux community that doesn't understand what a major roadblock it is for the general user having different distributions having completely different ways of packaging, distributing, and updating applications. Don't worry, no one's taking away your apt-get, pacman, rpm, eopkg, makefiles, etc.
There's a vocal segment of the mobile App developer community that doesn't understand what a major roadblock it is for the general user having different distributions having completely different ways of packaging, distributing, and updating applications on iPhone and Android phones.
In reality, it doesn't matter.
I saw a lot of near pension age people, first time computer users, being taught basic usage of Ubuntu at around version 5.10. In our office, we have administrative and corporate treasury staff being taught to use it. The matter of them using it and not complaining "where is the start button here?" is having them RTFM* or get fired.
Not a single time we had to fire anybody over that.
Irony here is that the few Windows machines in the office are used by engineering for things like solidworks, different physics simulation packages, cadence, vivado and etc
[*] available in eloquent Chinese, unlike worse than Google translate Microsoft's manuals
I think there's a vocal segment of the Linux community that doesn't understand what a major roadblock it is for the general user having different distributions having completely different ways of packaging, distributing, and updating applications. Don't worry, no one's taking away your apt-get, pacman, rpm, eopkg, makefiles, etc.