Request for classic confinement: aegis-host

store-requests classic-confinement
1

Hello,

I am requesting classic confinement for the snap “aegis-host”.

name: aegis-host

description:

Aegis Host is the native messaging daemon for the Aegis HTTP ecosystem. It acts as a secure, local bridge between your web browsers (Chrome, Firefox, Edge, Brave, Vivaldi, etc.) and your system’s GnuPG keyring. Key Features:

  • Secure Challenge Signing: Authenticate dynamically using GnuPG private keys directly in your browser.
  • Stateless Encryption: Encrypt payloads using public keys on the fly without cluttering your permanent local keyring.
  • GUI Pinentry Support: Interacts seamlessly with your native OS Pinentry dialog (like Pinentry-GTK, Pinentry-Qt, or Pinentry-Mac) for secure passphrase entry.
  • Lightweight & Fast: Written in Rust for maximum memory safety, security, and near-zero overhead.

snapcraft: native-host-rust/snap/snapcraft.yaml at main · AegisHttp/native-host-rust · GitHub

upstream: github.com/AegisHttp/native-host-rust/

upstream-relation: I am the author and lead maintainer of the upstream project.

supported-category: other (temporarily granted classic due to resources not yet supported by snapd, specifically browser native messaging host registration and GnuPGagent socket access)

reasoning:

Technical reasons for why the existing interfaces are not sufficient:

1. Inability to Register Native Messaging Manifests via Strict Interfaces

  • The Problem: For web browsers (Chrome, Chromium, Firefox, Edge, Brave, Vivaldi) to communicate with aegis-host, a JSON manifest file must be written to specific host paths, such as ~/.config/google-chrome/NativeMessagingHosts/ and ~/.mozilla/native-messaging-hosts/.
  • Interface Insufficiency: There is no browser-native-messaging interface in snapd. While the personal-files interface allows reading/writing predefined paths in the home directory, it requires hardcoding the paths in snapcraft.yaml at build-time. We cannot pre-enumerate all potential user configurations, browser variations (e.g., flatpak vs native browsers, custom profiles), or dynamic profile locations. Writing to arbitrary browser-specific folders across different home structures is blocked under strict confinement.

2. Access to GnuPG Keyring and Dynamic Unix Sockets

  • The Problem: aegis-host must execute the system-installed gpg binary (typically /usr/bin/gpg) and interact with the user’s local GnuPG home directory (usually ~/.gnupg/). More importantly, it must establish a Unix socket connection with the running host S.gpg-agent daemon socket to request cryptographic operations.
  • Interface Insufficiency:
    • No GnuPGSocket Interface: There is no standard socket-forwarding interface in snapd for the local GnuPGAgent socket.
    • Strict Isolation: Under strict confinement, access to files outside the snap mount point (like host keyring databases) is denied. The application cannot execute host-level binaries or connect to external background agent sockets running outside the sandbox.

3. Native Pinentry GUI/CLI Dialog Spawning

  • The Problem: When signing or decrypting, GnuPG requires secure passphrase entry by spawning the system’s Pinentry dialog (e.g., pinentry-gnome3, pinentry-gtk-2, pinentry-qt, or terminal-based pinentry).

  • Interface Insufficiency: These Pinentry helpers are spawned by the host gpg-agent or the application itself and require access to the user’s actual session bus, Wayland/X11 display, and system TTY. A strictly confined snap cannot securely invoke or delegate execution to these external host GUI pinentry agents without triggering AppArmor blockages.

  • I understand that strict confinement is generally preferred over classic.

  • I’ve tried the [existing interfaces]to make the snap to work under strict confinement.

Thank you for your time and review!

2

This request has been added to the queue for review by the @reviewers team.

3

Hey @canus

Please note that classic confinement is a sensitive matter and it is reserved for mature, well-known applications published by mature, well-known entities. As of today, I believe that aegis-host doesn’t meet this criteria because of the following reasons:

  • The project seems to be very fresh, according to the upstream repository

  • The projects seems to have little/none community around according to upstream repository (contributors, issues, PRs, etc.)

  • I could not find evidences that the project has a strong enough user base currently

Considering all these factors, I think aegis-host should not get classic confinement as of now.

That said I don’t see a clear reason why this cannot work under strict confinement

1. Inability to Register Native Messaging Manifests via Strict Interfaces

bitwarden and keepassxc are already doing it. Please take a look at their implementation

2. Access to GnuPG Keyring and Dynamic Unix Sockets

I think gpp-keys interface possibly cover all of this.

3. Native Pinentry GUI/CLI Dialog Spawning

x11, wayland, desktop interfaces possibly covers this already. Please share any further apparmor denial you may still find while running under strict confinement.

Thanks