Skip Navigation

Inkscape Flatpak is looking for a maintainer!

github.com Removal from the Inkscape Website · Issue #87 · flathub/org.inkscape.Inkscape

The inkscape project is considering removing the flatpak format from the website's resources/downloads pages because of lack of maintenance. There is no maintainer of the flatpak/flathub format at ...

Removal from the Inkscape Website · Issue #87 · flathub/org.inkscape.Inkscape

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.

76

You're viewing part of a thread.

Show Context
76 comments
  • 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.

    • 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

      • 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...

You've viewed 76 comments.