Pre-flight eligibility question: restlos-uninstaller and native package removal

store-requests classic-confinement
1

Hello Snap Store reviewers,

I maintain Restlos Uninstaller, an MIT-licensed Python/GTK 4 application and game uninstaller. I have registered the Snap name restlos-uninstaller, but no Snap revision has been built or uploaded. The current public beta is 1.7.0, distributed as a native Debian package and a source archive.

Project and source: GitHub - jurkast/restlos: Sicherer grafischer App- und Spiele-Deinstaller für Debian/Ubuntu, Fedora, Arch Linux und openSUSE · GitHub

Experimental manifest (unbuilt): restlos/snap/snapcraft.yaml at v1.7.0 · jurkast/restlos · GitHub

Before proceeding with Snap packaging, I would appreciate guidance on whether this application’s purpose and access requirements are eligible for the Store. The repository’s snap/snapcraft.yaml currently contains an experimental confinement: classic manifest; it is not a tested or approved distribution.

What the application does

  • Lists applications managed by APT, DNF, pacman, Zypper, Flatpak and Snap, plus supported AppImages and games managed by launchers such as Steam, Lutris and Heroic.
  • Shows a reviewable removal plan before making changes. It invokes the relevant package manager for package removal and can remove user-selected associated configuration, cache, installation and game-data paths.
  • Offers Trash-based recovery for eligible files and optional local backups of eligible settings/save data. These do not undo package-manager operations.
  • Lets users inspect known file locations in their desktop file manager before removal, without changing the removal selection or executing those files.

Current host-access requirements

The native implementation queries host package databases and desktop entries. For native package removal, it executes trusted host package-manager paths through /usr/bin/pkexec; it does not implement this through PackageKit. It also inspects related processes through /proc, can stop them before removal, and reads or changes user-approved application/game data, including hidden configuration directories and game libraries on additional drives. Some launcher integrations update the launcher’s local metadata after removal.

Native package actions first require a successful removal preview and reject protected packages. The path checks protect broad/shared locations, and deletion does not follow symlink targets. These safeguards are not intended as a substitute for Snap confinement or Store review.

Policy question

I have read the classic confinement review policy, particularly the unsupported categories for management/third-party installer snaps and direct access to pkexec. I understand that needing unrestricted host access does not by itself justify classic approval.

  1. Is a cross-package-manager uninstaller with this purpose ineligible for classic confinement under those rules?
  2. Is there a supported strictly confined architecture for this use case, and which interfaces/design constraints would need to be considered before a redesign? For example, would PackageKit-mediated native package removal address only part of the issue, leaving other manager and app-data access out of scope?
  3. If the full functionality is unsuitable for the Snap Store, is native distribution packaging the appropriate route instead?

This is a pre-flight request for guidance, not a request to approve the current manifest or bypass confinement. Thank you for helping clarify the appropriate distribution path.

2

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

1 Like
3

Wow !!!

Color me impressed

You are in the whole time this forum exists the very first person to ask about this upfront instead of simply submitting a classic snap and asking about approval afterwards !!!

While I’m not in the reviewers team I think chances are pretty low to get approval for such an app as classic snap.

For strict snaps we do have a packagekit facing interface but I’m not sure what the requirements are to actually get it granted (and your current implementation obviously doesn’t use packagekit anyway (yet))

Access to /proc might be possible (with limitations) through the process-control interface that should also allow killing (IIRC the htop snap uses it that way)

In general we do have the snappy-debug tool you can run aside a strict snap, it will inspect the denials caused by the app and tries to make suggestions for interfaces to use.

Let’s see what the actual reviewers have to say…

1 Like
4

Hello @jurkast,

Thank you for the detailed inquiry! You are correct to flag that this snap falls under the unsupported category of third-party installer/management snaps, and being under a supported category is required for classic confinement. In addition to this, as classic confinement is a sensitive matter, it is reserved for mature, well-known application, and from what I can find, this project is quite fresh and so does not meet that criteria as well.

As for proceeding under strict confinement. Given the widespread access this requires, many of the needed interfaces are gated behind approval for installation. As is the case for packagekit-control and snapd-control. My instinct is you would not be able to achieve full feature parity under strict. In addition, these approvals would require similar levels of trust as for classic. This means that the current maturity of this project would most likely be an issue in those requests as well.

Due to these complexities, I would encourage proceeding with native distribution packaging. While I believe this is not currently a good candidate for the Store, you could ship the snap as a GitHub release. Users can install it with sudo snap install ./your-snap-name.snap --classic --dangerous , though this bypasses signature verification and the update mechanism that the Store provides. In addition, it is important for users to understand that this provides the application with effectively unconfined access to their system.

Please let me know if you have any other questions.