Well, upstream is now considering either merging or just pointing to the AM repository because it is bigger and better maintained.

https://github.com/AppImage/appimage.github.io/issues/3595

yet they still miss a central package repository, and that’s a big problem.

https://github.com/ivan-hc/AM

I don’t know where this myth about Flatpaks always being gigabytes in size originates from or why it’s so persistent, but it’s wrong.

Alright, here is ~25 GUI apps flatpak vs appimage:

• 6 GiB flatpak.
• 2.7 GIB appimage.

This is if you have a filesystem with transparent compression, If you do not have such filesystem (ext4), then it is more like 15 GIB vs 2.9 GiB lol.

This comparison is missing the flatpak equivalents of kdeconnect, deadbeef and a few CLI tools that I have on right btw, flatpak-dedup-checker for some reason doesn’t check the /var/lib/flatpak/repo directory which is usually another +1GiB in best case scenario.

https://github.com/pkgforge-dev/Cromite-AppImage

i was talking about the risk of a Flatpak which has access to user home and therefore could for example access $HOME/.firefox and steal session cookies.

Okay that makes sense.

Also I based my assessment of use FUSE2 for normal AppImages on the security hardening used by Secureblue, mentioned here under the section “Filling known security holes”

Remove the unmaintained and suid-root fuse2 by default.

kek they got it wrong. Also:

Mitigate LD_PRELOAD attacks via ujust toggle-bash-environment-lockdown.

Interesting, I wonder if they prevent executing the ld-linux.so as well.

There is two ways to preload libraries without having to modify the binary, the first is using LD_PRELOAD, the second is less well known but you can run binaries by calling the dynamic linker first (internally this is actually how all dynamic binaries you execute work btw) and then use the --preload flag to load a library.

That is instead of:

LD_PRELOAD=./kek.so /path/to/bin

you do:

/lib64/ld-linux-x86-64.so.2 --preload ./kek.so /path/to/bin

I’m going to take a wild guess and assume the second is still possible in secureblue 👀

AppImage is just a format, nothing is stopping distros from adding a binfmt_misc rule that makes all appimages be sandboxed with any tool. (this also means you can set this up so that they get executed inside a flatpak env btw)

They also rely on the deprecated SUID-root binary FUSE2.

There is no such thing as a suid fuse2, you are talking about suid fusermount, and libfuse2 which hasn’t been true for 3 years the runtime is now static and doesn’t depend on any libfuse (or any library) to work.

And even back then it wasn’t a hard dependency either, you could still run appimages by setting APPIMAGE_EXTRACT_AND_RUN=1 which makes them run without FUSE.

The runtime still depends on a suid fusermount in PATH (it checks all the way to fusermount99 lol), however there is a much better runtime that does not FUSE to work at all since it can use mount namespaces instead.

Meanwhile flatpak has a hard dependency on fusermount, it actually broke recently on ubuntu because they wanted to restrict access to fusermount.

but if given access to the “home” permission they can read and write to anywhere else in the user home, so stealing session cookies from a browser or ransomware could still be possible given the right permission.

web browsers (and electron apps) already have their own internal sandbox, which actually gets weakened by flatpak so it is actually not a good idea to be running those things with flatpak 1 2 3

firefox recently finally got a fork server in linux, which means it is possible to at least get the zypack hack working with it, no idea if it has been implemented yet though.

You also can sandbox appimages with bubblewrap, which is the very same sandbox flatpak uses, I wrote this tool used by AM for that.

Apps will also have access to the portals, although I don’t like this and looks like there is no easy way to disable access to portals other than disable all access to dbus which is bad.

We already had an incident where someone thought there was a sandbox escape when it was just the app opening the portal xd

https://github.com/ivan-hc/AM

Wouldn’t mind basically adding to a command or cron for something like apt-get get upgrade && flatpak update && something

iirc topgrade has support for AM, so you can do all at once with AM included.

.mozilla : “Oh but I AM special”

You would think that thunderbird would use ~/.mozilla as well but nope. It is ~/.thunderbird 🤣

Check my dotfiles https://github.com/Samueru-sama/dotfiles

0 hidden files, everything is in ~/Local.

Recently added this hack for ssh: https://github.com/Samueru-sama/dotfiles/commit/7e1f8bd3173da563731aea6db9efbf26a2b23e72

Alright be aware that AM not only can manage appimages, it also manages other portable formats and has access to over a 1000 static binaries from soarpkgs repo.

And it can do all of this at user level when used as appman, that is elevated rights are never needed to install anything and I can just take my HOME and drop it on any distro and be ready to go.

It made me get rid of flatpak all together and become an appimage contributor lol

what

Is topgrade used to update all the package managers at once? how many stuff are you using that you need that???

but I would have expected Fedora to come with something like this preinstalled tbh

Fedora is just plagued with poor decisions, and that’s expected, it is the testing ground of redhat and not something that regular users should be using, they even go as far as repacking existing flatpaks just because and then break them.

A while back they pulled this nonsense that not even upstream approves of: https://gitlab.com/gnuwget/wget2/-/issues/661

iirc fedora also enabled wayland by default on gnome in 2016 when pretty much nothing worked.

Rhino linux lets you install AM thru its GUI installer btw.

I’m not, it’s a vm that I use to test.

There is quite a lot of systems still stuck on kernel 2.6 that can’t be updated, so it is always nice to make sure what I do can work on such.

So, I would say the primary complaint should be a lack of package management.

https://github.com/ivan-hc/AM

So, I would say the primary complaint should be a lack of package management.

https://github.com/ivan-hc/AM

it allows the same packages to run on any Linux kernel (any Linux distro). That is pretty useful.

flatpak itself depends on namespaces, so saying that it works on any kernel is quite a stretch.

Can flatpak do this? This is a GIMP3 appimage running on ubuntu 10.04 without any container:

The kernel is so old that even the appimage runtime itself complains of missing functions and has to fallback to a workaround.

UPDATE: flatpak can’t work because bubblewrap itself can’t:

PR_SET_NO_NEW_PRIVS is only available since kernel 3.5

The issue is arch and not us. They are building fastfetch without SQLITE3 and then we get people asking why the package count of fastfetch doesn’t display soar pkgs… All we can do is just tell people to not use fastfetch from the arch repos.

All archlinux has to do is change this line from OFF to ON

Be aware the sandbox of flatpak is not safe for web browsers, specially firefox based browsers:

https://seirdy.one/notes/2022/06/12/flatpak-and-web-browsers/

https://librewolf.net/installation/linux/#security

https://github.com/uazo/cromite/issues/1053#issuecomment-2191794660

omg I cannot fucking believe that while I was typing this I just saw another distro package nonsense:

There is this very good tool called soar which I use for static binaries. (It also has support for appimages but to be honest it is not as good as AM rn).

Well we just got a complain that fastfetch is not displaying the package count of soar, which fastfetch is able to do.

Turns out this is because the archlinux package is built without SQLITE3 which is needed for that feature to work 😫

And what’s worse is that account registrations are disabled in the archlinux gitlab, so I have to jump thru some hoops to get a basic bug report filed…