Classic confinement request for putzen

store-requests classic-confinement
1

To make the review of your request easier, please use the following template to provide all the required details and also include any other information that may be relevant.

  • name: putzen

  • description: “putzen” is German for “cleaning”. It helps keep your disk clean by safely removing build and dependency artefacts. The putzen caches subcommand is an interactive TUI for browsing and reclaiming space from user-level tool caches (.cargo, .npm, .cache/huggingface, .gradle, …) ranked by score × age.

  • snapcraft: putzen-rs/snap/snapcraft.yaml at main · sassman/putzen-rs · GitHub

  • upstream: GitHub - sassman/putzen-rs: "putzen" is German and means cleaning. It helps keeping your disk clean of build and dependency artifacts safely. · GitHub

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

  • supported-category: tools for local, non-root user driven configuration of/switching to development workspaces/environments

  • reasoning: Putzen scans, ranks, and presents user-level tool caches in an interactive TUI; nothing is ever deleted without an explicit user selection and a confirmation prompt. There is no auto-delete path. Almost all targeted caches live in dot-directories under HOME (~/.cargo, ~/.npm, ~/.cache/*, ~/.gradle, ~/.ivy2, …). The home interface hides hidden paths, so under strict every cache reads as empty and there is nothing for the user to act on.

    We evaluated the strict alternatives before requesting classic:

    • system-backup (the path gdu took, topic 22400) is read-only, so it covers scanning but not the user-confirmed delete - putzen’s primary purpose.
    • personal-files write declarations would have to enumerate every cache root in the manifest, freezing the discovery set putzen exists to grow.
    • --root <dir> accepts arbitrary user-supplied paths at invocation (/var/cache, mounted external drives, CI caches); no strict plug covers that.

    Peer disk-cleanup tools (kondo, dust, fclones) ship classic for the same reasons.

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.

Note that snappy-debug can be used to identify possible required interfaces. See https://snapcraft.io/docs/debug-snaps for more information.

2

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

1 Like
3

Hello @5422m4n,

Unfortunately I believe this snap fails to fit under the listed supported classic category. Instead, I believe it falls into one of our unsupported cases of:

  • access to arbitrary files on the system because the application isn’t designed with confinement in mind

In addition, I found that the listed peer disk-cleanup tools all are published under strict confinement in the snap store. As such, I do not believe putzen should be granted classic confinement.

To move forward with strict confinement, I would encourage making a personal-files interface request with a list of the most popular known dot-directories. While it is not ideal from a development or user perspective, this list can be expanded upon for requested and relevant dot-directories in future revisions. In addition, if the first personal-files request is approved and publisher vetting is successful, future requests for adding new files to the list should be quickly approved and applied.