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

Flatpak Is Not the Future

ludocode.com

Post reply on HN
Print view View original

331–340 of 410 posts

Re: Flatpak Is Not the Future

#331

Post by teddyfrozevelt »

IiydAbITMvJkqKf wrote: post #109
smallerfish wrote: post #53

I agree that the implementation is lacking. Snap has the abysmally named "--classic" parameter to allow installs to "run without confinement". Flatpak can request permission changes at install time (albeit declaring them), where users are likely to just click OK/OK/OK. The sandboxing needs to be tightened up. Flathub is a strange beast. There's no mention of security on their wiki. They stopped publishing minutes (or…

the flatpak sandbox UX is bleak. right now, you have to check the JSON file you linked to check how much access a flatpak program gets. i disagree with the --own-name and --talk-name flags (i think this is for screensharing; zoom should use the screensharing portal instead. letting zoom talk to gnome shell directly could be bad.). --socket=x11 is a massive hole in the sandbox, since x11 does not have a security model…

It's not really that bad. You are told the permissions requested by an app on installation:

  $ flatpak install flathub com.microsoft.Teams

  com.microsoft.Teams permissions:
      ipc     network     pcsc     pulseaudio     x11     devices     file access [1]     dbus access [2]     tags [3]
  
      [1] xdg-download
      [2] org.freedesktop.Notifications, org.freedesktop.secrets, org.gnome.SessionManager, org.kde.StatusNotifierWatcher
      [3] proprietary


          ID                           Branch          Op         Remote          Download
   1.     com.microsoft.Teams          stable          i          flathub
and you can query an apps permissions at any time:

  $ flatpak info --show-permissions com.discordapp.Discord

  [Context]
  shared=network;ipc;
  sockets=x11;pulseaudio;
  devices=all;
  filesystems=xdg-download;xdg-pictures:ro;xdg-videos:ro;home;

  [Session Bus Policy]
  org.kde.StatusNotifierWatcher=talk
  org.freedesktop.Notifications=talk
  com.canonical.AppMenu.Registrar=talk
  com.canonical.indicator.application=talk
  com.canonical.Unity.LauncherEntry=talk
GNOME Software in GNOME 41 also has a much better list of permissions than the version shown in this article.

https://blogs.gnome.org/tbernard/2021/09/09/software-41-cont...

Re: Flatpak Is Not the Future

#332

Post by danShumway »

goodpoint wrote: post #330
joconde wrote: post #319

Earlier quoted context omitted.

> Debian can still compile Firefox from source and patch out trackers and update dependencies, even if at the end of the day it bundles the changes back into another Flatpak app. Does that mean I'll download one copy of libThatWasUpdated for every app that uses it? Seems like this is exactly like iOS and Android work. I see the appeal (they are definitely more secure against malicious apps than Linux with apt-get), b…

> they are definitely more secure against malicious apps than Linux with apt-get Not at all.

Unless you're running something like Firejail on your system, yes they are.

There are a metric ton of holes to plug in the Linux security model, Linux security is a dumpster fire. But... run Wayland, use Flatpak (and check your permissions), check file access/network access -- these are steps in the right direction, they are security improvements over apt-get. We know that isolation/sandboxing (and in particular filesystem isolation) is going to be an important part of security moving forward.

And if you're comparing this to Android/iOS, it's not even a contest, Android/iOS's model of app isolation is unambiguously more secure than an apt-get free-for-all; and repositories like FDroid allow you to set upstream maintainers the same way that you would in desktop Linux environments.

If you compare this to the web, it becomes even more obvious that resource/runtime isolation between sites improves security. Increasingly we're looking at not even sharing browser caches between domains, which is even more strict than Flatpak's shared runtimes. Isolation is a failsafe -- it means if something breaks or gets infected, it can't affect everything. It means that remote code injection into a properly sandboxed app can only compromise one app, and not overwrite your bashrc and insert random keyloggers into everything you do.

Improvements still to be made, I would not today assume that Flatpak is secure or battle-tested, and it definitely can't do much about X11. But we fix these things piece by piece, and the basic idea itself is still sound.

Re: Flatpak Is Not the Future

#333

Post by CRConrad »

jcelerier wrote: post #297
goodpoint wrote: post #255

Earlier quoted context omitted.

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

> On the contrary it provably works very well for distributions. if it worked very well there wouldn't be a need for flatpak / snap / appimage / etc. How do I install an older or newer inkscape / ardour / krita in the latest debian stable / ubuntu / fedora / whatever without recompiling stuff ?

> if it worked very well there wouldn't be a need for flatpak / snap / appimage / etc.

Exactly: There isn't.

> How do I install an older or newer inkscape / ardour / krita in the latest debian stable / ubuntu / fedora / whatever without recompiling stuff ?

You don't. Or if you have to, do it on Gobo (or perhaps Guix or NixOS?).

Re: Flatpak Is Not the Future

#335

Post by pfranz »

cycomanic wrote: post #209
pfranz wrote: post #88

Earlier quoted context omitted.

You should point the finger at package managers. They never really addressed needs outside of system administration (to be fair, that's the problem they were trying to solve). Scripting languages came up with their own package system because package managers didn't fit their needs, I often found myself building from source and installing into my homedir because package managers wouldn't accommodate, industries (like…

>You should point the finger at package managers. They never really addressed needs outside of system administration (to be fair, that's the problem they were trying to solve). Scripting languages came up with their own package system because package managers didn't fit their needs I argue that's simply not true. Scripting languages came up with package managers because the largest platform (Windows) does not have a…

Right. Windows support is a feature outside of the scope of Linux package managers. If they weren't tethered to specific distros I don't see why one couldn't support multiple platforms. It hasn't historically, but Windows has a bunch of package managers, even one supported by Microsoft.

I think "largest" is quite an exaggeration since historically scripting languages packaging has been rather terrible on Windows. While Windows was a consideration for languages like Python (I've read they avoided Make because of Windows), for me cygwin always coming up along with it until recently.

Re: Flatpak Is Not the Future

#336

Post by pfranz »

southerntofu wrote: post #156
pfranz wrote: post #88

Earlier quoted context omitted.

You should point the finger at package managers. They never really addressed needs outside of system administration (to be fair, that's the problem they were trying to solve). Scripting languages came up with their own package system because package managers didn't fit their needs, I often found myself building from source and installing into my homedir because package managers wouldn't accommodate, industries (like…

> Nix/Guix seems like the only one that's trying something different enough to address some of those other use-cases, but the cat's out of the bag for most people. Maybe that's because nix and guix don't interop despite having rather similar principles, and because we mostly don't have GUI for it (like GNOME Software has integration for flatpak) nor desktop integration (like AppImageLauncher). Are you aware of work b…

I wasn't trying to undermine their hard work! I think both have a chance of being successful in their own domains. I only meant to call them out as exceptions.

All I was saying is that if a new package manager addresses all of the issues scripting languages had, scripting languages would still use their own package managers. Because the culture is now set, even new scripting languages would write their own package managers.

Re: Flatpak Is Not the Future

#337

Post by hermitcrab »

jcelerier wrote: post #334
hermitcrab wrote: post #321

Earlier quoted context omitted.

Ossia looks impressive. Does it use Qt or some other GUI library?

Yes, it uses Qt for the GUI. Thanks ^_^

I am very out-of-the-loop on Linux. Your download page says:

"Your system must have at least glibc-2.17, as well as X11, ALSA, libGL, librt, libdbus."

What rough percentage of modern Linux computers would you say that covers? 99%, 90%, 50%?

Re: Flatpak Is Not the Future

#338

Post by JohnFen »

After giving flatpacks and the like a good, solid try, I have come to truly detest them. This article hits on most of the reasons why. If I can only get software in flatpack form, that software does not exist for me.

Re: Flatpak Is Not the Future

#339

Post by jcelerier »

hermitcrab wrote: post #337
jcelerier wrote: post #334

Earlier quoted context omitted.

Yes, it uses Qt for the GUI. Thanks ^_^

I am very out-of-the-loop on Linux. Your download page says: "Your system must have at least glibc-2.17, as well as X11, ALSA, libGL, librt, libdbus." What rough percentage of modern Linux computers would you say that covers? 99%, 90%, 50%?

Should be very close from 90%. Anything >= Ubuntu 14.04 (just tested it quickly through docker) or CentOS 7 (on which the builds are done) should work

Re: Flatpak Is Not the Future

#340

Post by Mikeb85 »

goodpoint wrote: post #255
rattlesnakedave wrote: post #230

Earlier quoted context omitted.

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

> Opposed to distributions providing targeted updates to each package.

Except distributions can manage their own flatpak repo. Using flatpaks as a format != using Flathub.

This is what Fedora does, for example.

Post reply on HN