Linux AppImage bundles no GIO TLS backend — all HTTPS fails, surfacing as an attestation error

[jordan-bravo]

I ran the AppImage of v3.3.4 on NixOS (with appimage-run) and Maple started up but when I tried to log in it threw an error. Using a LLM to troubleshoot, I was able to get it running.

(The details below were written with an LLM)

Summary

The Linux AppImage ships GLib, libsoup3 and WebKitGTK but no glib-networking GIO module (libgiognutls.so). Without it GIO has no TLS backend, so every HTTPS request from the webview fails. The first one users hit is the attestation fetch, so it surfaces as:

Couldn't process attestation document: Load failed

Load failed is WebKit's generic fetch() network error, not an attestation problem.

Observed on 3.3.4. Not distro-specific (see root cause) — I verified on NixOS 26.11 / GNOME.

Reproduce

// tlsprobe.c — cc -o tlsprobe tlsprobe.c -ldl
#include <dlfcn.h>
#include <stdio.h>
int main(void){
  void *h = dlopen("libgio-2.0.so.0", RTLD_NOW|RTLD_GLOBAL);
  void* (*get_default)(void)   = dlsym(h,"g_tls_backend_get_default");
  int   (*supports_tls)(void*) = dlsym(h,"g_tls_backend_supports_tls");
  void *b = get_default();
  printf("supports_tls=%s\n", (b && supports_tls(b)) ? "YES" : "NO");
}

./Maple_3.3.4_amd64.AppImage --appimage-extract
AD=$PWD/squashfs-root
GIO_EXTRA_MODULES="$AD/" LD_LIBRARY_PATH="$AD/usr/lib" ./tlsprobe   # => NO

That is exactly the environment AppRun constructs. Adding GIO_MODULE_DIR=<any glib-networking>/lib/gio/modules flips it to YES, and login then succeeds.

Root cause

1. No GIO module is bundled: find squashfs-root -name 'libgiognutls.so' returns nothing.
2. The bundled GLib's compiled-in module directory is a build-host store path, /nix/store/f7rc…-glib-2.86.3/lib/gio/modules — absent on other distros, and empty even on NixOS since glib-networking is a separate derivation.
3. apprun-hooks/linuxdeploy-plugin-gtk.sh overwrites GIO_EXTRA_MODULES with the AppDir root, which contains no modules — discarding any host value that would have pointed at glib-networking.

Underlying gap: repair_linux_appdir_runtime_closure (scripts/ci/_common.sh:3364) closes over DT_NEEDED. GIO modules are dlopened, so they are invisible to it by construction. grep -rni 'gio.module\|glib-networking' scripts/ returns nothing on master.

Suggested fix

In prepare_linux_appdir_for_appimage (scripts/ci/_common.sh:3579):

• Copy ${glib-networking}/lib/gio/modules/libgiognutls.so into ${appdir}/usr/lib/gio/modules/, before repair_linux_appdir_runtime_closure, so its DT_NEEDED on gnutls/p11-kit/tasn1 is closed over automatically. All three are already bundled, so the marginal cost is one .so.
• Run gio-querymodules on that directory so giomodule.cache matches.
• export GIO_MODULE_DIR="${APPDIR}/usr/lib/gio/modules" from maple-webkitgtk.sh (scripts/ci/_common.sh:3143). That hook is sourced last in AppRun, after the GTK plugin clobbers GIO_EXTRA_MODULES, so it wins.

glib-networking is already in linuxTauriPackages (flake.nix:207), so the path is available to the build.

Two smaller asks:

• Verify TLS on the packaged artifact. A verify_linux_appdir_tls_backend alongside the existing verify_linux_appdir_* calls would have caught this at build time, and covers the whole dlopen-ed-plugin class rather than this one module.
• Distinguish network failures from attestation failures in that error path. The current message sends you straight to attestation/PCR code for what is a transport error.

Why this was not caught

flake.nix:547 sets GIO_MODULE_DIR=${pkgs.glib-networking}/lib/gio/modules for the dev shell, so just desktop-dev always has a working TLS backend. Only the packaged AppImage lacks one — which is the argument for checking the artifact rather than the dev environment.

Worth confirming whether the .deb/.rpm are affected; if they rely on system libraries they are probably fine, which would explain why this went unnoticed.

Workaround

GIO_MODULE_DIR=/path/to/glib-networking/lib/gio/modules ./Maple_3.3.4_amd64.AppImage

On NixOS, via appimage-run, with the directory resolved from the host's GIO_EXTRA_MODULES.

[yaeloss]

I had something similar!

Environment

• OS: Omarchy Linux, based on Arch Linux
• Architecture: x86_64
• Maple version: v3.3.5
• Asset: Maple_3.3.5_amd64.AppImage

Problem

I tried to install the official Maple AppImage on Omarchy Linux. The application launches and displays the login screen, but attempting to log in shows me:

"Couldn't process attestation document: Load failed"

System networking, DNS, and TLS are working. I can successfully connect to the production enclave with:
curl -v https://enclave.trymaple.ai

The server returns an expected HTTP 404 for its root route, but the TLS connection succeeds.

Diagnosis
The AppImage appears to bundle GLib/GIO, GnuTLS, and WebKitGTK, but its extracted filesystem does not contain the GIO TLS module libgiognutls.so. Its AppRun script also does not set GIO_MODULE_DIR.

Using the AppImage’s bundled libraries reproduces the failure:
LD_LIBRARY_PATH=squashfs-root/usr/lib
gio info https://enclave.trymaple.ai
Result:
gio: https://enclave.trymaple.ai: Operation not supported
Pointing GIO to the host system’s modules restores HTTPS:
GIO_MODULE_DIR=/usr/lib/gio/modules
LD_LIBRARY_PATH=squashfs-root/usr/lib
gio info https://enclave.trymaple.ai
This reaches the server and returns Not Found, which is expected for the root route.

Launching Maple with the same workaround fixes login:
GIO_MODULE_DIR=/usr/lib/gio/modules
WEBKIT_DISABLE_COMPOSITING_MODE=1
WEBKIT_DISABLE_DMABUF_RENDERER=1
./Maple_3.3.5_amd64.AppImage
After launching it this way, attestation succeeds and I can log in.

Possible cause
The Nix development shell appears to include glib-networking and configure GIO_MODULE_DIR, but the corresponding GIO TLS modules do not appear to be included or configured in the final AppImage runtime.

Suggested fix
Bundle the glib-networking GIO modules inside the AppImage, including libgiognutls.so, and configure AppRun to use the bundled directory, for example:
export GIO_MODULE_DIR="$APPDIR/usr/lib/gio/modules"
Using /usr/lib/gio/modules works as a local workaround, but the AppImage should not depend on host modules because their GLib ABI may differ between distributions.

I was able to get it working now, and I'm excited to use it! It wasn't enough for a pull request, but I hope this helps for future versions.

Cheers gents,

YO

[marksftw]

thanks for these reports, very helpful!