Hacker News Reader

Hacker News

Comment by cheph | Hacker News Reader

Full thread

cheph

Currently I happily use flatpak for Slack, Teams, Bitwarden, Spotify, Geeqie, Zotero, Inkscape and other things.

The options here are:

1. Run those things directly as OS packages or sometimes AppImages or just precompiled binaries.

2. Run them via flatpak.

3. Don't run them

I don't think 1 is more secure than 2, and 3 is not really something I care for.

So sure, Flatpak has it's issues, however I still appreciate it and IMO it is better than snap and AppImage. I also use AppImage for some things where the sandboxing of flatpak gets in the way too much, but snap never worked for anything that I tired it with.

View on HN

This seems to miss the article's point. You wrote:

> I don't think [running apps directly as OS packages] is more secure than [running apps via flatpac]

The article's claim is that running them via flatpak _is_ less secure because they don't automatically get security updates when the distro's libraries are updates and, as a result, they're less likely to receive prompt security updates. Do you disagree? If so, why?

For non open source software, dependencies are often packaged with the software itself, so it would be the same in flatpak or in the distro. It is true for software that uses shared libraries though.

But they also use a lot of system libraries.

E.g. they likely will not bundle openssl but use the systems openssl.

what I don't like with installing it from distro is to pollute my OS and full my /usr/bin with some user app that should live on my /home. But i agree that the security updates are a real issue.

The Flatpak model is good for "pet apps" where you have a company, team, project whose entire job is to make this one app. Relying on upstream to fix security vulns is less of an issue because these companies have incentive to fix them. Spotify, Teams, Skype, Bitwarden, Slack are all pet apps.

The Flatpak model is terrible for distros who are already strained for people and who benefit from factoring as much of the work as possible out of each application so you only have to update one place and push out a fix everywhere.

If I could get the same things from distro I would maybe be more inclined to use distro packages, but in many cases I cannot.

My distro either does not have the things I use from flatpak or have them with some deficiency (like older version or compiled features).

I can still get rpms for some, like Teams, but that also comes with bundled libraries and the Teams flatpak does have very tight restrictions so if I am concerned for the rest of my system flatpak is more secure.

For some other things on that list there are no rpms however.

So yes, you are more exposed to the maintainers behaving well, but you are also more insulated than just running things without any sandboxing.

Well, the sandbox is a lie. Did you RTFA?

Plus, you can have rpms that provide their own packages, but it's rare and will still be upgraded if it's in the repos.

> Well, the sandbox is a lie.

It's not though. And for Teams filesystem access is serverely restricted only allowing access to xdg-downloads.

But it is kind of a moot point, because you can update the flatpak stuff. I run dnf update -y to update the packages on my fedora laptop and flatpak update -y to update my flatpaks. It updates signal and the fedora platform libraries (security updates anyone?).

Agreed. Things don't have to be perfect. They just have to be a little better than alternatives.

Things don't have to be perfect, but they need to be honest.

To state that an application with full access to the host's filesystem is "sandboxed" is surely very harmful and very misleading.

It is sandboxed, sandboxed in this context just does not say anything about filesystem access. But it still says something about how it is running and again most people would exect something like gimp to have access to the host filesystem when they install it. You have options to whitelist specific directories in flatseal if you want to restrict it more.

I agree with that, flatkpak is very much work in progress. A lot of packages are still unofficial. Some software are also not meant to be sandboxed and do require access to the whole file system. I do think it is going in the right direction though.

The author is also mistaking Gnome Software (the gui for managing apps in gnome that has a flatpak backend) and flatpak itself. Marking the app as Sandboxed when it's not is a gnome software issue, not flatpak.

> I don't think 1 is more secure than 2

It depends - do the apps in version 1 dynamically link to system libraries that can be kept up to date? If they do, they may be more secure than the flatpak versions. If they simply come as statically linked blobs, then you are right.

> dynamically link to system libraries

It's very likely for openssl ;=)

I downloaded slack from slack's download page at https://slack.com/intl/en-it/downloads/linux

It's either a .deb, a .rpm or the snap store. Where do you find the flatpack?

I know that I downloaded the .deb (Ubuntu 20.04 here.)

I checked what I got installed now

  ii  slack-desktop  4.9.1        amd64        Slack Desktop

It's the same version listed on their site and it's from September 17. Maybe it autoupdates. I can't remember if I reinstalled it two weeks ago. I don't think so.

You can get it from Flathub. It's packaged by volunteers, who use the .deb they get from the Slack website.

https://flathub.org/apps/details/com.slack.Slack

Which distro are you on that it doesn't even have an official Inkscape package?

edit: since you mentioned Snap I assume Ubuntu. What's wrong with `sudo apt-get install inkscape`?

inkscape 0.95 in the standard repos and will remain that way for the life of 20.04

inkscape 1.0.1 via the snap maintained by the inkscape devs that will continue to get upgrades and give me options to switch over to edge releases if I want them (currently 1.1)

I use fedora. The inkscape that comes with fedora was missing some functionality last I tried to use it, can't recall exactly what now.

Snap does have some wild issues that appear to stem from its sandboxing.

For me: I have discord and spotify installed via snap, with standard (not classic) confinement, and have had zero issues whatsoever with them. I also use VSCode and DataGrip via snap w/ classic confinement, and all of these work flawlessly.

I also have Slack installed, with classic confinement. It had issues with clicking links causing a separate Firefox process to be launched, rather than re-using the one I already had open. This was resolved with a config change inside firefox (weirdly enough), and is a common issue. Otherwise, it works great.

Development tools like node and go, those are another story. NodeJS is officially distributed via snap, and appears to run relatively well in classic confinement, but I've also ran into some really strange issues where, for example, a node process starting a child node process either silently fails or takes multiple seconds to start up, which causes issues in our company's testing framework. Go is not officially distributed, but is kept up to date by the community, but has major issues interfacing with VSCode (even though both VSCode and Go are in classic confinement!)

Overall, I really think Snap is a massive step forward in package management for linux. About 80% of applications I use are available there (versus maybe 40% on apt, 50% on apt if you include "run these dozen commands to use our custom apt server because we derive pleasure from making life miserable for our users" and 20% on flatpak). But, it has very obvious issues even non-technical users would see immediately. Hopefully they can work through them.

I can't comment on it's security, but all of the snap apps I've used have an insanely high start up time that it's genuinely confusing how it could be so bad.

On my laptop with a latest gen ryzen cpu and nvme ssd, the Chromium Snap takes 30s-1 mins to launch, while the .deb launches in under a second. Same for Spotify, Discord and others that I've used. The start up time is so bad that I replaced them all for .deb versions which has been much better.

I have not noticed this in GUI applications, which generally have some overhead anyway so the snap overhead is negligible. I have noticed it on simple CLI applications, such as jq, where the snap is often 10x+ worse than native (but, we're talking 10x of microseconds; it enters the tens of milliseconds, which becomes noticeable, but its not horrible).

Snap startup overhead is a known issue. Its definitely a thing.

Just curious, what do you find so miserable with 3rd party apt repos? I mean, just add it once and it will integrate with dependencies from your existing repos. I have never had any issues with such setups (as long as the 3rd party repo is maintained, of course).

Well, you're wrong, 1 is more secure then 2. That's the whole point of the article. OS packages and precompiled binaries don't install their own version (often older and unpatched) of core binaries they are dependant on.

By all means, use flatpak, but be aware you are seriously degrading your environments security.

Reply on news.ycombinator.com