Response to Flatkill.org | Hacker News Reader

Response to Flatkill.org

theevilskeleton.frama.io

65 pointszdw81 comments

I've contributed to flathub, so I might be biased, but what I never got about the "flatkill" rant (which was first posted like 3-4 years ago) is that flatpak has never claimed to be a security panacea. They didn't invent flatpak for the sake of security. Flatpak is fundamentally a distro-agnostic packaging mechanism and build environment with some clever abstractions to avoid static linking and encourage code reuse. Theoretically, it's also got the potential to make things more secure, but it wasn't ever billed as the main idea.

My dad was always a windows guy, but recently I got him using linux mint for some of his ham radio stuff. Flatpak and flathub are perfect for people like him. And that's good enough.

I got the same impression. Flatpak seemed much more like 21st century static linking with some slowly evolving security features bolted on top.

The other thing I didn't get about the flatkill rant was why it didn't put flatpak in context. It makes much more sense compare the security of flatpak to that of appimage and snap than to look at flatpak as an isolated thing.

Yep - perfect is the enemy of good.

For me the advantage of flatpak is that it makes things a lot easier to install, abstracting away all the detail between different Linux distros.

The layering is good + because of immutability, you have a system that is a lot closer to the one the devs actually used.

There is a little more security, which is a bonus too, but that's not the main draw.

To be fair the default software supply chain integrity story and sandboxing of docker, snap, and appimage are also terrible. They all solve the same "problem".

Without dedicated parties to maintain updates... like a distro, most of the packages distributed with these tools just make Linux less secure even if the tools themselves are useful in right context.

The docs and authors of these tools are trying to bring to Linux the "go on the internet and get a random .exe" model of Windows which is a proven security nightmare.

If you like that concept, then AppFS [0] is even more interesting since it removes the "install" step. CernVMFS [1] is very similar to AppFS, though AppFS has more features.

[0] https://appfs.rkeene.org/ [1] https://cernvm.cern.ch/fs/

Perhaps the messaging has changed or I came at it from a different angle, but my memory is that when I first investigated flatpak they promoted the security aspect of the sandbox, and that I was later genuinely confused when I found out that the apps could specify their own sandbox setting without specifically asking me on install.

There is security aspect of the sandbox, but that does not mean it is turned up to the 11 for every single package since day 1.

Especially if the result is, that it would break or make unusable the package.

No, the intent is to have evolution: provide a mechanism for some scenarios, update apps where possible, provide for more scenarios, update additional apps, and improve continuously, till you achieve the securing aspect.

Treating it as if it was a flip of the switch, and then badmouthing it when it turns out it is not, is not a good faith contribution.

Flatpak sandboxes are security theater. The goal of the sandbox is fantastic. But until apps are actually sandboxed they shouldn't call it a sandbox. "Trivially bypass-able security is better than no security" is just a bad thing to have to say to defend something.

Again, it is not something that can be done with a flip of a switch, across the entire ecosystem.

Rome wasn't built in a day either.

I agree. Now why is it called a sandbox if it isnt one?

Why is iptables called firewall, when you can put in rule to accept all the traffic?

It is a tool. It is configured into such a way, where it provides most value to most users. If you want to use in another way, you are free to do so.

Sandboxes are not the same thing as firewalls. iOS apps and web apps have a real sandbox. Those apps can never take over your system without a zeroday. Flatpaks apps can get and a huge percentage actually have gotten permissions to do that, so it isn't a sandbox. So they shouldn't call it a sandbox. I will celebrate the day 0% of flatpak apps can trivially escape their "sandbox". Until then I will call out flatpak for misusing language, overselling their product and misleading users.

iOS and web apps were designed and developed with the limitations given by the sandbox from scratch; there are exactly zero iOS applications in existence that didn'assume sandbox limits.

Flatpak applications are retrofits; they were originally developed with the assumption of the full access to the system (as permitted by permissions); so in order to remain useful, there has to be a transitional mechanism. No user would install an app, that is perfectly sandboxed, but no longer fit for purpose.

The same thing applies to MacOS, MacOS sandbox and MAS (MacOS App Store), it is the same store. You can also see apps that are being offered outside MAS exclusively, or the MAS version having limited features compared to versions that you can obtain outside MAS.

This also highlights difference between mobile and desktop apps: mobile apps are silos, that silo user data and only that one given application operates on them. Desktop apps on the other hand are built on cooperating; the user has a set of files that he organizes and then miscellaneous app operate on them. For this to work, the apps need to be provided access; thus they cannot silo user data for themselves.

https://web.archive.org/web/20160624093121/http://flatpak.or...

> Sandboxes

> Flatpak isolates apps from the host OS as well as from other applications. This provides security for users and a predictable environment for developers.

Nice of you to leave off the only remaining sentence in that paragraph:

> (Some of these features are work in progress)

But seriously, there's nothing inconsistent here. All the major headings on that page are about distro-agnostic app distribution, build environments, and portability. The fact that flatpak has mechanisms for sandboxing that go largely unused on flathub doesn't mean that flatpak misrepresented itself as secure.

In an alternative universe, on a private flatpak repository, flatpak (as a technology) facilitates secure sandboxed desktop applications. It just didn't turn out that way in our universe, or at least, not yet.

> Nice of you to leave off the only remaining sentence in that paragraph:

> (Some of these features are work in progress)

I left it off because it doesn't change anything when talking about the announced goals ?

> But seriously, there's nothing inconsistent here. All the major headings on that page are about distro-agnostic app distribution, build environments, and portability. The fact that flatpak has mechanisms for sandboxing that go largely unused on flathub doesn't mean that flatpak misrepresented itself as secure.

https://docs.flatpak.org/en/latest/sandbox-permissions.html

> One of Flatpak’s main goals is to increase the security of desktop systems by isolating applications from one another. This is achieved using sandboxing and means that, by default, applications that are run with Flatpak have extremely limited access to the host environment.

how can it be written more clearly ?

hell, the first press release has "security first" as headline:

https://flatpak.org/press/2016-06-21-flatpak-released/

And under that "Security first" headline reads the following:

> "Initial Flatpak releases have concentrated on application building, distribution and installation, and while the foundations of sandboxing are in place, there are still missing pieces."

I don't understand how you can say "flatpak has never claimed to be a security panacea. They didn't invent flatpak for the sake of security." and read that while keeping a straight face.

Even if it takes 3 decades, it's still a goal that was there (and advertised as such) from the very inception of the project, 5-6 years ago.

What I wrote is,

> flatpak has never claimed to be a security panacea.

> They didn't invent flatpak for the sake of security.

> Flatpak is fundamentally a distro-agnostic packaging mechanism.

> [Security] wasn't ever billed as the main idea.

and we keep digging up old posts from the flatpak folks that say their main focus isn't security, and that security isn't ready, and that the primary usage is as an environment for desktop apps to be built, packaged, and distributed.

Are they not allowed to think about security and sandboxing without making it their primary focus on day one?

> Are they not allowed to think about security and sandboxing without making it their primary focus on day one?

a headline that titles "security first" is incompatible with security not being one of their main focus. They had to think better about it (or issue a rectification press release later).

> They didn't invent flatpak for the sake of security

[citation needed]

Alex Larsson speaks to the "security model" in his blog posts. [0],[1],[2]

Without a strong security/sandboxing story, there is no flathub or general confidence in running binaries received directly from developers vs. the traditional distro model.

Distros have historically served as trusted arbiters. One of Flatpak's stated goals is to bypass distros in the interests of enabling end-users to more closely track developer releases of software.

This exposes end-users to substantial risks, and Flatpak relies on sandboxing to mitigate those risks.

I find it obviously inconsistent with Alex's posts for Flatpak's GUI to claim apps are sandboxed, when they're directly accessing the host filesystem and/or user's home directory, and don't utilize portals.

[0] https://blogs.gnome.org/alexl/2017/01/18/the-flatpak-securit...

[1] https://blogs.gnome.org/alexl/2017/01/20/the-flatpak-securit...

[2] https://blogs.gnome.org/alexl/2017/01/24/the-flatpak-securit...

> clever abstractions to avoid static linking

the really clever thing would be to embrace static linking

You cannot really have static binary on modern linux with contemporary glibc.

Unless you intend to break services NSS, that is. Even golang runtime checks for NSS config before ignoring glibc.

This is indeed a major and shameful bug of GNU libc. There's no fundamental reason why NSS services cannot be statically linked. My pet conspiracy theory is that some glibc authors were anti-static linking fanatics (probably Drepper), and tried hard so that it was difficult to static link. Fortunately, we have musl libc where static linking works without trouble, and by the way produces smaller binaries.

NSS modules are actually plugins, so they have to be dynamic. They don't have to be shipped with glibc, other libs can ship their own, or even be standalone. For example, nss-mdns used to be standalone, or nss-resolve ships with systemd-resolved.

NSS should have been a service spoken to over e.g. UNIX domain sockets.

From TFA regarding security updates on libraries and dependencies:

"A valid point. Since the Flatpak developers were fully aware of this problem, they came up with an acceptable and easy solution: flatpak-external-data-checker (f-e-d-c). f-e-d-c is a tool that automatically checks for external sources, such as dependencies and binaries. When an update is found, flathubbot automatically submits a merge request. Here are some concrete examples: [1] [2]."

At this point, it's getting more complex and harder to deploy than dynamically linked binaries, is it not?

> While punching holes in the sandbox is not the most secure implementation in the world, it is only a temporary solution. It is better than not sandboxing at all.

Is it though? My point of view is that it is the worst of both worlds. On one side application developers have to deal with changing Flatpak features like portals and the complexities of making their app work sandboxed, and on the other side users get no actual security whatsoever since there are still giant holes like bashrc.

It would probably be better to disable security features entirely, so that apps can be packaged easily, until they provide actual security for the users. Since app developers will have to re-package anyway, make them do it then. In the meantime everyone is just alpha-testing features that don't provide value.

> A few months ago, I submitted an issue in the Gitg issue tracker. The maintainer replied to me: “Reviewing ssh feature, it is not even touched on gitg or libgit2-glib, just a dependency on libgit2, […]“.(Source)

> Although it comes with an unpatched libssh2, Gitg does not use the part that contains the vulnerability.

This conclusion is plain false. The maintainer comment he quotes only says that gitg doesn't directly use libssh2 (so they can't enforce a version constraint on it), not that it doesn't use it all. It's very likely that gitg does actually use the vulnerable libssh2 if you use it to clone a repository over SSH (which it can do).

While discussing applications that are advertised by Flatpak's application metadata as sandboxed: "Allowing access to the host file system does not give the application full reign over your system."

The Flatpak documentation he then links to contradicts his rather controversial idea that a sandboxed application have access to the host file system.

"With Flatpak, each application is built and run in an isolated environment, which is called the ‘sandbox’. Each sandbox contains an application and its runtime. By default, the application can only access the contents of its sandbox. Access to user files, network, graphics sockets, subsystems on the bus and devices have to be explicitly granted. Access to other things, such as other processes, is deliberately not possible."

The author sounds extremely defensive, either ship a decent product or don't. If it becomes something where getting exceptions for sandboxing are so absolutely difficult most people skip it all together and ask for full access, you might as well just install directly from apt.

I also hate snaps, apt get install whatever you need, and be done with it.

And what about when apt doesn't have a package for the thing you want? You can install Spotify, Steam, Discord, Microsoft Edge, Zoom, and Minecraft with flatpak.

Usually their developers will have ppas.

And what if i do not use a debian based distro for which the ppa works?

Maintaining one package that works on all distros is a lot easier.

ppas doesn't work if you don't use ubuntu/debian. And not everybody was willing to go through the trouble of making a ppa, an AUR package, a custom .rpm, etc, etc.

You can install Spotify and Zoom with apt.

And Discord and Steam.

Zoom throws a `zoom_latest.deb` on their website with no repo, you just need to remember to go there and download it for updates, by hand. Given zoom's security record, no thanks.

Yeah, that's pretty shitty.

you listed Electron apps, a java game that runs without external deps, and something nobody would want to install anyway.

Absolutely none of those justify fat apps as they are already fat apps in themselves! I don't even...

> either ship a decent product or don't.

Why the need to be so aggressive toward open-source contributor ? And most product become good through iterative refinement. Ship it and listen to feedback to make it better is a perfectly valid way to do things, especially for open-source project.

> I also hate snaps, apt get install whatever you need, and be done with it.

Then you are not the target demographic for snap or flatpack. I personally had to often install application that where not available on my distro repo, and the plurality of way to install application, plus manage their own dependencies, was a nightmare.

> the plurality of way to install application, plus manage their own dependencies, was a nightmare.

https://xkcd.com/927/

Also relevant: https://xkcd.com/1654/

>Then you are not the target demographic for snap or flatpack.

You know it would be great if they shipped default Ubuntu with a big flyer that said "don't like snaps? you're not the target demographic"

To be fair, as Linux users we generally can build from source if all else fails.

Now if you have some weird application which isn't built for your distro AND is closed source , you may run into problems .

Wouldn't apt give full access as well?

Flatpack allows it to work on all distro, isn't that the point?

Yes and yes. GP's point is that the distro's package manager is already an ultra reliable way to get non-sandboxed software.

Except it relies on benevolent volunteers to maintain the packages and make sure they are up to date for your distro. I think having a standard where the app developer can easily provide a single package which can be distributed and installed on all distros would be beneficial.

Whereas flatpak doesn't rely on benevolent volunteers? I think having a dedicated community where maintainers can easily pool their package updates together would be more reliable.

> Whereas flatpak doesn't rely on benevolent volunteers?

It doesn't on the distribution side. Yes it's maintained by volunteers, but the packaging and distribution is not, it can be done by the application developer.

So if I make a desktop application for Linux, I can do a flatpack build of it, and now all distros can install my app. Where as traditionally, I would have had to make multiple builds for targeting different distros. So generally, what happens is the app developer maintains a build for the most popular distro only, and there are other volunteers in other distros who try and repackage it for other distros and maintain it up to date, etc.

While I kind of get the problem flathub is trying to solve. I have to ask how often have you guys found yourself unable find a package (in your distributions package manager) for the software you want. I personally use debian (now in qubes os). And for all the software I want there is either a package in the debian repositories, or there is a ppa, or a single sad package on the devs site.

> I have to ask how often have you guys found yourself unable find a package

Often enough if you don't use Debian/Ubuntu/Fedora. Similarly, the package might be out of date.

That eventually more of the software can be sandboxed is nice as well.

Debian kind of spoils you in this regard though. Go out of Debian and Ubuntu, and you are probably going to miss some package at some point.

On Debian, Flatpak can still be useful to get the latest version of some apps too.

I'm not a big fan however. At work, I'm using the Kate Flatpak package on Debian Buster (to have syntax highlighting for the programming language I use), but the open and save dialogs are a bit buggy and you cannot open another file in a new tab from the terminal or the file manager (it will open a new window). Integration is not great, I often just use the native Kate and do without the syntax highlight.

> I have to ask how often have you guys found yourself unable find a package (in your distributions package manager) for the software you want.

Very often. Or I just want a updated version. There is a lot of small/obscure open-source tool available on github (for example) to do X or Y. Most of them don't have a package, and if they have, it is often not really maintained and very outdated. The same apply if you need to use closed-source / not entirely open-source software.

I remember all the time I had to figure out what kind of build system the app was using, running cmake/make/some weird build sys, only to figure out that I was missing some lib, and that the repo version was not compatible so I had to also deal with dependency manually, and then figure out the different build option, ...

As a developer who wants to build an app from source: all the bloody time. Especially problematic if I'm using a distro with an immutable root file system, like Fedora Silverblue, but let's be honest, sorting through peoples' bizarre build requirements and consolidating that with the distro you're running can be a full time job. Flatpak means your app has a manifest file that describes all of its dependencies precisely. This integrates really well with GNOME Builder[1]. If you're interested: install and run Builder, clone https://gitlab.gnome.org/GNOME/nautilus, make a change if you'd like, (make sure Builder is using the `org.gnome.Nautilus.json` build configuration), wait for it to fetch dependencies, and run the thing. There's a bit of tedium in fetching bits you might already have[2], but the tedium is reproducible.

And as a developer who wants to release software myself instead of dealing with distros, this is also a vastly better experience. It fits smoothly into a development workflow, and I can just release my thing and have binaries for people to install right away, in a place I control. Distros can still package the thing if they want to for some reason (and Flatpak does a good job encouraging you to use a real build system), but as the developer of the app I get to provide a one click install that actually works (and gets updates, and doesn't pollute your sources.list or give me root access to your system via postinstall scripts).

[1] https://wiki.gnome.org/Apps/Builder

[2] Flatpak deduplicates things quite well, but it doesn't care if you already have a particular library on the host, and it treats version 1.0.4 of something as completely, entirely different from version 1.0.3, so if you look really closely you'll notice both are on your disk somewhere. But this is the price we pay for reproducible builds, and they're definitely worth it. (See also, Buildstream: https://www.buildstream.build/).

It happens oftentimes that you want a newer version and your distro doesn't have it yet.

Also, you have to think from the distributor as well, if you want to make an app for linux, how do you go about having it packaged and distributed for all distros? You need to manage so many different package manager, its a lot of overhead.

"Flatpak fixes that issue by providing consistent builds for every distribution" - aka https://xkcd.com/927/ "Standards"

I get the point of flatpak and I see its value. Personally I just don't need yet another channel through which I need to get stuff. Ubuntu has already obnoxiously fragmented [1], this is just another fragmentation I don't want

   [1] chunky@mills:~$ erl

   Command 'erl' not found, but can be installed with:

   sudo snap install erlang            # version 22.3.4.1, or
   sudo apt  install erlang-base       # version 1:22.2.7+dfsg-1

Also there's this annoying gem:

    $ sudo apt install cpufreq
    
    No apt package "cpufreq", but there is a snap with that name.
    Try "snap install cpufreq"

Can't say I'm getting the point of either snap or flatpak when the whole point of using a distro is that's a trusted/curated set of software. Moreover, snaps frequently just don't seem to work for me whereas the regular .deb does.

I don't use Ubuntu anymore because it's turned into a garbage heap. Debian, Arch, or Qubes. (Fedora-Cent-RHEL are boned. Cent-RHEL has/had an awesome stable kernel due to enterprise-scale bug fixes but that's likely to end. Debian is a good substitute.)

If I need the latest-greatest on a stable release OS, I use habitat.

> Fedora-Cent-RHEL are boned.

Care to elaborate on that? Curious where your position on this is coming from.

You may not be aware of what's happened:

IBM buys RHEL and immediately messes with its products and culture.

https://www.cnbc.com/2019/07/09/ibm-closes-its-34-billion-ac...

https://itsfoss.com/centos-stream-fiasco/

CentOS is no longer basically functionally-equivalent to RHEL.

https://www.theregister.com/2020/12/09/centos_red_hat/

IBM (through Red Hat) runs the Fedora project's board of directors, so there is no real independence from IBM.

Fedora is great, I've been using it daily for 5 years.

How is Fedora going to sustain itself long-term?

http://techrights.org/2020/12/26/fedora-2020-and-ibm-vision/

What is up with everyone posting techrights all of a sudden?

It's a conspiracy blog, and most websites actually paying attention to FOSS news have ignored them for years.

https://www.reddit.com/r/linux/comments/4541p6/can_we_not_po...

Disclaimer: I work for Red Hat. TechRights claimed that there were massive layoffs last year, which is total BS. They literally just make stuff up. The other day they claimed that "Fedora is being outsourced to Microsoft and to AWS" on the basis that some Fedora repos are on Github, and some build infrastructure uses AWS. And mind you the claim was not "Fedora project infrastructure is being outsourced" but actually "Fedora is being outsourced". And that has been the general way they approach "reporting" for years, as you can see from the /r/linux thread.

Then when I and others pointed out how ridiculous this line of reasoning was, and the post got flagged by admins, they made an entire new post claiming they were being censored by HN.

I've personally had better luck with flatpack than snap[0]

I still prefer to install from the OS repos where possible, but I like having choices.

I'd rather be able to install something untrusted through a package manager where I can then at least have it installed in a standardized manner than download a binary and trust myself to remember what I did with it, but that may just be because I'm stupid :) .

[0] Also, it not creating a bunch of loop devices is nice.

Emperor's new clothes. Something for someone to say is "better" while ensuring their job security. In reality it creates too many choices, duplication of effort, too much fragmentation, abandoning standards, and complexifying security, auditing, and configuration management.

If you want isolated software, use something like Qubes (Xen with virtualized containers), not Docker and not flatpak, snap, or anything similar.

Inventing "new" things rather than fixing what already exists is rarely ever a good solution.

I don't see what you mean. Qubes is great, but it is not the same thing as Docker, flatpak, or snap. Are you saying Qubes should somehow be changed so that it works similar to Docker? And if so, why wouldn't you just use Docker?

Then you need to understand how they work differently and their contrasting limitations. Qubes (based on Xen) is great for desktop users to segregate applications. Xen standalone is similarly great for general server containerization.

Docker doesn't work anything remotely like a hypervisor. It doesn't provide the much greater assurance of security, scalability, isolation, resource metering, accounting, or flexibility that a hypervisor does. Docker is a security disaster and it only runs Linux. Xen/Qubes runs Windows, BSDs, or any other OS. Docker seems "easy" but with many subtle costs that come later at scale. You can't live migrate a Docker container from one host to another, where you usually can with Xen using shared storage. There are many other gotchas in the lifecycle of Docker containers that are eliminated or mitigated by using hypervisor guests instead.

flatpak and snap are basically filesystem overlays. They're gross, poorly-managed, incompatible duplications of package management.

I am not sure I see what the significant difference is, I've heard of security escapes happening in both Docker and in various hypervisors. Either way there is a risk of some privilege escalation bug that allows access to the full RAM. I think if you want isolation, both of them lose out to having a separate firewalled off machine. Also I think the companies running heavy Linux workloads on Docker are probably not interested in the ability of Qubes to run Windows or Mac, just my read on the situation from talking to some of them.

I don't know about snap but from what I have seen of flatpak, it allows for different versions of the same package to be installed, not many package managers are supporting that currently. (Nix and Guix being some notable exceptions, and those should be able to re-use some of the sandboxing bits from flatpak if they need to) Of course, that is one of the main benefits to building this on top of filesystem overlays, and why it requires a different approach from a traditional package manager, i.e. it's not just a duplication.

Edit: Live migration actually does work for containers, take a look at CRIU. (I don't know the current status of this being integrated in Docker) I never even saw this as being opposing technology anyway, for example if you need to you could migrate a container in or out of a VM.

I know all about application file systems overlays, I was part of a startup that shipped a multiplatform one. They have many many problems because they blow in a fixed set of dependencies as a monolith. It's a similar to the difference between image-based deployment and configuration management-based deployment: granularity of lifecycle including updates, and management.

The nuances become readily-apparent running anything real at scale, especially if you're only given a herring (Docker) to chop down the mightiness tree in the forest when you need a harvester (hypervisor). Docker, flatpak, and snap are unnecessary other than as shiny, fragile toys that attempt to (poorly) replicate the functionality of other tools. Live migration for containers is like adding high availability to a solar calculator: completely pointless and inappropriate engineering. Just don't get attached to these limited "advances" / fads / religions because popularity and newness aren't the same as demonstrable progress.

It's better to use something like Nix or habitat for multiversion app dependencies or just privately vendor them. There is no need for snap or flatpak if a containerizable OS can choose the correct dependency constraints for an app. The problem of concurrent package versions in existing package management systems can be solved with naming and numbering standards rather than reinventing everything.

I get the point of flatpak and I see its value. Personally I just don't need yet another channel through which I need to get stuff.

IMO Flatpak solves several real problems: 1.) allowing third parties distribute applications in a distro-agnostic manner; 2.) allowing easy installation of packages as a user (rather than requiring root); 3.) a way to install applications on top of an immutable base OS; 4.) sandboxing of applications, or at least packaging applications such that they can move to proper sandboxing over time.

Unfortunately, the development of application bundles follow the prototypical path that we are oh so familiar with as Linux users. Rather than sitting together and making one standard, Canonical (Snap) and Red Hat (Flatpak) made their own application bundle formats, in addition to an already existing format (AppImage). And now vendors have to build bundles in three different formats, like they had to build for at least two package managers before. So, the problem actually got worse.

To Red Hat's credit, Flatpak was initially developed as part of freedesktop.org (initially as xdg-app).

We can always hope that Canonical will give up on Snaps for desktop applications I guess (like they dropped Unity and Upstart).

I think criticism of open source projects is valid, so I'm in no way saying we shouldn't, but it's so frustrating to see people just crapping on a project for not doing things the way the person wants. I can't remember where this quote is from, or who said it, but it gos along the lines of

  As a critic, I'm in the privileged position of being able 
  to critique someone's lifes work

And I think that sentiment could be felt more often. It's so easy to be on the outside looking in and critique everything that is wrong with something. But making things is hard, and trying to fix things that weren't necessarily a priority during a projects inceptions is even harder. I just wish more people would support each other when they share their projects to the world

Recent discussion as part of another submission: https://news.ycombinator.com/item?id=26528805

It's weird that flatkill.org picked Flatpak instead of all container systems or statically linked software.

Well that's the thing: not all of these container systems advertise themselves as having sandboxing built in. Neither do people statically linking.

The AppImage philosophy seems to be much more robust here (and not coincidentally more in-line with the Unix philosophy): focus strictly on the packaging/distribution aspect and defer the sandboxing to separate tools (e.g. Firejail).

They don't advertise, but they have the same issues, which should be dealt with. I don't think it's fine to just say "security doesn't concern us" in the year 2021.

> They don't advertise, but they have the same issues, which should be dealt with.

Which is possible, specifically by deferring to something like Firejail that can handle any application rather than expecting every application format to bake in its own subtly-different mechanism. That is:

> I don't think it's fine to just say "security doesn't concern us" in the year 2021.

That ain't what's being said. What these folks are actually saying is that security and packaging are separate concerns, and that said security should be enforced in one place in a way that's applicable to all programs, no matter their packaging.

security should be enforced in one place in a way that's applicable to all programs, no matter their packaging.

How do you do that without placing contraints on said packaging, though? Will you just blanket-restrict all packages to the strictest security measures? i.e. no network, no access to persistent storage, w^x on all pages? Or will you only provide token security because all features are useful to some apps, and you can't know beforehand what features the app actually needs?

> Will you just blanket-restrict all packages to the strictest security measures?

Seems like a reasonable default to me. And indeed, that seems to be more or less exactly what Firejail does if it doesn't have a profile already for an application: https://firejail.wordpress.com/documentation-2/

There is no practical path to securing the user from software they have installed on their own machine at this point. People protect themselves from bad software by having users install software from a curated repo that contains Firefox the browser from Mozilla not $irefox the cryptocurrency miner.

So basically Flatkill was right. It's weird to see so much written about an issue that could be fixed in like 5 minutes. Just change it so instead of "Sandboxed" it says "Limited Sandbox (?)".

The thing about updating SSH doesn't really feel like a flaw in Flatpak to me. It's just a trade-off. Lying about sandboxing is inexcusable though.

Reply on news.ycombinator.com