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

Flatpak – a security nightmare

flatkill.org

Post reply on HN
Print view View original

81–90 of 264 posts

Re: Flatpak – a security nightmare

#81

Post by pdonis »

ambrice wrote: post #77
stephenr wrote: post #43

Earlier quoted context omitted.

> bring the horribly broken and insecure "download it and drag it to your desktop" model of application distribution, which has long been a source of viruses and malware on Windows and Macs, to Linux. Wat? Windows famously doesn’t have “just drag it to your desktop” to install. There’s an entire segment of the industry around building installers and managers for installation of windows programs. And I can’t recall a…

I think the reference is to the fact that on Windows you download some random .exe installer from some place on the internet and trust it, rather than selecting a signed package from a trusted repository that gets automatically updated. Should have been "download it, drag it to your desktop, and install it".

Yes, this is what I was referring to. Sorry for my unclear phrasing.

Re: Flatpak – a security nightmare

#82

Post by bananadonkey »

kilburn wrote: post #34
briffle wrote: post #11

Earlier quoted context omitted.

Yes, his other major gripe is that the security updates for non-official flatpaks take a while to get security releases out. I have the same problem when I run applications that have an official RPM repo, and a volunteer packages the deb and pushes it to the official Ubuntu/debian repos. The same thing with Alpine Linux packages. Its not a problem with the tech, its a lack of volunteers (or not yet enough adoption by…

> his other major gripe is that the security updates for non-official flatpaks I don't know whether it is true or not, but the author explicitly states that it is the official applications AND runtimes that aren't properly maintained. > I have the same problem when I run applications that have an official RPM repo, and a volunteer packages the deb and pushes it to the official Ubuntu/debian repos No you don't, becaus…

Parent was talking about Debian upstream patches making it into his platform of choice; in this case RHEL/CentOS.

That requires paid/volunteer package maintainers.

Re: Flatpak – a security nightmare

#83

Post by pdonis »

linuxftw wrote: post #72
pdonis wrote: post #35

Earlier quoted context omitted.

> This isn't any less "broken" than painstakingly adding third-party repositories when your package happens to not be maintained. True, it isn't any less broken than that; it's more broken. First, adding a third-party repository, and then using your distro's GUI package manager to install an app from that repository, is a lot more work for the average user than clicking on a download link and then dragging the downlo…

> is a lot more work for the average user than clicking on a download link and then dragging the downloaded file to your desktop (or clicking on it to open it and start an install process). You can totally download binaries from the internet and execute them if they don't require libraries (if the binary even needs any libraries, ie not statically compiled). You can also download a .sh installer and execute that to i…

I agree there's a ton of software out there that wants you to install it this way, not just on Linux but on any OS. My point is simply that I, as a user, am never going to use software that wants me to install it this way. The extra work involved in setting up secure distribution is a feature, not a bug.

Re: Flatpak – a security nightmare

#84

Post by tannhaeuser »

xfer wrote: post #74
tannhaeuser wrote: post #71

Earlier quoted context omitted.

A poor package repository is a consequence of too many packaging formats, and lack of volunteer maintainers, though (I, too, could have made more to help). So coming up with package formats all the time - .deb, .rpm, .apk, Alpine's pm format, pkg, .dmg, flatpack, snap, docker and whatnot - is exactly the problem (cf. https://xkcd.com/927/ ). Maybe Slackware got it right after all by only building from upstream .tgz s…

> We'll see in a decade or two what software is even remotely in a usable state still. Most distributions need non-free explicitly enabled, so almost all packages are open source, so it is irrelevant to distro packaging format.

Open source doesn't ensure it'll even build against new compilers, libs, language runtime, and all the other stuff we're reinventing all the time to keep the hamster wheel spinning. What open source desktop apps are you using that need sandboxing anyway all of the sudden? GIMP, Inkscape, Audacity? Come on.

Re: Flatpak – a security nightmare

#85

Post by dcbadacd »

Natela wrote: post #52

The sandbox is in a sense working, the problem is that the folder the app accesses is more critical than what the user thought. We should make sure nothing in home will get executed : no bashrc, no scripts, no executable. In the "ideal" world you would never download & run any script or any executable (like on Android or IOS). Everything the user should be able to do is install or run flatpak apps. (Of course in prac…

Maybe it's about time we break backwards compatibility and get rid of all dotfiles in ~ and move them to say .local/share/software_name and then start restricting access to those folders?

Re: Flatpak – a security nightmare

#86

Post by gbraad »

The developers are employed by Red Hat, but that does not make this a Red Hat endorsed product. It is not included in the current offering of RHEL and unlikely would be in a new(er) version as the technology is immature/not well enough tests d/proven yet for inclusion within EL. I call the usage of 'Red Hat' here clickbait and sensationalism as there is no indication within the text that shows the aforementioned non-existence of endorsement or inclusion.

Note: the engineers working on Flatpak and both friends and colleagues of mine. Just concerned that the author misrepresents our employers viewpoint. We are allowed to work on side projects, but that does not make them default inclusions or endorsed.

Re: Flatpak – a security nightmare

#87

Post by fouc »

nickysielicki wrote: post #48

1. None of this has anything to do with Flatpak, it has everything to do with Flathub and how particular software is packaged. 2. Your preferred distribution can host their own Flatpak repository and ensure that things like security updates get dealt with properly. Flatpak is not Flathub. 3. This ecosystem is growing, so it's putting some things on the backburner, prioritizing application availability over holding a…

Probably a good idea to get the permissions correct up front.

Re: Flatpak – a security nightmare

#88

Post by gbraad »

aritmo wrote: post #55
nickysielicki wrote: post #48

1. None of this has anything to do with Flatpak, it has everything to do with Flathub and how particular software is packaged. 2. Your preferred distribution can host their own Flatpak repository and ensure that things like security updates get dealt with properly. Flatpak is not Flathub. 3. This ecosystem is growing, so it's putting some things on the backburner, prioritizing application availability over holding a…

But Flathub is flatpak. Also, does flatpak have the full support of redhat?

Flatpak is still a side project worked on by my colleague. Although he is employed by Red Hat, it is not a project led by our employer. AFAIK there hasn't been any work done to get it in RHEL, ...

Re: Flatpak – a security nightmare

#90

Post by jopsen »

nickysielicki wrote: post #48

1. None of this has anything to do with Flatpak, it has everything to do with Flathub and how particular software is packaged. 2. Your preferred distribution can host their own Flatpak repository and ensure that things like security updates get dealt with properly. Flatpak is not Flathub. 3. This ecosystem is growing, so it's putting some things on the backburner, prioritizing application availability over holding a…

Spot on.. expecting the latest open source software to be perfect is not reasonable..

People who wants stable and secure to go with Debian stable... Some day when starts recommending flatpak, I'm sure flatpak will be solid :)

Post reply on HN