[quevon24]

Summary

Follow-up to a security review of the app. No vulnerabilities were found in the app code; the actionable findings were in the release pipeline, plus one startup bug noticed along the way.

• Pin and checksum-verify appimagetool. The release workflow downloaded appimagetool from a mutable continuous tag and ran it to repack the AppImage we ship. It is now pinned to the 1.9.1 tag of AppImage/appimagetool and refuses to run unless its SHA-256 matches. (The old AppImage/AppImageKit repo is archived and its tagged assets 404, so the pin moved repos.)
• Optional AppImage signing. When an APPIMAGE_SIGNING_KEY repository secret is set, the AppImage is GPG-signed and the public key embedded, so AppImageUpdate and users can verify authenticity rather than trusting GitHub + TLS alone. Without the secret the build stays unsigned, as today.
• Public signing key committed as dockerlite-release-signing.pub.asc (fingerprint 5396 D542 D9A6 08DD 5D27 4BE2 0D85 CE52 C3B5 9577) and attached to every release so users can compare it with the key embedded in the AppImage.
• README: recommend .deb/.rpm over the AppImage (they use the system WebKitGTK, which gets security updates; the AppImage bundles a frozen copy), and document how to set up the signing key and bump the pinned tool.
• Apply the saved Docker socket path at startup. The backend always started on /var/run/docker.sock; the persisted setting was only applied after pressing Test in Settings. Setup now reads the store and switches before the webview's first call. Unit tests cover the parsing.

Verification

• Ran the full repack flow locally against the published v0.1.0 AppImage with the pinned tool, checksum check and a throwaway GPG key: output has a valid embedded signature, update info and a .zsync.
• Pinned checksum matches the digest GitHub reports for the 1.9.1 release asset.
• cargo fmt --check, cargo clippy -D warnings, and the new unit tests pass.