Bump version to allow AppImageLauncher to continue working

[TheAssassin]

The current AppImageLauncher process of bypassing binfmt_misc involves extracting the runtime from the AppImage in question into a memory buffer, patching out the magic bytes and launching it from there with an LD_PRELOADed library. As you can imagine, we need to tell this patched runtime where the real binary is to be able to mount the FUSE filesystem correctly.

This library is a bit of a hack. It hooks some functions we know the runtime uses (read: the old type 1 and the type 2 one that AppImageKit features) and that way it can reliably fix all kinds of function calls that point to the AppImage.

This has worked exceptionally well over the last few years. However, with a static runtime, i.e., a static binary, there is no LD_PRELOAD feature that could be used.

For upcoming runtimes, we could specify some kind of other method that can be used to reliably tell the runtime where the real binary is. In fact, the current type-2 runtime already features a TARGET_APPIMAGE environment variable (which AppImageLauncher used prior to version 1!), which could be improved a bit. However, AppImageLauncher needs to know that this feature exists for sure.

My suggestion: let's make TARGET_APPIMAGE or a similar approach that works in the scenario I described part of the runtime's specification. Any spec-complying runtime needs to expose such a feature. Also, let's bump the runtime version so that it is easy to discover that the feature is there for third-party tools. Last but not least, we won't break any compatibility by retrospectively changing the specification.

Side note: of course, I'd rather avoid this annoying workaround. However, it's the best and most reliable way I came up with so far to bypass binfmt_misc. They do not have a feature built-in that could be used and as far as I can see have no interest in improving this. Also, it would take years for such a feature to reach end users anyway, since this is a kernel level problem.

[probonopd]

So, you are saying we should remove

type2-runtime/src/runtime/runtime.c

Lines 1339 to 1341 in 7804775

	* This variable is intended for use by e.g., appimaged and is subject to
	* change any time. Do not rely on it being present. We might even limit this
	* functionality specifically for builds used by appimaged.

and make it mandatory in the AppImageSpec 1.0?

[TheAssassin]

This is the easiest option. Additionally, we need to allow tools like AppImageLauncher to discover this change. The easiest way is to make the new static runtime a type 3. We could even include the requirement for the lib to be static and work with both FUSE 2 and 3.

You suggested making the static runtime a type 3 yourself a couple of years ago and make us draft a type 4 instead in the future.

[probonopd]

Why is there a need to "discover this change" and not just assume that all type 2 runtimes support TARGET_APPIMAGE? Shouldn't that be approximately true?

[TheAssassin]

There is at least one currently spec-compliant third party runtime that does not feature this environment variable. I can try to find it again if you like. There is no way to tell different runtimes apart. The safest approach is to increase the version by one.

[TheAssassin]

In a discussion on IRC, we came up with an alternative idea: adding some other type of "marker" to the runtime that has no relation to the current magic bytes' location. For type 3, @azubieta had an idea to let the linker embed some magic bytes in another location (I think an offset of 1024 was proposed back then). In order to prepare a proper type 3, we could prepare such a feature now: let's properly version the AppImage spec for the first time, standardize that new marker, deprecate the old one for the future (which is just documentation, but a great hint for the community! Type 3 won't be released that soon) and add this new function to the build process. It'd be a great test drive for this idea anyway.

Edit: my own proposal is to release an AppImage spec 2.0.0 with the current feature set, then release a 2.1.0 with the new version marker and possibly also TARGET_APPIMAGE (unless that is supposed to be a 2.2.0).