Flatpak – a security nightmare – 2 years later (2020)

http://flatkill.org/2020/

by URfejk • 5 years ago

316 289 5 years ago

What is the security story for Snap and AppImage?

AppImage is a convenience layer which doesn't claim to add any security as it provides no sandboxing whatsoever. And the outdated dependencies in images are likely to exist in the AppImage world too.

PhilippGille• 5 years ago

The AppImage website mentions Firejail as a way to sandbox apps.

https://firejail.wordpress.com/documentation-2/appimage-supp...

Quickshooter• 5 years ago

Snaps for services, debs for user apps

batrat• 5 years ago

you hurt all 9 pacman's out there.

loloquwowndueo3• 5 years ago

Snaps suck for services because they auto-update and either restart daemons without warning or leave the running process in an undefined state.

nodja• 5 years ago

All of the examples are apps where the main use is manipulating files on the system.

Asking out of curiosity, how would someone properly sandbox this use case without having a worse UX?

littlestymaar4• 5 years ago

Something akin to the web's permissions notifications “This app wants to access ~/Images/ do you want to allow it. Checkbox: I want to remember this” and a centralized permission manager ?

mavhc3• 5 years ago

Passing responsibility of not distributing evil software from the gatekeepers to the user.

Ignores half the point of having a distribution that has a package manager, curated software.

diffeomorphism2• 5 years ago

In practice this has the same effect as windows vista had. You train users to immediately click away the annoying popups without reading them.

josefx2• 5 years ago

All of the examples are apps where the main use is manipulating files on the system.

So do users, still can't overwrite system wide settings without first getting root. Decent sand boxing has to be granular enough to cover partial access. Of course the hard part on Linux would be locking access to files like ~/.bashrc without completely blocking access to the home directory, that probably would require an exhaustive list of all config files that are directly stored in home instead of a specialized sub folder.

foobar3333311• 5 years ago

Flatpak apps can not access root owned files. They run as the user and the typical linux permissions apply. They can only gain access to root if they have filesystem access so they can load malware in to bashrc. The thing is this is exactly the same as traditional packaged linux software. Flatpak only offers the ability for extra security.

eeZah7Ux6• 5 years ago

You described what firejail is already doing.

kelnos2• 5 years ago

The proper way to do this is to have the file/directory picker run in a separate process (managed by the sandboxing runtime), and the sandbox only grants access to files/directories explicitly picked by the user.

This does mean that some apps potentially do have worse UX; any app that implements a custom file picker will just stop working properly. Arguably in that case you just simply cannot sandbox that kind of app, and you shouldn't try, because it gives people a false sense of security in using it.

For apps that want to do custom things you essentially have to make them not need to do custom things by building their custom behavior into the sandbox-owned file picker (or whatever), and allow them to make use of it in a safe way. But that's a lot of work, and it doesn't seem like the Flatpak folks really work with the toolkit authors.

foobar3333311• 5 years ago

The proper way to do this is to have the file/directory picker run in a separate process (managed by the sandboxing runtime), and the sandbox only grants access to files/directories explicitly picked by the user.

Flatpak has this already. They call it portals and it covers more than just file pickers. The problem I have seen is that shoving existing software in to flatpaks and making them use portals ends up buggy for unknown reasons. I think the app devs themselves need to make at least some conscious effort to make sure it works and not directly access files.

saagarjha• 5 years ago

(This is how Powerbox on macOS works.)

microtonal4• 5 years ago

Somebody wrote a response to this: https://theevilskeleton.frama.io/2021/02/11/response-to-flat...

littlestymaar4• 5 years ago

Interesting part:

It is crucial for an IDE to have access to home or host filesystems, for Git repositories, and for other external uses, otherwise it is not very useful. […] They also need additional permissions to work, since making them use portals for all host system file access is technically complicated. Audacity and VLC face similar barriers, but all these applications should eventually be able to use portals instead of direct home or host filesystem access without losing functionality.

Which means that the author still has a point: there are still lots of use cases where the only practical way to use the file-access sandbox is to disable it.

Btw, the post you shared is a much more balanced view on Flatpack than the OP, but after having read it I would still consider Flatpack not being ready for what it advertises.

santoshalper• 5 years ago

It seems pretty obvious to me. Some programs aren't going to be very useful if you don't let them access resources on your computer, like the filesystem. Some "stateless" apps will do fine without it (Spotify), but anything designed to create and edit files you want to live outside the sandbox is going to need to access them.

smoldesu2• 5 years ago

This response is pretty well-measured, but their closing note rubbed me the wrong way.

If you don’t like Flatpak for personal reasons, I respect your opinion, but basing your arguments on an anonymous post that claims to have “criticized” Flatpak, but provided no statistics or evidence that vulnerabilities have been exploited inside a Flatpak package is not a reliable source of information.

Really?

You can't categorize people into "people who use flatpak" and "people who have personal reasons", it's not a very healthy way to look at software development. These concerns are entirely legitimate, and it's not like you're coming from the majority here. Flatpaks are still wildly unproven, and most of their responses were concessions surrounding the issues Flatpak has.

mands2• 5 years ago

Response from a Flatpak package maintainer - https://theevilskeleton.frama.io/2021/02/11/response-to-flat...

I'll leave others to make their own minds up, but I personally think the original article is FUD in a similar vein to some of the SystemD and Wayland nonsense that gets upvoted occasionally.

ekianjo• 5 years ago

note that the response partially agrees with the points raised, it looks like a constructive discussion overall.

nextlevelwizard• 5 years ago

It is hard to guess at motives when author is unknown.

Or when neither of the CVE links go anywhere.

Maybe I've understood how Flatpaks work incorrectly (please correct me if so), but the applications are ran in containers. So how would an attacker exploit CVE-2019-17498 on a Gitg? Its not like Gitg has a port open for listening incoming messages.

With ffmpeg I don't know if things like Chromium are actually using the flatpak ffmpeg or if they ship with their own libs.

foobar3333311• 5 years ago

The criticism and response typically boils down to "Yes, but its actually not any worse than what we have now"

If you manually install a rpm, deb or add a new repo, your system is completely owned by the person who built that package or repo. The biggest problem is that flatpak advertises sandboxing when some apps disable it but I imagine in the future we will get better UI around showing the user exactly what gets exposed as well as less permissions being given to packages.

mands2• 5 years ago

Agreed, as far as constructive discussion can be had with a post from a domain called flatkill.org :)

kelnos2• 5 years ago

I don't agree with your assessment at all. The linked article seems to mostly agree with the criticism levied, but disagrees mainly with the severity and degree of the issues.

For example, OP says:

Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions

The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissions. Well, ok, sure, that's definitely not "almost all", but that's still way too many.

I haven't used Flatpak (or Snap) before, but my impression of the technology was that it isolates apps and strongly sandboxes things so if you accidentally run something malicious, you're covered. But that doesn't seem to be the case, really. I get that this is a hard problem, and some things aren't even possible to do on X11, but then don't leave people with the belief that you can do all these things.

The response also says:

Some directories, like ~/.local/share/flatpak/overrides, are blocked. Even if they have home or host access, they will still need explicit permissions to get read-write access to the blocked directories. Doing this with .bashrc, .zshrc and other shell configuration files would be very useful from a security standpoint to prevent sandbox escape.

That is just an awful approach to security. You need to deny by default and selectively allow, not allow by default and selectively deny. Applications do not need explicit permissions to get r/w access to blocked directories; they can simply append to ~/.bashrc or whatever, and bam, they have "permission".

I'd heard some bad things about Snap, but looks like I'll be staying away from Flatpak as well.

orf2• 5 years ago

Well, ok, sure, that's definitely not "almost all", but that's still way too many.

And a couple of sentences after it goes on to explain that it’s not too many because most of those 23 need those permissions.

gspr4• 5 years ago

It's almost as if the people riding the "sandbox everything" wave have realized that an operating system is more than a set of disconnected pieces of software. And that to make it an operating system, those pieces must interact, and not be isolated from each other. Go figure.

Soon they'll reinvent the classical Linux distro. Poorly. But with a cool name.

alpaca1282• 5 years ago

From my perspective as a Flatpak user I can say I hate how the current file access restrictions are implemented, it's confusing and annoying.

I use a messenger installed via Flatpak. So whenever I receive a file in it I cannot save it anywhere outside my Downloads folder. So every single time I then have to open a file manager and manually move the file somewhere else. Similar for the other way around - I have to copy any file I want to send into either ~/Downloads or ~/Pictures. Not a single other path is visible or accessible, if I click on "Desktop" in the list of favorites nothing happens. This is confusing and annoying for me, this would be super confusing for a user who doesn't know and care about file permissions.

I like flatpak as it can nicely fill gaps in official repositories whitout being bound to a single distro family once again. But honestly I understand why apps would just go "allow all", because anything else drives the user insane the way it is implemented now.

necovek13• 5 years ago

Snap and flatpak: they suffer from identical problems (in the snap world, these are "classic" snaps which get almost no restrictions).

Any app that needs to save files in your home directory, which all the traditional apps do (Gimp, Inkscape, *Office...), has to have r/w access to your home directory (duh).

So I would venture to say that this is all misleading marketing, which is mostly what the OP complains about too.

It all boils down to the same discussion we had 20 years ago: Linux proponents talked about how much better it was when it comes to viruses because only your $HOME would be affected, somehow missing to realize that in mostly single user desktops, that was the only thing anyone really cared about.

(I've exclusively used GNU/Linux systems since 1999, but not for made-up reasons like that :))

Flatpak/snap model is the one where app controls your data (which allows them to only need access to a certain subdirectory of $HOME—think Steam or Spotify), instead of allowing you to group files related by topic instead.

And that's exactly the model I don't subscribe to :)

amelius3• 5 years ago

and some things aren't even possible to do on X11

I think they are, simply based on the fact that we can run untrusted stuff inside VirtualBox (and with quite good performance).

AdmiralAsshat• 5 years ago

The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissions. Well, ok, sure, that's definitely not "almost all", but that's still way too many.

The response article did also note that the most popular flatpak apps are often ones that really need filesystem access in order to function properly, e.g. an IDE, an image editing program, an audio editing program, etc.

It's really hard to conceive of how these programs would work without some of the requested permissions. I remember the hazards of trying to get a proper IDE on ChromeOS some years back because of Google's own sandbox restrictions on allowing extensions to access the chromebook's filesystem. IIRC there was a company that even created "cloud-IDE" environments to get around this limitation.

djeiasbsbo• 5 years ago

I use flatpaks all the time and I almost always have to adjust these permissions to be more restrictive.

It's really not an issue with flatpak itself, it's the maintainers who give permissions that are not restrictive enough. It's understandable because it makes it easier to package and maintain.. but it also kind of makes the whole concept useless.

What I personally want is apps which are as, if not more restricted than mobile apps.

oedmarap• 5 years ago

Great article, thank you for sharing.

I use Flatpak extensively and I fully agree with you and the author of the response that there is a need to balance practicality vs. idealism when it comes to (fully auditable) FlatPak apps, as well as FlatHub's overall approach and continual work within the desktop Linux ecosystem.

What's more, the fact that an entire domain was devoted to what could have been a blog post gives credence to the responder's notion that this is FUD which, while valid for discussion, is most certainly not beneficial to the FOSS community writ large.

Either way, from the article you linked TIL about Flatseal[0] so I'll be taking that for a spin!

[0] https://github.com/tchx84/Flatseal

Blikkentrekker3• 5 years ago

I find your takeway that it is f.u.d. from this response quaint.

To sum up the issues:

- We agree that write access to the entire home directory compromises any and all security, but we are aware of the problem and trying to fix it.

- We checked the claim of “Many of the popular flatpack applications still have access to the entire home directory,” and conclude that 23 of the 50 most popular ones do.

- We partially disagree that the “sandboxed” icon is misleading, because it does limit some things, even though we as per issue one agree that access to the full home directory gives malware carte blanche.

- We agree on the point that the outdated example library with a vulnerability used is true as stated.

- We agree with the issue, but we have a tool built that mitigates it by altering developers.

I hardly would say that this rebuttal amounts to showing “f.u.d.”; — it alleges no technical falsehood in the article, but at some points simply disagrees that it is as much of a problem as the article claims it is, not numerically in terms of facts, but simply disagreeing on whether full write access to the home directory is truly such a big issue as the original article makes it out to be.

antimba8• 5 years ago

There are several technical falsehoods on https://flatkill.org/2020/. For example, this one:

Almost all popular apps on Flathub still come with filesystem=host or filesystem=home permissions

TheEvilSkeleton counts them and 23 out of 50 is not almost all, so that is a technical falsehood, albeit not one that invalidates the author’s point. There are other falsehoods that do invalidate the author’s points. This one, for example:

Two years is not enough to add a warning that an application is not sandboxed if it comes with dangerous permissions (like full access to your home directory)?

This is wrong because GNOME Software did, before the flatkill author’s 2020 update, add a warning (which is missing from the author’s screenshot) indicating that the app has high permissions and can access all files and folders (it’s still described as sandboxed, which technically it is, just with the ability to escape the sandbox; further changes to GNOME Software to make this clearer are already planned). The author’s screenshot was presumably taken using an outdated version of GNOME Software; they should have checked more recent versions before making claims about what features developers did or did not add.

And here’s another falsehood:

So I need to run multiple fcitx daemons on my desktop and switch between them as I switch flatpak apps depending on which fcitx libraries are bundled with that app

The flatkill author misunderstood the implications of the bug report (in addition to seemingly misunderstanding where fcitx comes from; it’s part of the runtimes, rather than being bundled with each app). The issue was caused by a change in Flatpak, fixed in fcitx, and there is no need for the fcitx versions to match going forward.

zokula• 5 years ago

Systemd and Wayland being cancer is not nonsense.

dastx• 5 years ago

One thing I've not understood about flatpak (or their competition for that matter) is why don't these permissions get prompted when they're used? Similar to iOS and Android, ping the user and confirm whether or not they want to give the application this permission. Perhaps even allow for customising the permissions (e.g. when it asks for permission to the homedir, you can override what the homedir would be when prompted).

We are living in a day and age where applications ask for overbroad permissions for many reasons, laziness, privacy invasion, and even legitimate use. Forcing user interaction at worst raises awareness, at best prevents the privacy of individuals from being invaded.

foobar3333311• 5 years ago

I think its more of a one step at a time thing. There is nothing about the design of flatpak which prevents permission popups. The problem is that every desktop program must be rewritten to support this idea and most linux desktop app devs are only vaguely aware of flatpak, let alone ready to start designing specifically for it.

The current strategy seems to be having outsiders packaging all the desktop software in to flatpak while disabling any sandboxing that gets in the way. This brings you to the same state as traditional package managers with little security, but it boosts the flatpak ecosystem and makes it ready for the average person. At that point app devs will be more aware of it and can build their apps to tolerate missing access to things and prompting for access.

Iolaum2• 5 years ago

This brings you to the same state as traditional package managers with little security

Does it? From the flatpak state you have a far more clear path towards a sandboxed destination.

fragileone• 5 years ago

Agreed, the current state is such that many developers either rely on package managers for auto-updates (thus lacks sandboxing anyway) or use Snap (which is usually similarly not sandboxed and you have to put your trust in some proprietary cloud platform to push code to your computer). Just getting devs to support Flatpak is an effort, but once that's done sandboxing can be worked on later.

lambda_obrien• 5 years ago

Why not just fake stuff? If you give software no file permissions, show it an empty dir. Tell the software you saved it's file but don't, just keep it in an memory overlay just for that program's run. If it wanted the network, give it a dummy net.

epr• 5 years ago

The problem is that every desktop program must be rewritten to support this idea

No, and expecting that to work is obviously ridiculous. This type of problem needs to be solved in a way which requires no changes at all from developers, or it will almost certainly go nowhere.

fulafel2• 5 years ago

This is probably quite hard to implement without modifying the packaged applications. Needs something like a mechanism of pausing, instead of denying, a system call in the kernel and calling back to userspace, which would then load new policy into the ruleset on the fly and resume execution. Oh and reverse engineer the high level intent of the user / application far enough to present an intelligible question to the potentially nontechnical user.

Maybe some antivirus etc products manage to seemingly do things like this on Windows platforms, but they have generous support from the platform developed over decades, are executing custom 3rd party kernel drivers, are unhindered by opinionated kernel developers blocking the feature due to their distaste for these hacks, and the resulting system is still unsound and rife with stuff like TOCTOU vulnerabilities, and the prompts are not intelligible to nontechnical users.

KronisLV• 5 years ago

Doesn't this imply that Linux is falling behind somewhat in the area of permissions management? Personally, i think that limiting access to files and such based on users and groups simply isn't enough and instead the user should be prompted (or should be able to configure) which piece of software is allowed to do what (network access, file system access, talking to specific devices) based on their own individual needs.

Oh and reverse engineer the high level intent of the user / application far enough to present an intelligible question to the potentially nontechnical user.

I don't believe that this is such a big problem, since Android is pretty explicit about this - a camera app asking for access to my contacts will simply get denied and will promptly be uninstalled.

harporoeder• 5 years ago

There is a mechanism for this called portals (1) available in flatpak. It gets integrated into the GUI toolkit, and certain applications are not supported. It is useful for things like accessing files from outside the default sandbox.

1. https://docs.flatpak.org/en/latest/portal-api-reference.html

its-summertime• 5 years ago

specifically, anything that uses the generic GTK/Qt way of accessing files via the file chooser will automagically use the portal

Anything that tweaks on that, most notably Electron, will not use the portal

gigatexal• 5 years ago

How better or worse is Flatpak than a chmod +x’d AppImage?

linmob• 5 years ago

Confirming these settings at first launch is something that mostly annoys users. Remember: Most users just install software via Flatpak because this way they don't have to compile it themselves, deal with a tarball or use an outdated release their distribution ships.

Also, if you want to review or change these settings, you can use Flatseal[0]. Arguably, it should be installed by default.

The problem with flatkill.org is that it leads to users rather downloading a random deb off the internet or an AppImage than using Flatpak, which both have worse security stories.

[0] https://github.com/tchx84/Flatseal

bayindirh3• 5 years ago

If macOS, iOS and Android can get away with one-time permission pop-ups when access is first needed, I'm sure the same model can be applied to Linux.

The annoyance doesn't come from the security, it's from un-refined UX.

gspr4• 5 years ago

or use an outdated release their distribution ships.

And a good chunk of those people often would be just fine with that "outdated" version.

alerighi• 5 years ago

Is not that simple. First you would need a flatpack daemon that manages that permission, that the application could ask for a path (e.g. by writing in a control socket) and the daemon asks the user and mounts that paths inside the container, and then inform the application that the operation is successful. But that would require modifying the application, and not in a trivial way, and it's unacceptable (you need to fork basically every application that you package for flatpack, and the filesystem access could be in various places).

A more acceptable solution would be to intercept all the filesystem related system calls, look if a path is accessible, and if not ask for the permission and either try again the system call and return the result or return to the application E_AGAIN (but is not ideal since not a lot of applications handle that correctly). But this approach would probably require a kernel module, or you can do that with eBPF but obviously you would need CAP_SYS_ADMIN capability so not really possible.

The approach of flatpack is create a container with all the paths that you know the application can access and then jump into the container. A simple solution that even doesn't require a daemon and doesn't require modifying the applications.

ddtaylor2• 5 years ago

But that would require modifying the application

Technically it can be done using LD_PRELOAD on fopen() and such.

incrudible• 5 years ago

One thing I've not understood about flatpak (or their competition for that matter) is why don't these permissions get prompted when they're used?

The POSIX APIs do not have such permissions. You can attempt to put something in between and have lots of stuff break, that's what Apple did. On Linux, there is no such authority.

There are alternatives as well, such as sandboxing all the way up to using a hypervisor for every program, which is arguably what you need to run an untrusted program.

We are living in a day and age where applications ask for overbroad permissions for many reasons, laziness, privacy invasion, and even legitimate use.

Fair enough, but Flatpaks are mostly open-source software and closed-source software can be monitored far better on a Linux system.

HenryBemis• 5 years ago

Simplistic response: Apple & Google (A&G) don't want people concerned with what's going on under the hood. It is difficult to explain. Also, imagine that you download something, you pay for it, then it asks a question you do not understand (rights 666 or 777? - what the hell? I don't want the devil on my phone!! NO to 666, Yes to 777)(maybe I will win in the casino). And assumming you 'Deny' and the app doesn't work. And you paid $10 for it. You uninstall, reinstall, and 'Allow'.

(Majority of) People barely understand the (privacy/security) impact of giving access to Location, Contacts, Calendar, Phone, SMS. Now think of the more obscure (?) layers of the following pyramid: Hardware, Middleware/Drivers, OS, Applications. (Majority of) People hardly understand Applications. You want to ask them if they can write on X folder? On the OS? Good luck!

Although both A&G can review your code and flag these upfront with some auto-policy-check, I feel that it would send many app creators reeling & pain. Pain for app creators = smaller revenue to A&G.

I assume it's the typical cat & mouse game. A&G may try to reduce/prevent access here but their SDKs will create a new oppotrunity/workaround to get access there. The new "there" access will be abused and someone will find away to do what they were doing in the previous setup. And thus we restart the chase.

It's in the way that people code. Naughty and/or lazy coders will go for the keys to the kingdom, ignoring the security. To avoid misunderstanding the word 'lazy' doesn't mean 'lazy people', but 'lazy/inapprpriate/corner-cutting practices'.

Closi• 5 years ago

People hardly understand Applications. You want to ask them if they can write on X folder? On the OS? Good luck!

Well this is how it works in OSX (“Would you like to grant this application permissions to this folder?”), so I guess the answer is “yes - that’s exactly what Apple do”.

megous• 5 years ago

Reminds me of some bizarro Android permission issues, when I wanted to install a TLS client certificate (pfx) file. I downloaded it via web browser to a phone, opened the certificate management app, and the file was grayed out, no explanation, nada. No way to click on it, no error messages, no confusing permission flags in the file list. I thought the format of the file was wrong, so I tried regenerating it a few times in different formats, wasting an hour or two.

Turns out, you have to copy the file to some folder via adb command line, to make it usable by Android. Copying directly to a uSD card would have probably worked too, but how many people just have a uSD card reader lying around.

But I didn't get a confusing security prompt when downloading from a https:// url, that I might not have understood, so I was better off I guess. /s

varispeed• 5 years ago

In my view these queries about permissions are a bit meaningless. If an app asks me if I want to give it access to my Photos I feel uneasy about that. Which photos? For what? What is it going to do with it? I think the filesystem should be sandboxed and if an app wants to read something I should be able to e.g. give it a directory where it can do anything or I should be able to select a file and the app will have a permission only for that file for a limited time e.g. only to read it once. Also there is no easy way to know what these apps send over network. How do I know they are not downloading all my documents to China?

XorNot2• 5 years ago

This is where we need to require better programming languages. What we need to be able to prove from code is that when an application is asking for a particular permission, the code paths the data will be used for can be shown not to result in network transmission without going through a trusted transform (if we want to allow it) - i.e. that only SHA512 transforms of that data can end up on the network without gating or something.

Zevis• 5 years ago

If it's anything like on Android, where you just give it blank permission to access your entire storage, it would be useless. There are plenty of programs you might want to use that have no business having access to everything, that you can't or don't want to trust 100%, but it's easier for the developers just to ask for everything (or it's the only option).

The "ask for permission" model is broken.

Everything should be sandboxed without giving the application awareness of being sandboxed. If you want to give additional access to a program, it should be through an external interface only accessible to the user.

Blikkentrekker3• 5 years ago

Because the system can't be intelligent enough for that.

Say the process wish to write to a particular file; — how far up the directory tree does the system ask for permission?; only that specific path? the home directory?; how can the system know this?

Of course, the other issue is that, say the system be implemented so that the write call blocks until the permission be given, that they will timeout with an error because they have limits on write calls that take that long, and assume there is something else that is wrong like mechanical storage failure, if a simple write call truly take seconds.

rathboma• 5 years ago

As a desktop app developer this is what I need.

I publish a snap variation and so many edge cases break the security system and make the app unusable.

Home perms? What if the user symlinks something into their home directory? Etc

takluyver4• 5 years ago

In some cases it does request permissions when you try to do things. E.g. sandboxed apps without full filesystem access can open & save files through a 'portal' - the system presents the user with an open/save dialog, and the app gets access to the file or folder they select. Things like screen sharing can work similarly - the system asks the user to approve access for the app.

But, as other people have said, this involves new APIs. In the open/save case, the app has to request that the system display a file chooser instead of drawing its own. GTK & Qt can hide this change so apps built on those toolkits benefit automatically. But beyond really self-contained things (like games) most apps that haven't been developed with a sandbox need some adjustment to play nicely within a sandbox. And making changes depends on building a consensus that it's worth doing.

hkt2• 5 years ago

Is there a security comparison somewhere of all the new fangled ways of getting up to date desktop software on Linux? snaps etc too?

I suppose the real answer may always have been backports on debian distros - which is to say, trusted sources over technical solutions.

eeZah7Ux6• 5 years ago

Spot on.

microtonal4• 5 years ago

which is to say, trusted sources over technical solutions

This does not solve the problem where your a PDF reader from a trusted repository happens to have a zero day exploit. When it is exploited, the attacker could have access to all your files, since there are no further limitations unless you bubblewrap or firejail the application yourself.

Since sandboxing is one of the goals of Flatpak, the exploit would be limited to the sandbox (if sandboxing was enabled for the PDF reader).

hkt2• 5 years ago

It doesn't solve that problem, but it does provide a channel that is likely to receive an update in most distributions. It would be nice to not have to choose between sandboxing and security updates, though.

cl3misch2• 5 years ago

All Linux users I know don't use Flatpack/Snap for their sandbox, but much rather for getting the newest version of some UI app (Inkscape) on an older Ubuntu release.

I think this shows that a standard release cycle is not appropriate for desktop users.

sjellis• 5 years ago

Yes, for me the sandboxing is not the immediate benefit.

The instant value is providing channels for developers to ship apps to their users without either side having to mandate the OS that the other uses. Right now, even well-funded projects like Visual Studio Code have to pick and choose which Linux distributions and versions that they package for.

They don't provide packages to the main repositories for Linux distributions, partly because the release cycles are so wildly different. I don't want Debian stable to ship a completely new base system every few weeks, but the release cycle of my Web browser is a new version every six weeks.

In the ideal Flatpak world, I can run Solus or whatever distribution I choose, and the app developers that I rely on can not care about distribution market share, and just target Flatpak runtimes.

The challenge is going to be to ensure that Flatpak repositories and the Canonical App Store (the server end of snap) enforce good enough legal and security checks once vendors have started using them.

jart2• 5 years ago

Am I the only one who sees the irony in it being a scandal for free software to fail to adequately restrict freedom? I just can't imagine an iPhone style restrictions model ever gaining momentum in open source. As much of a prize an App Store would be, it's just too at odds with the culture. I think what makes more sense for open source is to have better tools for monitoring what it's doing. The behavior of some of these programs with things like dns is like the hunger games and you can't trust the system to save you with a top-down permissions model when the system itself is the problem.

e_proxus• 5 years ago

Security and open source philosophy are two completely orthogonal problems. You can a have an open source system that is the most secure, sandboxed implementation there is. Likewise you can have a completely insecure closed source proprietary system.

The freedom in open source could be the freedom to structure your system in the most secure way possible for running untrusted applications. It’s just that no one managed to achieve this yet in a satisfying way.

jart2• 5 years ago

Not entirely. A few months ago I was reading about a controversy where the Emacs dev team was concerned about the ethics of conducting an online survey. Can you believe that? That's why I like using their software. You just know people who are that extreme philosophically will never in a million years betray you.

Don't you think tools like Bochs, QEMU, gVisor, etc. are reasonably satisfying? Security is a hard problem since there's an endless push and shove around its tradeoffs hence why sometimes the best one can afford is monitoring.

psanford• 5 years ago

I see flatpak and snap as potential solutions to the problem of distributing proprietary software to Linux. Its in that usecase that I really want sandboxing and where the current solutions are lacking.

Right now I'm most happy with Firejail for sandboxing proprietary applications. It doesn't solve the packing problem but seems to do the best job at actually limiting what applications can do.

jeppesen-io• 5 years ago

Shall I plug NixOS?

xvector• 5 years ago

What is Nix and why is it a better alternative?

microtonal4• 5 years ago

There is some overlap and there are a lot of differences. One point of overlap is that Nix makes it easy to install packages that are newer than your os. For example, you could run NixOS 20.09 or Ubuntu 16.04 and have the latest Handbrake or youtube-dl.

A large difference it that Flatpak also attempts to sandbox applications, which Nix doesn't (it only sandboxes builds). Though it might be easier to sandbox applications using Nix than traditional package managers, since all dependencies are made explicit.

kaba02• 5 years ago

Basically, nix (and guix, which is based on it) is the only package manager that actually solves the dependency hell problem properly.

It makes builds reproducible, and basically a package will depend on it’s inputs’ hashes. So you can not only install multiple versions of the same package that is solved by some package managers although in hacky ways, you can install multiple ones that only differ in eg which libc version they link to.

In this way, I do think that it is truly revolutionary - but it is a package manager (and NixOS makes basically the OS a big package). Flatpak and snap try to do this as well, in an objectively worse way, but they also provide different features, so they are not in competition. I would rather like to see flatpak and snap employ nix for solving the package management problem and build on top of it. That would actually make the linux solution better than what we have on other OSs.

spindle• 5 years ago

eeZah7Ux6• 5 years ago

no thanks. It's pretty orthogonal to the conversation about sandboxing.

oever• 5 years ago

Nix packages and NixOS services have no easy sandboxing features. There is no improved security in current Nix or NixOS.

fguerraz• 5 years ago

My most recent favourite https://gitlab.gnome.org/GNOME/mutter/-/issues/1606 In this case more of a gnome issue maybe, but the fact that there's no UI feedback from either flatpack or gnome is laughable.

mrweasel• 5 years ago

Security updates are a huge issue for most “container” formats. Even official image on Docker Hub receive almost zero security updates and most companies seem to have no policy on how to keep container, be it Flatpak, Docker or even LXC containers updated.

antimba8• 5 years ago

Even official image on Docker Hub receive almost zero security updates

Are you talking about the Official Images program? Because if so, this is not true.

cardanome• 5 years ago

I don't need the security. I don't need automatic updates.

As a Linux user, most of my software will be installed with my native package manger and receive the appropriate security updates.

Flatpak/Snap/Appimage are just for when the former option is not possible because the software is not available or not in the right version I need.

I am making a conscious decision here to seek out that software and can be expected to check for trustworthiness.

The Windows world survived decades with running random .exe files from the internet. Some people got hurt but that is fine. Sometimes convenience and productivity can be more important than security.

I already have a good sandboxed environment, it is called a web browser.

So really for me the only thing I need is some easy way to run an application with just a single click on any Linux system. Appimage works fine for me. All the other features, I don't need them.

LockAndLol• 5 years ago

"People are trying to do things better, I'll say they aren't and not provide a single option that's better" aka "I'll complain about stuff and not do a single thing to improve it".

What a contribution. Typical flame bait website.

cheph3• 5 years ago

The sandbox is STILL a lie

No it is not. If sandboxed means no access to filesystem, sure it would be, but that is not the only definition of sandboxed, that is not the definition of that under which flatpak said they would operate, that is not the definition of sandboxed under which other things operate.

If you want them to use a different definition of sandboxed, by all means submit an issue making the case, but you don't even make it here. You just ignore that and then proceed to act as if your definition is the only reasonable one. And if that was the case the very least you can do is find a reference for your definition.

Try harder with the FUD.

vntok• 5 years ago

A single line of code allows any "sandboxed" program to escape from the sandbox. This is not what the word "sandboxed" means for any reasonable definition of "sandboxed".

cheph3• 5 years ago

A single line of code allows any "sandboxed" program to escape from the sandbox.

How is that what is happening here?

Shadonototro2• 5 years ago

it doesn't matter what people think

both snap/flap user experience is trash

linux desktop is doomed to fail people the people who make decisions are clueless and tasteless

preommr• 5 years ago

linux desktop is never going to take off and died off when all the money moved to the cloud - it's not the 2000s, you can download windows and run it for free because that's not where the money is anymore. For the average user that's not technically oriented, that's going to be their goto solution.

_qbjt2• 5 years ago

linux desktop is never going to take off

Who cares? Why is popularity so important to you?

Jonnax• 5 years ago

What's your idea that would save Linux desktop?

Shadonototro2• 5 years ago

less fragmentation, i think Unity 8 could have been the answer, sadly it died way to early..

pjmlp4• 5 years ago

The Linux Desktop has failed already thanks to the endless fragmentation and religious attacks on drivers.

Even ChromeOS and Android only package the Linux kernel, while building their own userspace on top.

With the Web turning into ChromeOS, and the return of timesharing via the cloud, there is even less reasons to care about the GNU/Linux desktop.

_qbjt2• 5 years ago

linux desktop is doomed to fail

What does this even mean? I’ve been using Arch Linux with KDE as my only desktop OS for years and it’s a wonderful time. If you think Windows is better and prefer to use that, great. I personally prefer Linux and a lot of other people do as well.

krick• 5 years ago

I don't want to downplay the importance of the problem, but it seems to me, that unfortunately the correct addressing of security concerns is rather an exception, than the norm on Linux desktop. Of course half of the your "ordinary apps" need home write permissions, whether they are installed via flatpak/snap or not. And most semi-technical desktop Linux users have some sort of ~/bin with a bunch of random scripts, and a number of tools installed via pip or directly downloaded from github. (In fact, you probably use Linux on desktop in order to do all these things, because it makes life easier.) And many users aren't even really aware of the contents of their .bashrc and such.

So, is there a security problem with Linux desktop? Yes, absolutely. And it is serious enough to worry for those who are not paranoid security enthusiasts (I mean, even real vulnerabilities aren't truly a concern to many users, but we have to admit there is a problem, when it becomes quite evident, that Linux starts falling behind both MacOS and Windows in this regard). But is flatpak the culprit? No, not really. Linux on desktop in 2021 is just really flawed (at least security-wise).

syockit• 5 years ago

I don't have experience with MacOS to comment, but at least in Windows it's pretty much the same: as soon as you get the user to click OK in the UAC prompt, everything is fair game after that. Is there even a model desktop OS we can look to as being secure? Chrome OS perhaps?

my123• 5 years ago

For Windows, there are the Win32 apps that you talk about, which aren't sandboxed.

And there are the modern applications from the Microsoft Store or self-distributed as msix/appx which are properly sandboxed.

pdimitar2• 5 years ago

People have praised Qubes OS for its security in the past but I've never tried it.

GordonS2• 5 years ago

In some ways, things are better there on Windows here, because of code signing - if something isn't code-signed, you get a more prominent warning. I often wish for something like this on Linux (and it would have to be easy to use - no compiling your own kernel with additional modules for example).

It's really not easy to get a code signing certificate fraudulently (or to steal someone else's), but of course, there are some issues with code signing: for example, certificates are relatively expensive, so very few OSS/free software projects sign binaries.

Koliakis2• 5 years ago

I've been experimenting with Qubes and it's the only OS I'm aware of that adequately addresses this issue. It's not usable for non-technical users though without a lot of learning/training and it can be a bit tedious to use sometimes.

I have all my personal data in its own isolated VM (Qube). I do all my browsing in another VM, which has its own home folder and no access to my personal VM. All my sensitive stuff like banking is done in its own VM. Every proprietary application gets its own VM (mainly Teamviewer and VS Code).

So if I do happen to run some program that's malicious, it has effectively zero access to anything sensitive unless it's aware of Qubes and knows how to break out of the hypervisor (non-trivial).

oxylibrium5• 5 years ago

I'm not too sure about "falling behind Windows", personally. The major lines of defense that Windows appears to rely on are code signing and a signature database, with behavioral AV being a relatively recent creation that still doesn't cover a lot of big holes. (for instance: What if I manage to fake my way through an OV/EV cert or use a leaked one? What if I use polymorphic code obfuscation that can generate hundreds of different signatures, but is also used by "legitimate" programs as DRM?) There's SafeSearch, but many people just click past those warnings anyway.

It's just as easy for a Windows .exe to create a service that runs when you log in as it is for a Linux app to write something to .bashrc - so its not a uniquely Linux problem.

macOS has the big Apple hammer to force developers to comply - Apple has the power to say "from this release on, all permissions need to be requested for or they won't work". Comparing the two companies, Apple uses the big hammer they have to force some compliance from app devs, while Microsoft often tries not to break stuff.

Linux doesn't have a big, central hammer like Apple does, so progress like Flatpak's isolation has to happen in steps, or else you end up in this chicken and egg problem:

- App devs won't support Flatpak with stuff like using portals because Flatpak has a small userbase - Users won't use Flatpak because it doesn't have apps that they want, and will instead go about doing things the old way

This "we'll give them $HOME for now and let them fix it eventually" is deliberate - you need to drive adoption for Flatpak before apps consider adding special code paths for it. The goal is to eventually fade out $HOME access or severely restrict it, but unfortunately this is the norm.

I've mentioned this on other posts, but this is deliberately why Flatpak's messaging on their website[0] is focused on ease of distribution instead of security. In addition, if you feel like you can put up with an app having a restricted view of the filesystem (for example, you don't think you'll touch anything outside ~/Documents/Models with Blender), you can adjust the sandbox to fit your needs.

[0] https://flatpak.org/

tsimionescu• 5 years ago

It's just as easy for a Windows .exe to create a service that runs when you log in as it is for a Linux app to write something to .bashrc - so its not a uniquely Linux problem.

This isn't entirely true - you need something like Administrator access (so at least a UAC prompt) to create a Windows Service, whereas all software you run on Linux will normally have access to write to your .bashrc.

Of course, if we're talking about installers and not random .exe's, where users are already conditioned to allow installers to run as Administrator, the problem re-surfaces.

A bit closer to editing .bashrc in Windows is the peculiarity that Windows DLL search order normally starts from the directory where the .exe was loaded from. So, any .exe in a User-writable location that loads a DLL can be tricked into running malware by creating/overwriting a malicious DLL of the same name there (this doesn't work for Windows DLLs, though).

cheph3• 5 years ago

Linux starts falling behind both MacOS and Windows in this regard

Last I installed something with windows it had full write access to my home directory and pretty much everything the user it was running as had access to. Is this no longer the case?

airhead969• 5 years ago

And this is why I use Qubes and not Snap, Flatpak, or any of these other cobbled-together emperors-new-clothes app package managers. I knew this would happen from the very beginning but as usual, most software developers just shrug it off.

pedro2• 5 years ago

For me Flatpak is akin to Arch’s AUR.

As such, rebuilding Flatpak and its various layers should be easily rebuilt from source or equivalent as available as an option (but not the default). That would prevent some of the issues.

It would also introduce bugs, but at least you would have the option.

pjfin123• 5 years ago

I don't have anything against Flatpak but maintain a Snap package and think Snap has made a lot of good design decisions even if it still has rough edges. For a basic application it's pretty easy to package for Snap. A lot of the things that bother Linux power users like polluting their mounted file systems wouldn't matter to regular users. My understanding is they support either pre-declaring permissions or requesting them at run time.

https://github.com/argosopentech/argos-translate

zajio1am• 5 years ago

Hot take: Per-application sandboxing is (in general) fundamentally flawed idea, as applications are just tools to manipulate data, while data needs to be protected from unintended manipulations, but such protection should not encumber intended manipulations. What manipulation is intended depends on worflow, not application. Such setup can work on phones due to their limited use cases, but not on desktop.

What we need are tools for per-workflow sandboxing. Assign each data to worflow/project (with separate uid), and then execute applications as a part of the project. So applications would have access to data of the project in which they are executed.

higerordermap3• 5 years ago

The world doesn't work like that.

1) application sandboxing isolates different vendor's code, some of which may be security / privacy infringing.

2) There wouldn't be a problem with data sharing in a properly designed sandboxing system. There will be shared filesystem, file chooser / save dialogues so that's not really a problem.

TheMagicHorsey• 5 years ago

It seems like some of OP's criticisms of Flatpak are not actually criticisms of Flatpak, but rather criticisms of the way Linux works.

Perhaps OP would be happier with a capabilities-based operating system (like Google's new Fuschia system).

It just seems like these complaints leveled against Flatpak are asking the authors to achieve nearly impossible goals given the complexity of doing sandboxing at the app level in Linux.

vorticalbox2• 5 years ago

The most popular applications on Flathub still suffer from this - Gimp, VSCodium, PyCharm, Octave, Inkscape, Audacity, VLC are still not sandboxed.

All of these require access to the users data to actually function.

GIMP, Inkscape: edit/view photos and save creations VSCodium, PyCharm: edit/create project files Audacity, VLC: play user media

these apps have the same "problem" in snap requiring --classic to allow access to the users files.

andagainagain4• 5 years ago

Question then - does flatpak require an explicit flag when installing them to access those files? Or is it as I assumed just "flatpak install"

vorticalbox2• 5 years ago

I actually believe it's set in the flatpack, though I am unsure.

KerrickStaley• 5 years ago

A small nit about an aside in the article: Is fcitx "the" East Asian IME for Linux? As a speaker of Chinese as a second language, I use IBus (with libpinyin), which is supported out-of-the-box in GNOME and seems to provide a better user experience than fcitx the last time I checked (which was probably 10 years ago).

raffraffraff• 5 years ago

Semi-related. I wanted to run Amarok 1.4 recently (because I had been having a discussion about how no music player on Linux touches MusicBee, and the last one that had promise, before the developers lost their minds, was Amarok 1.4 - yes I know about Clementine etc but MusicBee still wipes the floor with all of them. This is a digression).

Anyway, I spent about an hour attempting to get get it to run on my up-to-date Mint laptop. Now, Amarok 1.4 is 12 years old, so if you want to get it to run, you'll either have to compile it (which means getting your hands on the 12 year old KDE libs), run a 12 year old Linux distribution in a VM, or... Dockerize it. Now you see where the flatpak connection comes in.

Step 1: Find an Ubuntu 8.10 ISO and mounted it:

sudo mount -o loop ubuntu-8.10-desktop-amd64.iso /mnt/intrepid

Step 2: Unqsquash the filesystem:

sudo apt-get install -y squashfs-tools sudo unsquashfs -f -d /tmp/unsquashfs /mnt/intrepid/casper/filesystem.squashfs

Step 3: Import the tarball into a Docker image:

sudo tar -C /tmp/unsquashfs -c . | docker import - ubuntu/intrepid

Step 4: Run interactively and install Amarok:

docker run -it --entrypoint=/bin/bash ubuntu/intrepid

(NOTE: At this point, it was pretty hard to find an apt repo for Ubuntu 8.10 but, amazingly, one or two still exist online. So I edited the apt sources, ran apt-get update && apt-get install -y amarok. I also created a user to run Amarok - one whose uid/gid matched my own user. These commands are left as an exercise for the reader)

So I dockerized Amazok 1.4.10 / Ubuntu 8.10. What next? Well, I could have created a Dockerfile that started "FROM ubuntu/intrepid" and repeated all of my manual work I did in the interactive container, but I'm not keeping this thing, so I just did this the hacky way:

docker export quirky_mendel -o ubuntu_intrepid_amarok.tar

docker import intrepid_amarok.tar amarok:1.4.10

Now I have a docker image called "amarok:1.4.10" which I can share on Docker Hub! Does it work?

docker run -it --entrypoint=/usr/bin/amarok --rm --name amarok --net=host --user amarok --privileged -e DISPLAY=:0 -v ${HOME}/.Xauthority:/home/amarok/.Xauthority amarok:1.4.10

IT WORKS! A 12 year old music player running in a docker container on the latest Linux Mint. My alternative to Flatpak / Snap etc. Is it safe? Nope! It's running in an Ubuntu image that wasn't updated since 2008.

superkuh• 5 years ago

Containers on the desktop are a symptom of a festering underlying disease. They are not the cure for anything. Modern linux development is extremely rapid pace and is 100% targeted at the needs of the corporate entities paying for the development. This extremely fast pace of change in the kernel and underlying libs, langs, and compilers means that a desktop environment put together 4 years ago cannot realistically compile or run software written today.

That's okay for mega-corps who re-build the entire software universe every time they want to make a change. Or for those who ignore desktop entirely and just "deploy" containers.

And that's lead us to today. Linux desktop can't live for more than a few years on it's own. In order to deal with the backwards incompatible features some desktop distros have shifted to using containers. But this doesn't fix the futureshock. It only makes things for desktop users worse.

busterarm• 5 years ago

I only use Flatpak apps when it's my only option and the only places that seems to be are Electron apps.

Discord & Slack, I'm looking at you.

I also run a rolling-release distribution...

GekkePrutser5• 5 years ago

Indeed, very good point. Those is why I moved to freebsd for my desktop. Too many corporate interests hijacking Linux right now.

einpoklum• 5 years ago

Containers on the desktop are a symptom of a festering underlying disease.

Agreed, although we may be in disagreement regarding what the disease is.

Modern Linux development is extremely rapid pace

I believe you are over-generalizing, both over different distributions and over different packages within a distribution.

and is 100% targeted at the needs of the corporate entities paying for the development.

... specifically, many distributions are not funded by one, or a few, specific entities, corporate or otherwise. Debian comes to mind. I've never felt its is developed rapidly, or that languages change that quickly.

. Linux desktop can't live for more than a few years on it's own

I'm not sure what you mean.

In order to deal with the backwards incompatible features some desktop distros have shifted to using containers.

but the rest haven't.

andagainagain4• 5 years ago

One thing that gets me about the sandbox of flatpak is that it doesn't seem to be up to the user. If the developer of the app chooses the permissions, then there isn't a fundamental difference for security from having all permissions anyways.

Ideally a user installs the app and they would know, without reading anything else about the app, that the app is separate from their system. If any app you install is NOT separate from the system, then... the sandbox is like making a giant wall but having a door right in the middle of it.

takluyver4• 5 years ago

You're thinking about malicious apps, where the developer would just request all permissions they can. But sandboxing is also about limiting the impact of security issues in apps from honest, well meaning developers who (hopefully) won't request more permissions than they need.

E.g. if I make a chat app, and it has a bug that lets someone send you a malicious message and execute code in the app, then a sandbox is a really good thing.

The developer also sets the default permissions - in principle, the user can change these before running the app. Of course, not many users will do that, but there are still cases where it can make a difference.

GekkePrutser5• 5 years ago

From the article:

The flatpak runtimes and apps do not get security updates

This is exactly what I worry about with things like Flatpak and Snaps (Ubuntu).

Instead of having the distro maintainer provide timely security updates, all they have to do now is shrug and point at the external package maintainer. So now instead of simply backporting a patch to the distibution's openssl library, every single app maintainer of each app that uses it has to do this and provide an update. This is clearly not going to work as well.

And while sandboxing is a great idea, it can be done using other methods too, like SELinux or AppArmor.

Not to mention the wasting of resources by running all those separate versions of each library.. But that's not security-related discussion.

antimba8• 5 years ago

So now instead of simply backporting a patch to the distibution's openssl library, every single app maintainer of each app that uses it has to do this and provide an update.

That’s false. OpenSSL is part of the runtime[1] and only needs to be updated there.

[1] https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/ma...

GekkePrutser5• 5 years ago

Ok bad example then, and I didn't know that, but most libs are not part of the runtime :) I just mentioned openssl as an example of a frequently linked library.

ravi-delia• 5 years ago

This is quite late, but I thought I'd add my two cents. I use Linux as my only daily driver, and in general I use my distro's package manager. I keep secure by not running random executables and keeping updated, but I'm no infosec engineer and there is a 0% chance that anyone who knew what they were doing couldn't work around everything I have.

Flatpak for me is incredibly useful in a narrow use case; other people put in the work to make stuff work without cluttering my damn home directory! Specifically it's helpful for Steam. Why every game on the planet feels the need to fill my home directory with UNHIDDEN directories with spaces in the name (!!!) is absolutely beyond me.

Ericson2314• 5 years ago

All the things like flatpak annoy me because I have a gut feeling that capsicum is the most incremental change to unix that is both secure and ergonomic, and all these other things sacrifice one or both of those with tons of complexity.

Just abandon the epicycles already!

hda111• 5 years ago

How does snap compare to this: let’s say the Chromium snap? It’s advertised as sandboxed but obviously can download files to your Download directory, it can print PDFs etc, access Webcam of course for video conferences. How is sandboxing supposed to work here?

smoldesu2• 5 years ago

If Flatpak security is this much of a joke, why do people go through the trouble of using it? Flatpaks are outright cumbersome, and bar-none my least favorite way to install anything. Have a local GTK/Qt theme/colorscheme? Gotta manually patch it in. Have a small main drive? You can store maybe three or four Flatpak'd apps. Slow internet connection? Good luck, you'll be here a while. All of it boils down into the outright worst way to distribute software on Linux. I'd rather use Snaps, which should be taken as a violent insult to anyone who's familiar with the medium. Nowadays, if I see that an app is exclusively distributed through Flatpak, I'll compile it from source or find an alternative.

The future of software cannot be containerizing anything dangerous or complicated. All it does is add an extra layer of abstraction that makes it harder for the end-user to use your software. All of this seems especially redundant on Linux, where we could take any number of extreme measures to sandbox software. Why did we choose the path of most resistance for the user?

antimba8• 5 years ago

Have a small main drive? You can store maybe three or four Flatpak'd apps.

That’s not true. Even the smallest consumer hard drives are big enough to store as many apps as you will want to install.

Slow internet connection? Good luck, you'll be here a while.

Flatpak uses OSTree to install and update apps. It is very efficient and generally faster than traditional package managers.

isaiahg• 5 years ago

Am I alone in that I really don't like using flatpaks or snaps over debs. All the software I've installed from both tends to be buggy and unoptimized. Inkscape from flatpak crashes, Kate can't access system themes, steam barely works and doesn't understand the permission system. It feels so much like these projects are taking software and stuffing it into a box it was never meant to fit. Also I don't really think the problem it fixes really exists. People who use Linux know what they're installing and I don't sandboxing really achieves anything other than getting in the way.

dang• 5 years ago

https://news.ycombinator.com/item?id=24661126

stjohnswarts• 5 years ago

Hmmm, my computer hasn't blown up and burned my house down nor my bank accounts drained yet...

Flatpak – a security nightmare – 2 years later (2020)

Related Stories