Classic confinement request for govard

store-requests classic-confinement
1
  • name: govard
  • description: Govard is a local development environment orchestrator for PHP applications (Magento, Laravel, Symfony, WordPress). A developer runs it inside a project checkout to bring up, switch between and tear down that project’s containerized stack (web server, PHP-FPM, database, cache, search), open shells in it, run framework CLIs, and sync code and databases with the project’s remote environments.
  • snapcraft: The snap is built by GoReleaser; its snap definition lives in govard/.goreleaser.yml at master · ddtcorex/govard · GitHub (snapcrafts section).
  • upstream: https://github.com/ddtcorex/govard (MIT)
  • upstream-relation: I am the author and maintainer of the upstream project.
  • supported-category: tools for local, non-root user driven configuration of/switching to development workspaces/environments
  • reasoning:
    • Govard fits the supported category “tools for local, non-root user driven configuration of/switching to development workspaces/environments”: a developer runs it inside a project checkout to bring up, switch between and tear down that project’s containerized stack, as a non-root user.
    • I built and installed a strict test snap (base core24) with docker, home, network, network-bind, ssh-keys and removable-media all connected, and ran Govard’s read-only commands. Results:
      • The docker interface grants the socket (the daemon is reachable), but Govard drives environments through the Docker CLI and the docker compose plugin: exec: "docker": executable file not found in $PATH. govard capabilities reports every stack command (env up, ps, status, db, shell, logs, …) as missing, versus ok for the same binary unconfined.
      • $HOME is remapped to ~/snap/<name>/<rev>, so Govard’s real state (~/.govard, including the project registry) is invisible: project list returns an empty registry on a machine with registered projects.
      • Remote/sync workflows lose the user’s SSH agent (agent not reachable; AppArmor denies exec of /usr/bin/ssh-add), and rsync is missing, so sync, deploy and remote * are unavailable.
    • Bundling a Docker CLI/compose/rsync would still leave Govard unable to use the developer’s own state, SSH agent and project checkouts outside $HOME (e.g. /var/www, /srv), which is the core of switching between development environments.
    • Govard never runs as root; optional steps that touch system state (trusting its local CA) are explicit, user-initiated commands.

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.

2

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

3

Hi @ddtcorex

Thank you for the detailed request and breakdown of your testing under strict confinement.

The requirements for classic confinement for govard are understood. The snap fits within the supported category of “tools for local, non-root user driven configuration of/switching to development workspaces/environments”.

However please note that 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 govard doesn’t meet this criteria because of the following reasons:

  • The project seems to be fresh, according to the upstream repository

  • The projects seems to have little community around according to upstream repository.

  • I could not find evidences that the project has a strong enough user base currently

Considering all these factors, I think govard should not get classic confinement as of now.

Sorry for the inconvenience.