Announcement

Collapse
No announcement yet.

Snaps & Ubuntu Core Desktop Talked Up At FOSDEM 2024

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by Artim View Post
    I doubt security in this context is the main benefit, but in another. Distributions - and especially Debian is known to do so - can enforce sensible best practices. E.g. they will force the app to have its configuration in /etc, not just some stupid location deep inside /var or /usr nobody usually checks
    Yes, I know about this, which is why I disagree with the statement that "a packager will never be smarter than the developer" that was mentioned earlier. A developer may know his own app better than the packager, but that doesn't necessarily mean he knows or cares about the best practices.

    Originally posted by Artim View Post
    But Flatpak does have one big advantage, security wise but also trust wise - snap does too, but to a lesser degree. Flatpaks are containerized, they can't access the system - e.g. not replace other programs, like MS (I think) was caught a few years back with their deb repo - and you can very easily manage permissions with Flatseal. E.g. WPS Office sometimes has best MS Office file support, yet I'd never let some shady chinese Office run wild on my system. With the Flatpak version, I just remove internet access and be done with it.
    Yes, of course I know about containerisation / sandboxing, but as you can see from the other comments, it's still subpar in both SNAP and Flatpak for various reasons. For example, some apps need to have lax permissions, because otherwise they won't work properly. I know that at least Flatpak strives to use portals as much as possible instead of raw filesystem access, but AFAIK, at this stage not all apps are able to utilise them. Maybe in the far future all Flatpak apps will finally be adapted to use portals. Also, instead of the current state of permission management, it needs a dynamic permission system, similar to what Android already has.

    Comment


    • #22
      Originally posted by user1 View Post
      Yes, of course I know about containerisation / sandboxing, but as you can see from the other comments, it's still subpar in both SNAP and Flatpak for various reasons. For example, some apps need to have lax permissions, because otherwise they won't work properly. I know that at least Flatpak strives to use portals as much as possible instead of raw filesystem access, but AFAIK, at this stage not all apps are able to utilise them. Maybe in the far future all Flatpak apps will finally be adapted to use portals. Also, instead of the current state of permission management, it needs a dynamic permission system, similar to what Android already has.
      Still you aren't running anything as root. With the traditional distribution methods, the package manager runs as root, and at least in .deb packages, probably in others too, you can have all sorts of scripts running at install time. With distro packages you can be quite sure that they are safe, but lots of stuff can only be installed from third parties. With them trust isn't always given, hence the example. So whatever script would be put into a flatpak, it can only run with the permissions of the Flatpak, never with root permissions (sure, you can run/install Flatpaks and probably AppImages and Snaps as root, but the point is that you usually don't, they are primarily designed to be installed only user wide, not system wide).

      Comment


      • #23
        Originally posted by ssokolow View Post

        [citation needed]
        Flatpaks are the same age as snaps (a decade old!) and have almost all of the same issues that snaps have. The only area Flatpaks are better are speed (and they’re still slower than standard packages, sometimes by a lot) and slightly better permission control.

        Red Hat has just managed to brainwash people into saying that Ubuntu is a bad company while RH are the magical saviors of Linux, so anything Ubuntu is bad and anything RH does is good.

        Tell me when Flatpaks are stable (don’t introduce bugs) and are also ACTUALLY sandboxed, since 95% of applications distributed as Flatpaks break out of the sandbox by default because of point 1: bugs.

        Comment


        • #24
          Originally posted by user1 View Post
          Particularly, I like the fact that packaging provides additional wall of security which you don't have if you get the software directly from the developer.
          Hmm. Do you think that packagers test their packages like release managers do? I know enough packages which are broken because they use a different library version.

          Comment


          • #25
            Originally posted by patrick1946 View Post

            Hmm. Do you think that packagers test their packages like release managers do? I know enough packages which are broken because they use a different library version.
            That may be true for distributions that don't give a damn about stability like Arch. Everybody else would have already dumped that package.

            Comment


            • #26
              Originally posted by Artim View Post

              That may be true for distributions that don't give a damn about stability like Arch. Everybody else would have already dumped that package.
              Exactly. And I'd say Debian cares about this more than any other distro.

              Comment


              • #27
                Originally posted by user1 View Post

                Exactly. And I'd say Debian cares about this more than any other distro.
                Well, I can't talk for things like RHEL, any of the CentOS successors like Alma Linux, or OpenSuse, but they are at least one of the distros with the biggest focus on doing things the proper way instead of the easy way.

                Comment


                • #28
                  Originally posted by Artim View Post

                  Well, I can't talk for things like RHEL, any of the CentOS successors like Alma Linux, or OpenSuse, but they are at least one of the distros with the biggest focus on doing things the proper way instead of the easy way.
                  Yeah, I was just thinking about regular user distros. Idk how things are in RHEL / CentOS / Alma Linux and other such distros. Regarding OpenSUSE, I'm not sure if they give such amount of attention to package stability like Debian (at least in regards to Tumbleweed, since it's a rolling release), but they certainly do a much better job than Arch. Unlike Arch, I've never heard about Tumbleweed needing manual intervention after updates (unless you have proprietary drivers) and if there is a broken package found, it should get fixed pretty quickly. OpenQA of course helps them a lot.

                  Comment


                  • #29
                    Originally posted by Daktyl198 View Post

                    I have bad news for you if you’re a fan of Flatpaks, buddy.
                    Flatpak people realise the limitations of Flatpaks and have spent time trying to come up with future proof solutions (e.g. portals). Which, yes has taken a long time and imho too long, but at least they recognise it.

                    Comment


                    • #30
                      Originally posted by Daktyl198 View Post

                      Flatpaks are the same age as snaps (a decade old!) and have almost all of the same issues that snaps have. The only area Flatpaks are better are speed (and they’re still slower than standard packages, sometimes by a lot) and slightly better permission control.

                      Red Hat has just managed to brainwash people into saying that Ubuntu is a bad company while RH are the magical saviors of Linux, so anything Ubuntu is bad and anything RH does is good.

                      Tell me when Flatpaks are stable (don’t introduce bugs) and are also ACTUALLY sandboxed, since 95% of applications distributed as Flatpaks break out of the sandbox by default because of point 1: bugs.
                      The only performance overhead of Flatpaks is the time to setup the namespaces (near instant, systemd is already doing it anyway) and that the Flatpak won't be able to use the fs cache of shared libraries that were used to boot your machine, but they can use the shared cache of other flatpaks with the same library version combination.

                      There's no extraction, no mounting of anything, no decompression (other than that of your filesystem).

                      Comment

                      Working...
                      X