The Flatpak is already packaged and works well. It just needs to be maintained from a person that joins the Inkscape community.

This would allow further improvements like Portal support and making the app official on Flathub.

Update: One might have been found!

    • Daeraxa
      link
      fedilink
      40
      edit-2
      6 months ago

      From the conversation it seems to be a similar situation to the project I’m with is in. The flatpak is essentially community maintained rather than being directly supported by the team. To become verified it needs to be done so by a representative of the maintainers of the software. To be verified it doesn’t have to have a team member involved in it but this is a requirement Inkscape seem to have imposed.

      For us we just aren’t in a position to want to support it officially just yet, we have some major upgrades coming to our underlying tech stack that will introduce a whole bunch of stuff that will allow various XDG portals etc. to work properly with the Flatpak sandboxing model. To support it now would involve tons of workarounds which would need to be removed later.

    • @woelkchen
      link
      126 months ago

      Why is the flatpak not verified on flathub? Hmm

      Because it’s not by upstream Inkscape, apparently.

      • @[email protected]
        link
        fedilink
        English
        3
        edit-2
        6 months ago

        *'til

        But the lack of verification and validation is a huge risk to flatpaks. As someone formerly involved with securing OSes, this kind of thing was scary back then and doubly scary since it entered its “don’t confirm; just get in, loser” phase.

        • @[email protected]
          link
          fedilink
          06 months ago

          😱 so I guess install via appimage?? Package manager? 🤷 🤯 brain malfunction. Im thinking don’t download or install until you verify the download with a hash and hopefully signature if they exist 🤷 use fedora? Which has better security? 🤷🤯

      • @[email protected]
        link
        fedilink
        16 months ago

        For checksums: https://github.com/flathub/flathub/issues/1498#issuecomment-649098123

        Flatpak does verify the integrity of files as it is downloading/installing them. For ostree remotes this is done using GPG signatures (which are better than mere checksums). If you want to see the commit ID (which is like a checksum) for something on flathub use e.g. flatpak remote-info -c flathub org.gnome.Builder and for the local copy flatpak info -c org.gnome.Builder. For OCI remotes we at least check SHA256 sums and there might be more integrity verification mechanisms I’m unaware of.

        But for signatures: https://github.com/flatpak/flatpak-builder/issues/435

  • @[email protected]
    link
    fedilink
    English
    3
    edit-2
    6 months ago

    [email protected] flatpak also needs a flatpak maintainer! Your work would help people contribute their spare computational power to scientific research. If you are passionate about fighting cancer, mapping the galaxy, etc this is an awesome way to contribute to that effort in a very force multiplying way.

  • @headset
    link
    -96 months ago

    Oficial repositories, unoficial repositories, flatpak, snap… What happened to just donwload the app from it’s own creator and install on your machine? Why do we need every app being touched by some rando before I can install it on my box?

    • @[email protected]
      link
      fedilink
      176 months ago

      Your wanted option is not gone, you can still download the binaries if the author presents them; or you can compile it from source. This is just another, more convenient way to distribute the program.

      If you are looking to get your programs Windows-style, to download a binary or “install wizard”, then you can look into appimages.

      Like any form of distribution however: someone has to offer this, be it the author or “some rando”.

      • boredsquirrelOP
        link
        fedilink
        36 months ago

        Appimages have no install wizard. And Windows executables have some weird signature verification which Appimages dont have at all.

          • boredsquirrelOP
            link
            fedilink
            26 months ago

            If you mean downloading random stuff from random websites, yes.

            But they dont have installers, so no verification, no moving to locations where executing is allowed (on Linux the entire home is executable which is a huge security issue) no desktop integration, no context menu, no file associations.

            • @[email protected]
              link
              fedilink
              1
              edit-2
              6 months ago

              But they dont have installers, so no verification

              https://lemmy.ml/post/17283790/11897811

              on Linux the entire home is executable which is a huge security issue

              You still have to give the exec permission to the appimage.

              no desktop integration, no context menu, no file associations.

              Maybe no context menu depending on what you mean exactly, but the rest are fully possible and I do it on a regular basics with my appimages…

              edit: Omg you are the guy from don’t use appimages, I see you haven’t changed one bit.

              • boredsquirrelOP
                link
                fedilink
                16 months ago

                You still have to give the exec permission to the appimage.

                True, but this only prevents against stuff executing itself.

                Mandatory access controls and sandboxes only protect the core system. Like installing packages with root.

                You put things there privileged, so you know what you run comes from a protected area.

                Running things from random directories (like ~/Applications which AppimagePool uses) destroys that.

                Suddenly you rely on an executable home dir, which means any regular software (including appimages which are nearly impossible to sandbox) can write to the area where your programs are.

                That concept is so broken that it needs to go.

                I am against flatpak install --user for that reason, because no program should come from an unprivileged directory.

                The issue especially is if it doesnt follow standards. ~/.local/bin is a standard, and with SELinux confined users you may be able to protect that directory. But random ones like ~/Applications that dont follow any standards, will not work.

                Maybe no context menu depending on what you mean exactly

                The “open with” and “create new” things. Actually,

                Flatpaks cannot create “create new” entries too. I am currently experimenting with these, as it sucks to not be able to “create new Libreoffice writer document”. And the xdg-templates directory doesnt do anything lol, you still need desktop entries.

                but the rest are fully possible and I do it on a regular basics

                The concept of an installer is that the app does that on its own. That is pretty bad and the kind of Windows crap we absolutely dont want.

                But on good operating systems, a privileged package manager does all that. Puts the stuff where it belongs. Flatpak for example links the desktop entry that the app itself contains in a sandboxed directory, to the export directory where the OS sees it.

                And some portal or whatever deals with the “standard apps” stuff, like that Okular Flatpak will be shown to support opening PDFs.

                If apps do this on their own that means a single app can mess up your entire system, also malicious.

                Appimage may have tools, I only tried AppimagePool for curiosity and the experience was pretty bad and incomplete.

                But the issue is that they were just thrown out there, “here devs, do the same shit you do on Windows, it is totally normal for people to double click an executable, not have any sandboxing, deal with updates on their own, dont have any cryptographic verification, …”.

                And only afterwards came the managers, the daemons, which cover a part of it.

                They (could) solve:

                • being privileged, placing apps in not user-writable directories
                • having access to integration locations, that apps should never touch
                • downloading from defined, maintained locations (instead of letting people click on random internet malware ads)
                • running in the background, notifying about updates
                • centrally managing these updates
                • verifying signatures before allowing updates
                • doing the actual update process (instead of deleting a file and placing a new one)

                And they often dont even do that. There are no signatures, as devs were never told “either you add a signature, or people will not install your app”. So there is zero verification

                But they dont solve the core issues that are:

                • devs were told they dont need to care about…
                • creating metadata
                • creating a real repository
                • signing their apps
                • using a standardized build system
                • transparently declaring used dependencies (i.e. using a given set of them), thus deduplicating them
                • going through a review process
                • being affected when dependencies are end of life
                • declaring opt-in permissions, so users know if the app is insecure (appimages are impossible to sandbox with bubblewrap, and hard with firejail (which is a setuid binary and had security issues), dont know about nsjail, crabjail, minijail or others)

                Flatpak is similar to Android. On Android you still have a package manager but the APKs are signed individually, updates just allowed if the signatures match. So you can sideload how you want, it is still secure.

                And using Obtainium, which is kind of like an AppimagePool, you can get all the apps from independend developers.

                But they were told they need to follow all these rules, Appimage developers can do whatever they want.

                Sorry that was long.

                I see you haven’t changed one bit.

                Regarding what? XD

                • @[email protected]
                  link
                  fedilink
                  16 months ago

                  Running things from random directories (like ~/Applications which AppimagePool uses) destroys that.

                  ~/Applications is no a random place, it comes from macos. And what is appimagepool?

                  You mean appimagetool? that’s used to turn the AppDir into an appimage.

                  If you meant appimagelauncher, ~/Applications is the default location but it can be changed to any location.

                  (including appimages which are nearly impossible to sandbox)

                  See that lock next to some appimages? Yes that’s aisap sandbox..

                  It isn’t perfect though, right now its biggest limitation is that a sandboxed appimage can’t launch another sandboxed appimage. But dbus, pipewire, vulkan, themes, etc works.

                  The “open with” and “create new” things. Actually,

                  You can totally do that with appimages once they are integrated into the system by the previously mentioned tools, those menus rely on desktop entries in $XDG_DATA_HOME/Applications.

                  That concept is so broken that it needs to go.

                  Good thing we have choices on linux, you can make your entire home not executable if you want to.

                  I like to keep all the software that I need in my home, because that way I don’t depend on what my distro provides. I can just drop my home anywhere (besides a musl distro) and I’m ready to go, I even have my window manager as an appimage because I couldn’t compile it statically.

                  But the issue is that they were just thrown out there, “here devs, do the same shit you do on Windows, it is totally normal for people to double click an executable, not have any sandboxing, deal with updates on their own, dont have any cryptographic verification, …”.

                  AppImage is just a format, same as a deb or rpm, you decide how you handle it afterwards.

                  doing the actual update process (instead of deleting a file and placing a new one)

                  Same link again: https://github.com/AppImageCommunity/AppImageUpdate

                  Many of the appimage devs actually worked on making zsync2 for this: https://github.com/AppImageCommunity/zsync2

                  On Android you still have a package manager but the APKs are signed individually, updates just allowed if the signatures match. So you can sideload how you want, it is still secure.

                  You mean the APK itself does the signature verification or what? With appimage it is AppImageUpdateTool that does the verification.

                  (appimages are impossible to sandbox with bubblewrap, and hard with firejail (which is a setuid binary and had security issues), dont know about nsjail, crabjail, minijail or others)

                  Again this nonsense.

                  Regarding what?

                  You still have that github repo saying that appimages bloat the system when that is a total lie. they can even use less storage than native packages let alone comparing it to flatpak…

                • @[email protected]
                  link
                  fedilink
                  16 months ago

                  A matter of perspective I think. It’s a flaw in my opinion. Just downloading anything from anywhere sets one up for failure/malware.

                  Code Signing on its own is useless, I think. If there is no distribution structure or user-validated trustchain, of course. But then you don’t really need Code Signing, a simple hash is enough.

                  My personal preference are the distro repos, to a point where I even dislike additional package managers like pip, npm or cargo.

        • @[email protected]
          link
          fedilink
          3
          edit-2
          6 months ago

          And Windows executables have some weird signature verification which Appimages dont have at all.

          EDIT:

          Appimages have no install wizard.

          Appimagelauncher, gearlever, AM, etc. Which is the same as a install wizard since it integrates the appimage into the system. AppImages do not need to be extracted into the system which is what windows install wizards do.

          • boredsquirrelOP
            link
            fedilink
            1
            edit-2
            6 months ago

            Appimages came before these tools, and the tools (forgot the name GearLever, AppimagePool is another one) came afterwards.

            They are structurally better as they are external.

            That verification is interesting. So it is another appimage, used to verify appimages? Are all Appimages using that, if not what percentage of the ones you know? And are tools like Gearlever enforcing or using that signature check?

            • @[email protected]
              link
              fedilink
              26 months ago

              Are all Appimages using that, if not what percentage of the ones you know?

              Usually if the appimage has a github release with a zsync you have that verification.

              And are tools like Gearlever enforcing or using that signature check?

              I don’t use gearlever, as far as I know gearlever doesn’t even let you sandbox the appimage like AM does. I don’t think any of those forces signature verification besides AppImageUpdateTool and that’s because that’s part of the zsync update process.

              • boredsquirrelOP
                link
                fedilink
                16 months ago

                Interesting, will look into this. The issue is of course that these tools are optional.

                But if they work, they may fix nearly many issues. Some will remain, for example many proprietary apps dont use Github releases, while these may be especially targets of fakes.

    • @[email protected]
      link
      fedilink
      116 months ago

      What happened to just donwload the app from it’s own creator and install on your machine?

      That’s the Windows shit I specifically wanted to get away from

    • @[email protected]
      link
      fedilink
      76 months ago

      What happened to just donwload the app from it’s own creator and install on your machine?

      You have that option with the appimage, inkscape releases it themselves.

    • boredsquirrelOP
      link
      fedilink
      46 months ago

      Thats how packaging works.

      On Android I use Obtainium, as the package manager deals with signature verification. On Linux, Flatpak is the only equivalent to Android apps.

      RustDesk is the only Flatpak not from Flathub I use, because they have messed up permissions.

      • SayCyberOnceMore
        link
        fedilink
        English
        56 months ago

        Well… of course only time will tell, but the fact that we’ve been doing that for sooo long… (me for ~20 years?) would imply that it might just be around for longer than snap/flatpak/etc

        Of course, sometimes it’s disguised as yay -S

      • Chewy
        link
        fedilink
        226 months ago

        I’d say flatpak isn’t the future because it’s already here and seems to be universally accepted as the cross-distro package manager.

        I do like how the Nix package manager handles dependencies, but it’s not suitable for app developers packaging their own apps because of its complexity.

        If a better flatpak comes around I’d use it too, but at least for graphical apps I don’t know what it’d have to do to be better. In my opinion, flatpak is a prime example of good enough, but not perfect and I’d be surprised if there was a different tool with the same momentum in 15 years (except snap, but they seem too Ubuntu specific).

          • @woelkchen
            link
            56 months ago

            For what it is worth you can install Snap on most distros. https://snapcraft.io/docs/installing-snapd

            Snap is a cesspool for malware and shovel ware. The best apps are packaged by Canonical. Also, when people still cared about Snap, there were frequent reports of incompatibilities because it was developed with Ubuntu in mind.

          • BennyHill500
            link
            fedilink
            16 months ago

            but you shouldnt because snap’s "strict confinement’ sandbox feature does not work without the legacy patches to Apparmor that ubuntu uses.

        • QuantumSoul
          link
          fedilink
          26 months ago

          Snap is shit. I started using flatpak because apt didn’t support apps that I wanted and snap only supported ancient releases. .deb is annoying too and .appimage I don’t like to have the files hanging there

          • boredsquirrelOP
            link
            fedilink
            46 months ago

            Ubuntu may have convinced some proprietary developers, but Snaps are shit and devs know that I think

          • Possibly linux
            link
            fedilink
            English
            26 months ago

            I left Ubuntu when apt wouldn’t let me install a native package. It just would redirect to a broken snap.

          • @okamiueru
            link
            26 months ago

            Use arch with AUR, and cross your fingers that at least someone checks the changes. I sure don’t.

            • Possibly linux
              link
              fedilink
              English
              16 months ago

              No they aren’t

              It completely invalidates the Android security model if something can arbitrarily bypass restrictions.

              • @[email protected]
                link
                fedilink
                2
                edit-2
                6 months ago

                Thankfully we don’t have to follow the dumb Android security model on desktops.

                on Qubes we still have security through compartmentalization, yet all systems have root access (even passwordless sudo)

    • @[email protected]
      link
      fedilink
      Français
      66 months ago

      it sure seems like it though

      i mean, they’ll never replace system package manager, but for desktop applications, flatpak is honestly quite good

      • @bigmclargehuge
        link
        46 months ago

        (Not incredibly educated on Flatpaks, please educate me if I’m wrong) My main issue with Flatpak is the bundled dependancies. I really prefer packages to come bundled with the absolute bare minimum, as part of the main appeal of Linux for me is the shared system wide dependancies. Flatpak sort of seems to throw that ideology out the window.

        Let me ask this (genuinely asking, I’m not a software developer and I’m curious why this isn’t a common practice), why aren’t “portable” builds of software more common? Ie, just a folder with the executable that you can run from anywhere? Would these in theory also need to come bundled with any needed dependancies? Or could they simply be told to seek out the ones already installed on the system? Or would this just depend on the software?

        I ask this because in my mind, a portable build of a piece of software seems like the perfect middle ground between a native, distro specific build and a specialized universal packaging method like Flatpak.

        • @[email protected]
          link
          fedilink
          English
          36 months ago

          well, the point of flatpak is to have bundled dependencies so they run predictably no matter the distro

          if one of your software’s dependency gets updated, and your software isn’t, you may run into issues - like a function from the library you’re using getting removed, or its behaviour changing slightly. and some distros may also apply patches to some of their library that breaks stuff too!
          often, with complex libraries, even when you check the version number, you may have behavioural differences between distros depending on the compile flags used (i.e. some features being disabled, etc.)
          so, while in theory portable builds work, for them to be practical, they most often are statically linked (all the dependencies get built into the executable - no relying on system libraries). and that comes with a huge size penalty, even when compared to flatpaks, as those do have some shared dependencies between flatpaks! you can for example request to depend on a specific version of the freedesktop SDK, which will provide you with a bunch of standard linux tools, and that’ll only get installed once for every package you have that uses it