Flatpak Is Not the Future • Hacker News Board

Re: Flatpak Is Not the Future

#251

Post by goodpoint » Tue, Nov 23, 2021, 4:07 PM UTC

pas wrote: post #228

goodpoint wrote: post #210

Earlier quoted context omitted.

There are plenty of drawbacks: - Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever. Most do not provide security updates at all. - Privacy: distros like Debian spot and patch out trackers, telemetries and similar things. - Long term maintenability: your desktop becomes a random mashup of applications with increasing complexity that you have…

Debian could provide their packages as flatpacks too. Not to mention that container images are still mostly built by using regular packages, aren't they? (So they are not as opaque, nor the regular packages go untested.)

> Debian could provide their packages as flatpacks too.

That would provide no benefits.

> Not to mention that container images are still mostly built by using regular packages

Yes, and because of the bundling they are a security disaster, as proven by many researchers:

e.g. https://www.infoq.com/news/2020/12/dockerhub-image-vulnerabi... https://www.darkreading.com/threat-intelligence/malicious-or...

Re: Flatpak Is Not the Future

#252

Post by goohle » Tue, Nov 23, 2021, 4:09 PM UTC

fullstop wrote: post #223

enriquto wrote: post #216

Earlier quoted context omitted.

apt is not misleadingly advertised as a sandboxing environment. Flatpack is: "Flatpak: Linux application sandboxing and distribution framework " [0] "It is advertised as offering a sandbox environment in which users can run application software in isolation from the rest of the system." [1] The whole point of a sandboxing environment is that you can run applications that do not want to be sandboxed. The flatpack prop…

Trust of the packager is still involved, no?

When I use something from a distribution, I trust the distribution as organization. When I use something packaged by a developer, I trust the developer. I cannot verify thousands of developers, so I must trust the distribution and I can trust few developers or packagers outside of distribution.

Re: Flatpak Is Not the Future

#253

Post by panick21_ » Tue, Nov 23, 2021, 4:12 PM UTC

southerntofu wrote: post #165

panick21_ wrote: post #96

> If you are a Linux distribution maintainer, please understand what all of these solutions are trying to accomplish. All your hard work in building your software repository, maintaining your libraries, testing countless system configurations, designing a consistent user experience… they are trying to throw all of that away. Every single one of these runtime packaging mechanisms is trying to subvert the operating sys…

> This sound like a luddite that is against machines. The luddites were not anti-tech from a moral perspective, but understood mechanization of work to profit the bosses and go against the interests of workers (artisans) and therefore practiced sabotage. Despite this initial mischaracterization, i believe the metaphor holds and the author is against this application of this technology precisely because they believe i…

Sure, I agree with your interpretation of luddites historically.

However I still think moral is the right word. The consequences are consider amoral. So its is very much a moral perspective.

And I think the argument that it is bad for the ecosystem is fundamentally wrong.

Re: Flatpak Is Not the Future

#254

Post by AnIdiotOnTheNet » Tue, Nov 23, 2021, 4:12 PM UTC

oleg_antonyan wrote: post #69

As Linux user and app developer (shameless plug https://github.com/olegantonyan/mpz/ ) I deliberately avoid snap/flatpak/appimage/etc. Instead, I suffer with Open Build Service https://build.opensuse.org/ . It's kind of cool, free and can build for multiple distros, but making it actually do so is a pain. But I still prefer this over flatpak&co both as user and as developer. It just doesn't look like "the future of a…

If the future of application distribution looks like learning a new language just get things installed, count me out. Linux is obtuse enough as it is.

Re: Flatpak Is Not the Future

#255

Post by goodpoint » Tue, Nov 23, 2021, 4:13 PM UTC

rattlesnakedave wrote: post #230

goodpoint wrote: post #210

Earlier quoted context omitted.

There are plenty of drawbacks: - Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever. Most do not provide security updates at all. - Privacy: distros like Debian spot and patch out trackers, telemetries and similar things. - Long term maintenability: your desktop becomes a random mashup of applications with increasing complexity that you have…

> - Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever. Most do not provide security updates at all. As opposed to what? Dynamic linking does not solve this problem, contrary to popular belief. >- Long term maintenability: your desktop becomes a random mashup of applications with increasing complexity that you have to maintain yourself. Again…

>> - Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever. Most do not provide security updates at all.

> As opposed to what?

Opposed to distributions providing targeted updates to each package.

> Dynamic linking does not solve this problem, contrary to popular belief.

On the contrary it provably works very well for distributions.

>>- Long term maintenability: your desktop becomes a random mashup of applications with increasing complexity that you have to maintain yourself.

>Again, as opposed to what?

Opposed to distributions that do the huge work of packaging, testing, backporting etc.

>>- Licensing issues: distros review licenses (and find plenty of copyright violations while doing so). A flatpak puts you or your company at risk.

>Sounds like a good way for a proprietary software to be distributed...

This is unrelated to the lack of licensing review.

>>- Impact on the ecosystem: the more users switch to opaque blobs the less testing and review is done for proper packages. The whole ecosystem become more vulnerable to supply chain attacks.

>I don't see how one follows the other.

Supply chain attacks are strongly mitigated by maintainers doing vetting and packaging, and by distribution doing release freezing.

Re: Flatpak Is Not the Future

#256

Post by plorkyeran » Tue, Nov 23, 2021, 4:16 PM UTC

yoz-y wrote: post #195

addicted wrote: post #133

Earlier quoted context omitted.

That still does not change the argument that file size does not matter. In fact, this reinforces it. OSX believes file size matters so little they’re willing to double file size simply so users don’t have to pick x64 or x86 when downloading the app (and if they’re using the App Store the App Store could do it for them, but even that Apple thinks is too much complexity).

Not sure about MacApp Store, but on iOS they do trim archs and assets as needed.

That's a surprisingly recent addition on iOS, and it appears to not have made it to macOS.

Re: Flatpak Is Not the Future

#257

Post by AnIdiotOnTheNet » Tue, Nov 23, 2021, 4:19 PM UTC

Zardoz84 wrote: post #149

And nobody talks about Slax modules. Too many years ago, they had some basic containerization (only at filesystem level). If it got some kind of dependency managment, it would be really great.

As I recall, Slax used aufs-based filesystem overlays.

Re: Flatpak Is Not the Future

#258

Post by goodpoint » Tue, Nov 23, 2021, 4:20 PM UTC

alkonaut wrote: post #38

enriquto wrote: post #25

Earlier quoted context omitted.

> it works No. It doesn't. You still need to trust the people who package the thing. A working packaging system would give the user ultimate power to manage access to resources by each app. Overriding or mocking, if the user so decides, whatever access does the app believe to need. Flatpack does not give you such power, it removes this power from you and assigns it to the packagers. Thus, not only it doesn't work: it…

Is there any difference in trust between package maintainers and flatpack packagers? If anything, isn't the flatpack situation better in that regard because the end user is more likely to have a sandbox?

> Is there any difference in trust between package maintainers and flatpack packagers?

Yes, and very big: Debian maintainers need to build a reputation for years to gain upload rights, meet in person, sign keys, and the packages are peer reviewed my multiple persons.

Plus, packages spend time in release freeze being tested by a large userbase before a distro is released.

Re: Flatpak Is Not the Future

#259

Post by smoldesu » Tue, Nov 23, 2021, 4:22 PM UTC

I'll keep this short and sweet, because I could complain about Flatpaks for hours:

If you distribute your software via Flatpak, you can forget about me ever using it. Every computer I own has Flatpak disabled, and I will use system repos until the day I die. Plan accordingly!

Re: Flatpak Is Not the Future

#260

Post by tremon » Tue, Nov 23, 2021, 4:22 PM UTC

pas wrote: post #228

goodpoint wrote: post #210

Earlier quoted context omitted.

There are plenty of drawbacks: - Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever. Most do not provide security updates at all. - Privacy: distros like Debian spot and patch out trackers, telemetries and similar things. - Long term maintenability: your desktop becomes a random mashup of applications with increasing complexity that you have…

Debian could provide their packages as flatpacks too. Not to mention that container images are still mostly built by using regular packages, aren't they? (So they are not as opaque, nor the regular packages go untested.)

So they are not as opaque

Ok, say a wild CVE appears and it says libblip versions 1.3 through 2.0.4 have a severity-10 RCE vulnerability and should be patched ASAP. If the container images and flatpaks are not opaque, I presume you have a simple command that lists all vulnerable library versions that are present on all the machines you administer? And, subsequently, that you have an easy procedure to patch them all?