Application binaries must statically link libc and ssl when making programs for packging into appimage?

I haven't dug far enough into this specific project to know if it's static or dynamic linking, but that just doesn't matter.

Each app has it's own copy of libssl etc embedded into the prepackaged "binary" which is executed.. That's enough to know it's going to lead to all sorts of suffering when you actually try and rid yourself of $CVE of the month.

You can use either static or dynamic linking. An AppImage is really just an ISO container wrapping around your binaries.

So, yea.. As I said, in this context, it just doesn't matter if your statically or dynamically linked against glibc, every single AppImage published before Feb 15th or so requires an update.

What percent of AppImage's in the wild have shipped an update? Of those, how many have updated previous stable releases rather than just the latest version? I suspect very few.

[EDIT - Typos]

Regardless of dynamic or static linking there's the fact that "users dont upgrade" so you've lost either way.

Maybe not, but Since "Every AppImage contains an app and all the files the app needs to run." Even if you were dynamically linking, you'd be linking against a lib contained in the AppImage. So, each app would still have its own glibc that would have to be updated.

"The AppImage needs to include all libraries and other dependencies that are not part of all of the base systems that the AppImage is intended to run on" [ https://github.com/probonopd/AppImageKit/wiki/Creating-AppIm... ]