Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

flatkill.org

Post reply on HN
Print view View original

291–296 of 296 posts

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

#291

Post by AshamedCaptain »

orra wrote: post #248
Spivak wrote: post #202

Earlier quoted context omitted.

But that’s exactly what GTK and QT have! It’s what to do with apps that don’t use some abstraction that supports portals that’s the issue.

Well, there’ll always be a long tail. But if you start with the popular apps and frameworks first, you get the most bang for your buck. It wouldn't surprise me however if sandboxing is only a good model for GUI not console app. IIRC the Windows 10X approach will be to put all non-sandboxed apps in the exact same environment.

As mentioned above, Flatpak is already doing the two most popular toolkits. Programs just don't use toolkits to open files. So there is not a lot of "buck" here, and the tail is rather long.

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

#292

Post by GekkePrutser »

antimba wrote: post #275
GekkePrutser wrote: post #212

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…

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

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.

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

#294

Post by zokula »

mands wrote: post #7

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.

Systemd and Wayland being cancer is not nonsense.

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

#295

Post by ben509 »

hobs wrote: post #204
ben509 wrote: post #201

Earlier quoted context omitted.

If you define "care" as in, "random updates cause enough instability that they make alternate OS's favorable for accomplishing the same tasks," I'd cite Windows autoupdate as fairly hard evidence that people don't care. I imagine MS has crunched the numbers at some point, and decided that the amount of lost work and interruptions due to forcible updates (especially contrasted with the benefits of updates) is not caus…

Competitor? Windows is still >85% of desktop use or thereabouts - you can buy an expensive mac or you can go to hell and try out linux; neither is really an alternative for many so they just accept what happens.

So why do they bother adding new features to Windows?

I'll answer my question: Companies make decisions on the margin. They don't care that they have 85% of the market. They want that next percentage point.

The users who might switch to or from competitors are precisely the "swing voters" they have to consider.

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

#296

Post by einpoklum »

superkuh wrote: post #195

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 co…

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

Post reply on HN