Removal from the Inkscape Website · Issue #87 · flathub/org.inkscape.Inkscape
github.com
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 ...

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!

  • @[email protected]
    1•6 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…

    • boredsquirrelOP
      1•6 months ago

      ~/Applications is no a random place, it comes from macos.

      Hahaha I would call that VERY random. It is problematic that the default xdg directories are hidden.

      And I just learned that you can just source scripts into bash and thus being executable or not doesnt matter. What an incredible design flaw… at least this just works with some binaries, I guess?

      You mean appimagetool

      No the Flatpak Appimage Pool. But a solution to easily package a bunch of files sounds really awesome. I miss that for RPMs, sddm2rpm did this kind of.

      appman

      Very interesting tool. So this is for appimages but also binaries?

      I am a bit confused, especially as they state to prefer official releases, which for me means tarballs.

      But a very good concept.

      Interesting set of apps you have there. And ironically I have to agree they are small. Flatpak libraries are too huge and the deduplication doesnt work if it us not used for downloads and if there are dozens of runtimes.

      A modular approach would be very much needed, instead of a damn KDE runtime that is nearly the entire desktop.

      But I have some questions.

      Yes that’s aisap sandbox

      Thats not a sandbox, its a nice wrapper for firejail, at least what they write. I only knew some Github issue where they discussed this, and because Appimages require fuse they couldnt be sandboxed with bubblewrap.

      Then they say “bubblewrap is used in Flatpak” but no comment if THEY also use it.

      Firejail is the setuid binary I talked about, they likely have fixed their security issues but bubblewrap/bubblejail are probably better as they dont need setuid binaries.

      If Appimages are possible to sandbox with bubblewrap, that would for sure be cool.

      I also found rustysnakes crabjail, dont know the state it is in, but that is a possible candidate for replacing bubblejail.

      right now its biggest limitation is that a sandboxed appimage can’t launch another sandboxed appimage.

      No idea if Flatpaks can do that. But I would say the biggest issue is that the big vendors just put their appimage on some file server without any data on the sandbox.

      Flatpak is way better here, where the sandbox is checked BEFORE apps are successfully submitted. And there are warnings etc.

      And, of course, every app is sandboxed, not just a few.

      those menus rely on desktop entries in $XDG_DATA_HOME/Applications.

      Not the “create new” to my knowledge. That is in $XDG_TEMPLATES_DIR but I am currently struggling to make Flatpaks use that.

      AppImage is just a format, same as a deb or rpm

      Yes, so is Flatpak. But Appimages were introduced to be Windows-like. Sure there are companies that dont care and publish random rpms on their website too.

      But with Appimages that is the only way as there is no real repo. AppMan is a cludge here, bundling together tons of different sources, kind of like Obtainium.

      https://github.com/AppImageCommunity/AppImageUpdate

      That tool is either completely finished or kind of abandoned.

      Interesting, didnt know they have a signature builtin. That would also be useful.

      That zsync2 thing explained in AppMan was just like delta updates. If a malicious actor has access to the old appimage and the fileserver, they can produce the correct zsync2 thing and the updates work, until signature verification is enforced.

      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.

      As I said, as long as bash script.sh works with nonexecutable stuff, noexec home is pretty worthless. Just another layer of defence.

      You mean the APK itself does the signature verification or what?

      No, android APKs are like Distro packages, they can be sideloaded however you want and then are forwarded to the “session installer” (on modern android), which is the “package manager” of android.

      That installer saves the signature somewhere, and from then on you can only update the APK if the signature was made with the same private key.

      Found out you can also not sign APKs, which happened here. I honestly dont know if more developers dont sign their APKs.

      I will update my repo text to get to the current state of facts.