Flatpak: A security nightmare – two years later

Re:Flatpak: A security nightmare – two years later by kevincox on Friday October 02, 2020 @11:22AM (#24663552)

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.

[ Parent | on HN ]

Re:Flatpak: A security nightmare – two years later by danShumway on Friday October 02, 2020 @12:04PM (#24663999)

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?

[ Parent | on HN ]

Re:Flatpak: A security nightmare – two years later by remram on Friday October 02, 2020 @12:54PM (#24664534)

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.

[ Parent | on HN ]

Re:Flatpak: A security nightmare – two years later by danShumway on Friday October 02, 2020 @02:12PM (#24665329)

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.

[ Parent | on HN ]

Re:Flatpak: A security nightmare – two years later by boomlinde on Friday October 02, 2020 @05:05PM (#24667016)

> 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)

[ Parent | on HN ]

Re:Flatpak: A security nightmare – two years later by danShumway on Friday October 02, 2020 @07:37PM (#24668137)

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.

[ Parent | on HN ]

Re:Flatpak: A security nightmare – two years later by hapless on Saturday October 03, 2020 @12:40PM (#24673124)

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.

[ Parent | on HN ]

Re:Flatpak: A security nightmare – two years later by danShumway on Saturday October 03, 2020 @10:09PM (#24676094)

> 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.

[ Parent | on HN ]