• thingsiplay@beehaw.org
      link
      fedilink
      arrow-up
      10
      arrow-down
      2
      ·
      9 months ago

      I still don’t understand why a central repository for AppImages exist. The moment you are using a repository (and possibly version management), the format looses its reason to exist.

      • GnomeComedy@beehaw.org
        link
        fedilink
        arrow-up
        8
        ·
        9 months ago

        I don’t see how that’s true. The main point of AppImage is it ‘just works’ on any distro. If you have one primary place to distribute them to any distro - it’s still meeting AppImage’s vision.

        • thingsiplay@beehaw.org
          link
          fedilink
          arrow-up
          8
          ·
          9 months ago

          To be fair, after some thinking I think you are right and I was a bit in a tunnel vision logic. My previous statement looks a bit foolish now.

        • thingsiplay@beehaw.org
          link
          fedilink
          arrow-up
          1
          ·
          9 months ago

          I personally use a few AppImages, but want replace them with Flatpaks. Flatpaks have their own issues, and because I did not want to troubleshoot in case I encounter another issue, just carry on using AppImages for these selected applications. Also I was not able to archive Flatpak easily, its very complicated with keys and not. Compared to it, I just have the AppImages included in my regular backup process with regular files.

          My point was not if AppImages are useful (they clearly are and I use them), but was talking bout repositories. However after some other replies I thought about it and indeed such a repository makes sense even for AppImages. I personally just don’t have to use them.

            • thingsiplay@beehaw.org
              link
              fedilink
              arrow-up
              1
              ·
              9 months ago

              Not really. AppImages are as much secure as any other executable you run on your system. If you download it from a trusted source, like you download trusted Flatpaks or your systems repository, then they are not worse. If you say AppImages are highly insecure, because you run executable code, then you have to take that logic to any other executable format. The problem is not the format itself that makes it insecure, it’s the source.

                • thingsiplay@beehaw.org
                  link
                  fedilink
                  arrow-up
                  2
                  ·
                  9 months ago

                  I read that page and there is nonsense included too. Just because I read that page does not make it correct. If you think that AppImages insecure, then you did not understand my point that its not the format thats insecure, but the source where you get the files. Every packaging system is insecure if you get it from bad source.

                  That’s not even a question. AppImages are fine and not insecure if you download it from a secure place you trust (like your system packages, you trust your distro maintainer fully). Would you trust every distribution maintainer on every distribution? Let’s say a Chinese Linux distribution, that maintains Flatpaks and native packages. Let’s say they are flaky. See? It’s the source you don’t trust, not the file format or packaging system.

                  Read my replies (just like you said I should read the linked post). And understand the issues.

                  • Pantherina@feddit.de
                    link
                    fedilink
                    arrow-up
                    2
                    arrow-down
                    1
                    ·
                    edit-2
                    9 months ago

                    Shit missing internet got my comment deleted…

                    Appimage is not a neutral packaging format. Of course “an app packaged as .zip is as secure as packages as .tar.gz”. But the format causes all the things mentioned in the post.

                    • libraries are often the oldest non-EOL possible to support old kernels
                    • no transparency about used libraries and possible vulnerabilities
                    • no upgrades of libraries, always just the wanted app and then passively also the libraries
                    • no sandboxing without firejail (which is a root binary and thus can lead to privilege escalation of rootless processes if it has a vulnerability which it had in the past)
                    • no GUI sandboxing
                    • even with a repo no cryptographic signature verification like on Android (not sure about Flatpak which uses OSTree)
                    • requires users to execute code in random locations

                    So it is way less secure than Flatpak, thats a fact. It may not be worse than tarballs, but if those dont include the libraries even less secure than them.