Hacker News Reader

Comment by jillesvangurp | Hacker News Reader

Relative to running the same application without flatpak:

- You'd expect the application to run as your user and have full access to the home directory. Many applications expect to have this access. This is what it means to have user space applications. Flatpak is not about fixing or changing this.

- You'd expect individual applications might have out of date dependencies. Depending on the application this might be completely fine. This is not a security risk of flatpak but of the application. Developers are responsible for releasing updates, not flatpak.

So, works as advertised and intended. If your flatpak install has security bugs, update it. If you use a linux distribution that ships an out of date flatpak with fixed security issues, consider using a different one or update it yourself. If you use flatpak apps from developers that can't be bothered to release updates or fix bugs, consider using something else.

Basically, flatpak not being a middlemen between you and the application developers kind of is the whole point. They don't mention sandboxing on their frontpage, at all. This is not a goal. Instead, providing a cross distribution consistent installation experience is the main goal. They are not trying to be more secure than manually installing packages on your system.

So, these are not security bugs as far as I can see. It's not a security nightmare. It's fine. Actually looks interesting and might give it a try if/when I get rid of my mac.

View on HN

> They don't mention sandboxing on their frontpage, at all.

But the apps themselves still show "Sandboxed" when they aren't[1]. It's trivial for the flatpak "store" to just hide "sandboxed" if the flatpak requires access in its manifest. The Microsoft/Windows Store does this. UWP apps are sandboxed and permission-managed, but if a store app requires full access, the permissions section[2] says:

> This app can

> Access all your files, peripheral devices, apps, programs and registry

[1] See first screenshot in OP article.

[2] https://www.microsoft.com/en-us/p/microsoft-flight-simulator...

That screenshot is of GNOME Software, not of a Flatpak app. GNOME Software decides how it describes apps.

The GNOME designers are working on a redesign of this area: https://gitlab.gnome.org/Teams/Design/software-mockups/-/blo...

There are other software installers that can install Flatpak apps, e.g. KDE Discover.

So this is a valid criticism of GNOME Software, but not of Flatpak.

You're right, I checked Plasma (Kubuntu) and it doesn't show the same "Sandboxed" indicator for Flathub. This is more of a GNOME issue, even a serious one if it existed for an whole 2 years.

Great, let's create the bug report, otherwise GNOME devs may not know about this defect.

> But the apps themselves still show "Sandboxed" when they aren't

Redefining the term and then claiming that what someone else meant by it is not in line with what you meant with it is ... well it is messed up.

They are sandboxed, but rightly Gimp has access to your whole filesystem because that is what people who install it expect.

Of the 30 apps I have installed via flatpak only 6 have access to the whole FS or my entire home directory (Zotero=home, Krita=host, KolorPaint=host, Inkscape=host, Gimp=host, Geeqie=host), and of those 6 only 1 (Zotero) of them seems like it may be fine without it.

Having access to the host FS in no way mean to me that Geeqie is not "sandboxed". It just means that what I would expect is the case. If you want to change it, go open up flatseal and change it.

> They are sandboxed, but rightly Gimp has access to your whole filesystem because that is what people who install it expect.

They can be sandboxed, but that doesn't mean every Flatpak package should be labelled "Sandboxed". Especially if said app isn't actually sandboxed and has full filesystem access.

Except that with "old school" package managers you get security updates without the application or the developer having to act on it. I don't know if it's "a nightmare", but it's worse security comparing against the previous solution.

Nobody should be relying on dynamic linking as the primary way they keep their home computer secure. Enough applications statically link their libraries that this is not a reliable strategy.

If you can't trust a library author to keep their code up to date, it's probably also a mistake to trust them to use your system libraries in a way that minimizes their attack surface.

I also have problems with Flatpak's security model, particularly with their UX around permissions. We already learned from Android/iOS that allowing highly permissive manifests out of the box was a bad idea. But at least Flatpak is trying to do something, and that something seems like a tangible improvement to me. The idea that our systems will be secure because we dynamically link everything needs to die; it's not a viable security model.

Even if the only thing that Flatpak does is kill the "dynamic libraries make me secure" perspective, that on its own will be worthwhile.

Static linking is dead. Most applications cannot be built statically, at all.

Solaris-style RPath is still an option on Linux, but it is rarely used.

As far as “security,” dynamic linking is not an attempt to contain applications, but rather to fix as many things as possible with as few updates as possible.

Flatpak actively encourages upstream developers not to participate in the wider picture, and as it turns out, upstream developers can’t be trusted to fix security holes in a timely manner.

This was a widely foreseen issue that was pooh-poohed in the early days of flatpak, but, well, look how it turned out.

> Most applications cannot be built statically, at all.

That’s a pretty bold claim. Can you identify a specific C program that cannot be built statically, no matter how hard you try?

> identify a specific C program

Well, not sure about C (but I assume something using gtk could be pain), but if we expand that to C++, I mean, I would expect firefox and chrome to be basically unbuildable in static manner.

> no matter how hard you try

Well, no. If you are willing to rewrite it (even significant changes), of course it will be possible to built it statically. That does not mean it is doable in practice.

I doubt they meant "no matter how hard you try" nor were limiting this to C programs only. Something the size of Firefox, for example, with hundreds of files, multiple languages and dozens of platform variations, is simply not designed for a fully static build and trying to modify it to build like that would be an absurd amount of work for basically no reason, so it hasn't been done and probably never will be.

Add licensing complications to that (Qt is notorious for this) and OP's statement is for all intents and purposes true.

Perhaps so, but Firefox is but one program among the hundreds or thousands that are available in a typical Linux distribution. "Most" implies a quantitative analysis (i.e., more than half), which I think is disputable.

Firefox has a hard dependency on GTK, so it is literally unbuildable as a static binary.

Certain libs use dlopen() which needs dynamic linking. Mesa, Pam, Qt (static is possible but a lot of stuff will break), Glibc(static is possible but nsswitch.conf will break), Alsa. So most graphical apps will fail to be pure static(Prob possible but will hardware/config specific). So we need to tackle and provide alternatives to dlopen.

Running NSS and PAM modules in-process was IMO a historical mistake. Convenient in one aspect, rather inconvenient and impractical in many others.

If we were to redo these today, I think we'd do them out-of-process and talk to them over UNIX domain sockets or pipes.

The transitive dependencies of NSS and PAM modules can also wreak havoc with your application. There are many bugs which have arisen because of these limitations. Yes, looking at you, GnuTLS.

OpenBSD chose BSD Auth over PAM for this reason. With BSD Auth the C API invokes binaries in /usr/lib/auth which are SUID or SGID according to which permissions are required for the credential store.

> Qt (static is possible but a lot of stuff will break),

as a user of statically-built Qt I haven't noticed any particular breakage

GTK does not support static linking, so that rules out pretty much all GTK applications: https://mail.gnome.org/archives/gtk-list/2018-January/msg000...

The question about it comes up every so often, but nobody has ever put up the effort to maintain it. It appears to be a lot of work for very little gain.

Firefox. Chromium. KDE. Gnome-shell. Libreoffice.

Static linking is an atavism. Application authors don't spend time thinking about it any more.

The main reason static linking persisted as A Thing into the 1990s was that fossilized vendor UNIXes didn't support it, or didn't support it well. Those systems are all extinct.

About the only place you still see static linking is embedded. And that is its own world.

The two weaknesses cited by the OP to support your argument were CVE-2019-17498 and CVE-2020-12284. That means if you use the RedHat's App Store to illegally torrent media content and pentest strange ssh servers, you might get pwnd. Tears are flowing to mine eyes.

A lot of languages like Rust and Go (but also C++) mostly do static linking.

Golang doesn't really support static binaries. This may be confusing, since it compiles-in all golang dependencies, but by default, all output is dynamic, and it's quite difficult to get static binaries out of it at all.

The golang model expects all golang deps to be distributed as source code, and then it expects to dynamically link to all C dependencies. It is technically possible to diverge from the latter set of expectations, but it is not easily or commonly done.

C++ is much like golang in that respect. Template libraries are always "static" in the sense that they are distributed only as source code, but the final binary output is almost always a dynamically linked binary.

Distribution packagers often remove statically linked libraries from upstream and make the software dynamically link anyway.

I'm not saying that the UX of native packages is great for end users. I'm just saying that the security model is saner.

That cat is already out of the bag. How many Ubuntu users have custom software sources enabled; how many of them are installing games from Humble Bundle that come as their own `deb` packages with statically linked assets? GoG installed Linux games don't even use the package manager at all.

Heck, there's a decent amount of Linux software being distributed right now as `tar.gz` files with an install script that just extracts the folder someplace and then modifies the user's path.

Flatpak improves on all of that.

It's one thing to look at the Linux security model and say that OSS authors should coordinate with distros, but OSS authors and general Linux developers already don't do that today. So how is Flatpak making that situation any worse?

Developers were already abandoning the sane security model. Flatpak is a response to that trend, not the cause of it.

>How many Ubuntu users have custom software sources enabled; how many of them are installing games from Humble Bundle that come as their own `deb` packages with statically linked assets?

I don't have an answer to this question, but I would never do this. If the game was open source, I would rebuild it to be dynamically linked, and then publish the dynamically linked package.

If this is genuinely your philosophy then Flatpak isn't a real problem for you because you can take any OS application that's bundled with Flatpak, rebuild it to be dynamically linked, and then publish the new package using whatever package manager you prefer.

Or, alternatively, create a new flatpak runtime and rebuild it for that.

The distribution can recompile dependent packages if required without requiring the upstream program to release a new version no matter how the libraries are linked.

In which case, the problem isn't Flatpak, it's packages that are distributed outside of the distro's control. If Ubuntu was the ultimate distributor of every Flatpak on their system, they could also recompile and update the dependencies for those Flatpaks whenever a security risk was discovered.

Should we get rid of the AUR while we're killing Flatpak?

If applications are distributed by the same people, at the same frequency, linked against the same versions of the dependencies, why have two distribution mechanisms at all? What you're describing sounds like it could be a separate APT channel ("backports", "non-free", "edge", hell call it "flatpak" if you want) but doesn't need another package manager and package format.

That's what I was getting at -- the defense that package managers handle everything in the existing system falls apart as soon as you start compiling packages from source, adding custom repos, or installing proprietary packages, many of which will statically link their dependencies or use custom versions of libraries. There's nothing a distro maintainer can do about them.

The "authors won't keep their own software up to date" point isn't an argument against Flatpak in specific, it's an argument against custom package sources in general.

If we really don't trust authors to update their own software, then we ought to be pushing for even stricter sandboxing and system isolation than what Flatpak currently provides. The cat is already out of the bag: people already run software on their system from the AUR, from private repos, from custom Linux installers that just bundle everything into a tar.gzip. Dynamic linking won't save you from them.

> If Ubuntu was the ultimate distributor of every Flatpak on their system, they could also recompile and update the dependencies for those Flatpaks whenever a security risk was discovered.

If Ubuntu was the ultimate distributor of every Flatpak and had the means to recompile and update the dependencies for those Flatpaks whenever a security risk was discovered, they wouldn't need Flatpak. They could just maintain the software the way they've always done before.

Consider what the advantages to Flatpak really are.

1. Anyone can publish them (low standard of inclusion, which I hope isn't Ubuntu's goal)

2. You can easily distribute closed-source software with the exact dependencies they were compiled for (which Ubuntu can't change unless they have access to the source code and its maintainers are willing to provide that charity to closed source software shops)

3. You can easily install the software on any system with a recent enough kernel (Ubuntu being the sole provider wouldn't change that)

It's not as robust as it could be, but Flatpak pretty objectively has better sandboxing than a .deb package once you get rid of the dynamic linking problem. That's a good thing, because not all security bugs come from dependency management. But, ignore the sandboxing aspect for a second:

1. Ease of distribution of software should be a goal on Linux if it's not already. The lack of ease of distribution of software contributes to decreased support from developers on other OSes, increased pressure and stress for distro maintainers, and some truly awful installation methods outside of the official package managers.

2. Proprietary software largely already does this, so granted, using Flatpak doesn't really change anything. But that's also kind of the point; proprietary software already ignores the software center, so adding better sandboxing to those apps is a really good idea.

3. There are reasons to want the ability to link against multiple versions of the same dependency even if you're getting all of your software compiled by a single source upstream. Reconciling dependencies if you're a distro maintainer is hard. Being able to quickly update any app that's using an outdated dependency without worrying that you're going to break another app is kind of nice.

I'm not saying that Flatpaks should be centrally managed. My point was that people are already distributing software outside of app stores. We already have the AUR, we already have `tar.gz` files (even from Open Source projects), we already have custom repos that might break/rename/embed old dependencies.

Flatpak is responding to a trend that already exists; trying to make it slightly better so that instead of a random install script somebody pulls off Github to curl dependencies, they get a well-defined package that's less likely to bork their system or introduce a security hole into their other applications.

And that's good. We want to live in a world where people can install software from any source -- we wouldn't use Linux otherwise. But any system where people can install software from any source is going to have the same issues with dependency management and with trusting the author to keep their app up-to-date. All of the problems people are throwing at Flatpak in that specific area are just criticisms of the fact that Flatpak isn't centrally controlled. They're not really criticisms of the technology itself.

Those problems were brought up as objections the very minute that Flatpak and Snappy arrived.

OP has just provided concrete examples of those problems appearing in the real, existing public repos for Flatpak.

This is not surprising.

It has turned out exactly as expected: Upstream developers cannot be trusted to update dependencies on a timely basis.

> Upstream developers cannot be trusted to update dependencies on a timely basis.

And the current system, even without Flatpak, doesn't force them to. You're not arguing against Flatpak, you're arguing against decentralized app distribution in general.

You are already living in a world where upstream developers can decide to distribute their software using channels that distro maintainers can't control, update, or patch.

Flatpak changes nothing about that arrangement, it merely acknowledges that the problem exists and tries to make it slightly better. The alternative to Flatpak for a lot of Open Source devs isn't an official Debian package, it's a tar.gz file, which is just objectively worse.

I think the industry has moved past believing that dynamic linking has a net security and usability benefit over static linking/sandboxing, even if you heavily bias toward preferring security. The three most "modern" and popular linux "package managers" made in the last decade (Snap, Flatpak, Docker) all bias toward static linking and sandboxing (in the case of docker, forced sandboxing, but the others are opt-in).

Sidenote: I include docker as a package manager in that list because recently I actually ran into a very large and popular command line application that, per their documentation, prefers distribution and execution via docker over anything else: aws-cli. They don't keep any other linux package managers up to date, despite having a package in snap and distributing a .tar.gz. They recommend invoking it via docker. Rather interesting, and I'm surprised we haven't seen a frontend for "docker as a pm" gain traction, to increase usability over "go into your .bashrc and alias aws=docker run aws/aws-cli:latest $*"

I think the industry has "moved past this" because for SaaS platforms, it takes a lot less labor to enforce sandboxing in-house applications on the cloud than to maintain dependencies across the shop. However, for an OS distribution to end users devices, where applications inevitably ask for an are granted MUCH more permissions than they need, this is not a safe model. It is CLEARLY superior for users and for operating system maintainers, or others responsible for user security, to update dependencies using the traditional dynamically linked model. No work needs to be done to consider the compilation tooling of each individual application.

The existence of Flatpak etc. is a misguided concession from the FOSS community to private businesses and to software developers who are used to packaging for the cloud. The model is not appropriate for desktop or mobile software -- there is a reason that filesystem access is extremely restricted or impossible on mobile platforms, and that even Android has moved to dynamically prompting for permissions when apps use them rather than bundling them into a single prompt at installation.

For Flatpak to work, we need MUCH heavier sandboxing, which will be detriment to productivity for desktop users for certain classes of applications, and may prevent many types of applications from being packageable as Flatpak. I think this is a fine compromise. I'm OK with installing Spotify as a Flatpak (given better security, not now) but keeping my webserver, database, file manager, terminal, programming language, and other "system" software in the OS repository.

Docker dynamically links; you don’t need to recompile the world to update a docker image. You just regenerate the docker image.

It can dynamically link within the container, but as far as I know the container as a whole does not dynamically link with the outside world. Its effectively a chroot with a full system image inside that root filesystem.

And that's what we're talking about, effectively; how self-contained and sandboxed the package itself is.

Snap, Flatpack, and Docker applications almost universally use dynamic linking.

They just use some combination of rpath fields and virtual filesystems to make sure the dynamic linker only inspects the paths mandated by the application author.

> Developers are responsible for releasing updates, not flatpak.

That's what distribution maintainers do.

> They are not trying to be more secure than manually installing packages on your system.

That's downgrade from distribution experience.

The primary reason I have when considering using a flatpak or appimage is for software either not commonly included in distros (eg. proprietary software like games) or that are updated more often than the distro cares to manage (eg. browsers). It fills the gaps in distros.

You do not have to abandon distribution model. I've just installed Nix on Arch Linux [1]. It ships all required dependencies - glibc etc - version specific. Works on Ubuntu/Debian [2].

[1] https://wiki.archlinux.org/index.php/Nix

[2] https://ariya.io/2020/05/nix-package-manager-on-ubuntu-or-de...

> You'd expect individual applications might have out of date dependencies. Depending on the application this might be completely fine. This is not a security risk of flatpak but of the application. Developers are responsible for releasing updates, not flatpak.

Not so much in a system that links executable dynamically to system provided libraries (e.g. Debian), or provides system wide maintenance updates to statically linked binaries when their dependencies receive important updates (e.g. Alpine).

...which really covers every sane, actively maintained *nix system with a package manager, so in that sense Flatpak is definitely a step down. Instead of trusting, say, the Debian or OpenBSD maintainers to provide timely security updates, you have to trust each individual vendor of your flatpaks.

The only advantage I can see for them is in providing closed source software, which OS maintainers simply can't maintain and update. A developer advantage may be that the standard of inclusion is much lower than for Debian or OpenBSD, but that's IMO a user disadvantage.

> Instead of trusting, say, the Debian or OpenBSD maintainers to provide timely security updates, you have to trust each individual vendor of your flatpaks.

Well, yes, and it's the most obvious approach. You're trusting the person producing the product for producing a good product.

The distro approach is great, but it doesn't scale well for obvious reasons and it makes software development harder due to downstream issues often going reported as upstream issues.

I appreciate and enjoy the distro approach for what it gives me, but there should always be a way for developers to provide packaging that works everywhere and then distro maintainers can feel free to recompile/repackage as they please.

> You're trusting the person producing the product for producing a good product.

That's a generalization. Specifically, I'm trusting the person producing the product to do something that e.g. Debian has a proven track record of doing quite well: maintaining dependencies so that I have a secure (and consistent) system altogether...so well that I'd rather trust them to do it over any existing flatpak vendor, and definitely more than trusting n vendors for the n flatpaks I have installed.

> The distro approach is great, but it doesn't scale well for obvious reasons

Regarding what aspect doesn't it achieve the scale necessary? It's not obvious to me what you mean at all.

> and it makes software development harder due to downstream issues often going reported as upstream issues.

A cost of system-scale software maintenance, for sure.

> I appreciate and enjoy the distro approach for what it gives me, but there should always be a way for developers to provide packaging that works everywhere and then distro maintainers can feel free to recompile/repackage as they please.

I don't fundamentally disagree. My point is that I think it's a security risk to leave it to every developer to maintain their dependencies as they see fit, and that this is a problem that flatpaks create that a well maintained distro software repo doesn't have. It's better to acknowledge this risk and consider it to grow as you install more flatpaks than to ignore it, expecting that every flatpak vendor will respond in a timely manner to dependency CVEs; the trust I place in Debian—by necessity very high—now has to be multiplied for each individual flatpak.

> This is not a security risk of flatpak but of the application. Developers are responsible for releasing updates, not flatpak

If it was a regular application installed by a linux package manager, the dependencies will be automatically updated to fix security issues(At least in most cases).

> You'd expect the application to run as your user and have full access to the home directory. Many applications expect to have this access. This is what it means to have user space applications. Flatpak is not about fixing or changing this.

I as an user could at least expect a sandbox that protects a rogue application from modifying or even reading critical files without user consent: .config of other applications, .ssh/, shell configs (profile, rc). A web browser may require create-write access to ~/Downloads but not arbitrary read or write access anywhere else with the exception of save-as/upload explicitly requested by the user*, and that could be done by the OS file selection dialog giving back the filename + a token. And so on.

Perhaps it could even be abstracted to a common "profile" for application classes, and go even further than that and have stuff like raw USB/Bluetooth not authorized by the browser but by the OS/sandbox layer (to prevent attackers exploiting a browser bug).

So wait ... It's in my way for no reason?

/snark

I get the idea of Flatpak. I want some kind of app sandboxing. Ideally with a good UX and shared libraries, however.

> Instead, providing a cross distribution consistent installation experience is the main goal.

Who is asking this exactly?

As an arch user and technically a fedora, Gentoo, slackware, Ubuntu, debian user, I'm not asking for this.

I like how I install packages.

Installing garbage from a webpage like some windows pleb or having to eject weird desktop download things after drag and dropping things on a Mac is not something I want.

Please stop pushing this idea about flatpak being better, its not for a lot of users and for me, security doesn't even enter the equation.

But the idea that random flatpak maintainer has better security processes I place than the sec team for many distros is laughable at best.

You can wrangle the argument all you like about ideal world scenarios but the fact of the matter remains that suboptimal ideal still works out as more effective in the real world. Tragedy of the commons problems generally do require sub optimal solutions in the small to solve in the large.

There’s a lot of good software that isn’t in package repos. This isn’t a failure in the developers part. It takes knowledge and time and effort to package for a repo, let alone all the different repos on each distro. Flat pack gives a single way to distribute something and on that merit alone it’s valuable.

Again, to whom?

Arch has aur, arch can sideload rpm/Deb's, Mac has home brew, who needs this?

The only people I see using flatpak is the 50 odd Linux users we have at work, they constantly have dramas trying to make things work around home directory sandboxing, permissions, updating and more

> Single way

Why is this valuable? Just saying it doesn't make it true.

Why do we need a single way to install?

I'm not saying it's a bad thing, but giving up home dirs and a bunch of other platform specific benefits is a cost I'm not willing to pay for some made up ideal that gives me a worse experience.

Did you know, and this may shock you, that there are other people with other interests. Also, and this one is really going to blow your mind, these other "people" (plebes if you will), may value different things and want products that are of no interest to you.

Flatpak sounds like a shitshow, but the not because it doesn't meet your specific requirements.

> Again, to whom?

Are you trolling? I think the answer is obvious: less duplication of efforts may make the linux ecosystem be more lean which may mean more manpower to... bring the year of the linux desktop.

If you avoid duplication of effort by doing something worse than existing solutions, is that progress?

Distro package managers have more than 20 years doing this. If you want to replace them I think there should be fewer drawbacks. Otherwise you are throwing out decades of design, thought, bug fixes for something more problematic.

You are assuming that packaging is a substantial burden when compared to making a complex application and that that labor translates ultimately into tangible benefits.

If the packaging is done by the dev you are assuming that 1% extra effort wont be spent playing chess instead of adding features.

If the packaging is down by an interested party for that distro you are assuming that a person competent to write a package file is even competent to say write an app let alone interested in doing so.

To me at least, but I'm sure there is more people than me who wants this.

Almost every package manager on Linux distros allow you to install packages outside of the main repositories and still manage dependencies using the repos.

I agree there are a lot of distros to package for, but I'd say the bonus of not having to maintain and update all the dependencies outweighs that fact.

For example, there are a lot of tools that can generate Debian packages for you if you don't want to spend any time learning the manifests. I assume these exist for most distros.

Even if there are easy tools available, I'd still need to learn them for each distro I want to support. Heck, just figuring out the different names each distro uses for a particular package is a fair bit of work.

Just use Gnu Stow as a secondary package manager and install into the /usr/local tree.

The discussion is about packaging your software for users, not yourself. Stow is a solution for managing non-packages software on your personal system, not for distributing it.

Most people don't package their software for distros.

Smart distros keep things close to upstream so the burden is small.

This is a weird argument.

Now you want each developer to manage dependency updates for their application? I don't trust them to develop their own app let alone apply security patches properly.

As a free software developer of Windows, Linux and Mac software I would not want to have to need to be "approved by the gods" in order to release an application to the AppStore / SnapStore / Windows Store and whatever is called in the different flavors of linux.

I put my software in my webpage and whoever wants to download it and use it does it. If they don't trust it well then I'm sorry.

You can self-host Flatpak repositories with flat-manager, which differentiates Flatpak from the App/Snap/Windows Stores.

https://docs.flatpak.org/en/latest/hosting-a-repository.html

https://github.com/flatpak/flat-manager

As a Gentoo user, I very much welcome being able to pull in some applications that are closed source and/or not part of the portage tree without the hassle of finding out how exactly the base platform that it was compiled against looks like. For a while I had to keep a lot of 32bit versions of libraries around just to make Steam happy, and build the stupidly large qtwebengine just for the Nextcloud client. Nowadays I get both of them via Flatpak without hassle and can keep a leaner base system.

Why do you exactly run Gentoo in the first place if you don't actually value building the dependencies from source?

That's an odd question. I absolutely value having almost everything built from source and the control I get from that through use-flags.

That doesn't mean I enjoy compiling some incarnation of webkit every few weeks for multiple hours on a laptop, in particular if it's just for a single application (in this case: Nextcloud client). Same for 32bit stuff, I have absolutely zero use for these libraries outside of closed-source games, so I'd rather have them just work than full control over them.

As a Gentoo/Funtoo user, I feel like we can solve this problem with better security by running applications in Docker. See Funtoo's approach to Steam for example.

https://www.funtoo.org/Steam

> As an arch user

> like some windows pleb

I'm not sure if you're serious or making fun of stereotypes and thus don't know how to respond.

Seriously making fun of windows plebs? Yes. How anyone trusts Mac/windows these days still amazes me.

It's for the people who spent their free time to write the software that you use for free and call plebs.

Then don't use Flatpak!

The other side is that Software Developer Foo isn't necessarily going to have the resources/inclination to work with your distro maintainer. You may decide to avoid Foo's software as a result, and that's totally fine—but if I like Foo's software and want to use it, Flatpak gives me that opportunity.

I don't and I won't but I'm still looking to point out its shortcomings whenever it comes up.

Staying silent is as good as encouraging the echo chamber outright.

People are pushing this shit because it's trendy not because it's good.

Well, getting the wrong version (years old, not what the developer designated as stable & supported as of yesterday) of absolutely everything I care about is actually kind of really annoying with most contemporary linux distributions.

But basically, as with anything open source, if you don't like it, don't use it, make some other choices, or build your own. I see a lot of people whining and stamping their feet here but not a lot people building alternatives. Quit whining & start coding if it matters that much to you. As far as I can see there's Flatpack, Snap, and not much else here because nobody can be bothered apparently.

Microsoft calls typescript stable. I find bugs in it all the time.

I don't trust developers to designate things as stable.

Flatpak is supposed to be the solution for installing proprietary app while staying safe. For open source software, less value for using flatpak apart from no need for package in multiple format for different distro. Appimage also solve the same problem.

Now is flatpak secure for installing closed source app? At least not when they have full x11 access when using x11 desktop.

I can see two opensource groups that benefit from this. Maintainers can produce quality packages that don't vary unintentionally between target systems with less effort to produce. Package consumers can rely on having the same quality packages on varying systems. I use Ubuntu Server mostly because its packages are highly consumed. If I could get the same packaging on a different system I wouldn't have to worry about arbitrary variations not related to the distro but different just because it's produced through a separate workflow.

Not that I expected different from a "l337" Arch user, but "Windows plebs" have had "chocolatey" and the Windows Store for a while now...

> They don't mention sandboxing on their frontpage, at all. This is not a goal.

...and without this "fake sandboxing" strawman, flatkill.org is left without a convincing argument.

The security trade-offs that come with flatpak are the same tradeoffs that desktop operating systems like MacOS and Windows have made since their inception.

Considering that these are successful desktop operating systems, whereas Linux is not, one might conclude that these are the right tradeoffs, all things considered. Sure, it's "a security nightmare", but we've been living through it for decades. The alternatives clearly aren't good enough to bring everyone to move over.

Scroll down that page. The ui integration problem is real

I'm not saying that any of these problems aren't real. Many applications on Windows and some on MacOS disregard theme settings as well. That's not a security issue though, and it's fixable.

Reply on news.ycombinator.com