Hi,
I’d like to request classic confinement for pgp-manager and have filled out the template below. Happy to provide more detail or adjust anything if needed.
- name: pgp-manager
- description: PGP Manager is a desktop OpenPGP client for Linux. It generates, imports and exports keys, encrypts and decrypts text and files, creates and verifies signatures, and searches and publishes keys on public keyservers. It watches the clipboard so that encrypted blocks, signatures and public keys can be acted on directly from the system tray, and it reads existing GnuPG keyrings so users don’t have to re-import keys they already hold.
- snapcraft: pgp-manager/snap/snapcraft.yaml at main · developaaah/pgp-manager · GitHub
- upstream: GitHub - developaaah/pgp-manager: A modern, cross-platform desktop app that makes OpenPGP simple — manage keys, encrypt, sign, and verify, all offline and under your control. · GitHub
- upstream-relation: I am the original author and sole maintainer of the project. The snap is published by me, the same person who writes and releases the upstream code.
- supported-category: None of the listed categories is a clean match. The closest in spirit is a file-system / backup-style tool, since the core job is reading and writing user-chosen files anywhere on disk. I’m flagging this honestly rather than forcing a fit, because the access pattern below is the actual basis for the request.
- reasoning: The app operates on file paths the user supplies directly, not only on files picked through the desktop portal. Three of its main entry points never go through a portal dialog:
- Tray and clipboard actions — when the clipboard or a tray menu triggers an encrypt/decrypt/sign operation on a referenced file, there is no file-chooser interaction, so the document portal grants no access to that path.
- Batch and path-input operations — users paste or type absolute paths, including locations outside
$HOMEand outside removable media (mounted shares, project directories under/srv, system config under/etc). - GnuPG keyring integration reads and updates
~/.gnupg, a hidden directory not covered by thehomeinterface. I tried strict confinement first withhome,removable-media,gpg-keysandnetwork.homeexcludes hidden files, which breaks both the app’s own~/.pgpstorage and GnuPG keyring access;gpg-keysis read-only and does not cover keyring updates; andhome+removable-mediatogether still do not cover the arbitrary absolute paths the tool is built to operate on. Requiring users to first copy every file into$HOMEwould defeat the purpose of a general-purpose encryption tool.personal-files/system-filescould patch individual gaps but cannot enumerate the arbitrary paths users encrypt, which is the fundamental requirement.
On project maturity: I want to be upfront that this is a young project rather than have it count against the request quietly. The codebase is published and built openly, the snap is built and released straight from CI on tagged commits, and I’m the active maintainer responding to issues. I’m committing to keeping the snap current with upstream releases and to security updates, and I’m happy to start on an unstable or candidate channel and only promote to stable once there’s a track record, if that’s the preferred path for a newer publisher. I’d rather establish that maintenance pattern early than ship the app in a way that quietly breaks core functionality under strict confinement.
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.
Thanks for taking the time to review this.