Request for Classic Confinement for dotghostboard

store-requests classic-confinement
1

Hello Snapcraft Team,

I am requesting classic confinement for my snap dotghostboard, an advanced clipboard manager built natively for Linux.

Why strict confinement is not sufficient:

  1. System-wide Clipboard Monitoring: The application needs persistent, system-wide access to monitor clipboard events (text, images, and file paths) globally across different DEs. Strict confinement heavily restricts clipboard managers.

  2. Media Processing (ffmpeg): It integrates with the system-installed ffmpeg to generate real-time video thumbnails and previews for copied media file paths anywhere on the user’s disk.

  3. Inter-Process Communication (IPC): It uses QLocalServer for single-instance management and a global system hotkey (Ctrl+Alt+V) to toggle the UI from anywhere, which requires access to abstract sockets outside the sandbox.

  4. File System Access: Users can copy file paths from any mounted partition or directory, and the app needs to read these paths to detect if they are valid media files.

A link to the source code for verification: https://github.com/kareem2099/DotGhostBoard

The snap has already been uploaded and is currently pending manual review. Thank you for your time!

2

Not a store @reviewer, however:

This should be already possible under X11 via the x11 snapd confinement interface.

This falls under the following unsupported category of Process for reviewing classic confinement snaps :

Unsupported

  • dependent software only available on host (ship in instead snap (eg, stage-packages, build from source))

See also Runtime | snapcrafters/ffmpeg-2404-sdk: Content snap for ffmpeg.

Creating local socket is already possible in strict confinement, you can also use QDBus for implementing such feature.

Already possible via the x11 snapd confinement interface.

This falls under the following unsupported category of Process for reviewing classic confinement snaps :

Unsupported

3

Hi Buo-ren,

Thank you for the detailed technical feedback! While I appreciate the suggestions for Strict Confinement, there are several architectural reasons why DotGhostBoard (part of the DotSuite) requires Classic Confinement, especially given our future roadmap:

  1. FFmpeg & Bloat: Bundling FFmpeg inside the snap would increase the package size from ~5MB to over 80MB. For a lean utility aimed at Kali Linux and performance-focused users, relying on the system-wide FFmpeg is much more efficient.

  2. Global File Access for Pentesters: Our users often work with files in non-standard directories (like /tmp/, /opt/, or custom mount points during security audits). Strict confinement’s home/removable-media limitations would break the “Video Path Detection” and “Image Preview” features for these critical use cases.

  3. Secure Deletion (v1.4.0): Our upcoming “Eclipse” update includes a Secure Delete feature that overwrites file bytes before removal. This low-level file system interaction is often blocked or inconsistent under strict confinement.

  4. CLI & System Integration (v1.5.0): We are building a CLI companion for scripts and terminal-based workflows. Providing a seamless, friction-free experience across different distros without constant permission prompts is only possible via Classic mode.

DotGhostBoard is built to be a power-user tool, not a sandboxed app. Given these points, Classic Confinement remains the only way to deliver the full feature set without compromising on performance or usability.

You can check our full technical roadmap here for more details on upcoming features: https://github.com/kareem2099/DotGhostBoard/blob/main/roadmap(v1.x).json

Best regards, Kareem (FreeRave)

4

Hey folks,

dotghostboard does not clearly fit under any of the supported categories defined in the Process for reviewing classic confinement snaps, and most technical reasons are explicitly listed as unsupported.

Moreover, 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 dotghostboard 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

Thus, considering these factors, I think dotghostboard should not get classic confinement as of now.

1 Like
5

Hello Snapcraft Team,

Thank you for your response. I understand the rationale behind requiring a proven community and user base to grant classic confinement from a security standpoint. However, I’d like to respectfully address why this creates an impossible Catch-22 for this specific utility.

DotGhostBoard is, by definition, a system-wide clipboard manager. Its entire core functionality relies on global, uninterrupted access to monitor and capture clipboard events in the background across both X11 and Wayland environments.

Under strict confinement, the sandbox inherently breaks this global monitoring, rendering the core purpose of the application completely useless.

Regarding the community requirement: Gatekeeping necessary system-level APIs behind a “popularity contest” for a newly released, open-source project creates a paradox. Users cannot adopt and build a community around a tool if it cannot be installed and function properly on their systems, and I cannot get the functional classic confinement approved without the users.

The code is 100% open-source, transparent, built with Python/PyQt6, and specifically designed for power users on Linux who need native performance without Electron bloat.

My question to the team is this: If classic confinement is strictly denied based on community size rather than the technical necessity of the app’s category (Clipboard Manager), could you please provide the exact combination of plugs and interfaces in strict confinement that will guarantee seamless, system-wide, background clipboard monitoring without degrading the UX?

If strict confinement cannot technically support a global clipboard manager, then denying classic simply prevents innovation from independent developers.

I look forward to your technical guidance on how to proceed.

Best regards, Kareem Developer of DotGhostBoard

6

You haven’t demonstrated which specific access does the:

  • x11
  • wayland

snapd confinement interfaces can’t provide when the snap is operated in strict confinement.

Note that you can still distribute classic-confined snaps via other channels like GitHub Releases.