Classic confinement request for git-sentinel

  • name: git-sentinel

  • description: Git Sentinel is a local-first desktop application for monitoring the state of multiple existing local Git repositories from a single dashboard. It shows the current branch, working tree state, local and remote-tracking divergence, remotes, upstream information and fetch freshness. It also provides explicit Refresh and Fetch actions and can open repositories in the user’s terminal emulator or file manager.

  • snapcraft: git-sentinel/snap/snapcraft.yaml at main · osamucadev/git-sentinel · GitHub

  • upstream: https://github.com/osamucadev/git-sentinel

  • upstream-relation: I am the original author and maintainer of Git Sentinel.

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

  • reasoning: Git Sentinel operates on the user’s existing development environment rather than providing an isolated Git environment of its own.

    The application invokes the host git executable and intentionally uses the developer’s existing Git configuration, credential helpers, SSH configuration and authentication environment. Fetch operations are explicit user actions and are expected to behave the same way as running Git directly from the user’s terminal.

    Git Sentinel also needs to inspect existing repositories selected by the user. These repositories may live anywhere on the host filesystem, including paths outside $HOME and on other mounted volumes.

    In addition, Git Sentinel provides “Open in Terminal” and “Open Folder” actions. These launch the user’s installed host terminal emulator and file manager for the selected repository.

    Strict confinement would therefore give Git Sentinel an isolated environment that differs from the developer’s actual Git environment and would prevent or significantly restrict core functionality. Bundling a separate Git executable would also be undesirable because Git Sentinel is specifically intended to observe repositories using the same Git installation and configuration that the developer uses outside the application.

    I reviewed the available strict-confinement interfaces. Interfaces such as home and removable-media can cover portions of filesystem access, but they do not provide the combination required here: arbitrary user-selected repository locations, the host Git environment and configuration, and launching arbitrary installed terminal emulators as part of the development workflow.

    Git Sentinel does not automatically perform destructive or repository-mutating Git operations such as pull, push, checkout, merge, rebase, reset, stash, commit or branch deletion. Network access occurs only when the user explicitly requests Fetch or Fetch All. Removing a repository from Git Sentinel only removes it from Git Sentinel’s local registry and never deletes, moves or modifies the repository.

    Revision 1 (version 0.1.0) has already been uploaded to the Snap Store and is currently pending manual review because of the requested classic confinement.

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

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

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

Hello @srcaetite,

From the description and reasoning, I feel that this snap falls more into the unsupported categories: dependent software only available on host, and access to arbitrary files on the system because the application isn’t designed with confinement in mind and therefore does not qualify for classic confinement.

In addition, classic confinement is a sensitive matter and reserved for mature well-known applications published by mature, well-known entities. From my understanding, I do not believe git-sentinel currently meets this criteria as it appears to be very fresh, according to the upstream repository. As such, I believe git-sentinel should not be granted classic at this time. Thank you for your understanding.