Classic confinement request for BusyMark

store-requests classic-confinement
1

  • name: busymark

  • description: BusyMark is an editor for Markdown and Writerside-compatible documentation projects. It includes an integrated Git client for reviewing, staging, committing, branching, synchronizing, and inspecting repository history.

  • snapcraft: busymark/snap/snapcraft.yaml at Release/v0.3.1 · busystack/busymark · GitHub

  • upstream: GitHub - busystack/busymark: Markdown and Writerside Editor for Linux with Git, PlantUML, Mermaid, D2, OpenAPI, MathJax, AI editing, and export to PDF · GitHub

  • upstream-relation: I am the upstream developer and publisher.

  • supported-category: IDEs

  • reasoning: BusyMark needs classic confinement because its integrated Git client must behave like Git invoked from the user’s terminal or another IDE.

    Git configuration can invoke arbitrary user-configured credential helpers, SSH/GPG agents, signing programs, hooks, custom transports, external tools, and conditional configuration includes. Documentation workspaces can also be located on user-selected paths. These requirements cannot be represented by a fixed set of strict-confinement interfaces.

    Under strict confinement, the Snap receives an isolated HOME and cannot honor the user’s normal Git identity and configuration. This caused valid Git commits to fail with “Author identity unknown”, despite the identity already being configured for the user. Requiring users to duplicate their Git identity in every repository or inside the Snap would make BusyMark’s Git integration inconsistent with normal Git and other IDEs.

    BusyMark bundles Git and its required runtime libraries. Classic access is used only for user-initiated editor and Git operations. BusyMark does not run a privileged daemon, does not request root access, and does not modify the user’s Git identity.

I understand that strict confinement is generally preferred over classic.

I tried the existing interfaces under strict confinement. They cannot support arbitrary user-configured Git helpers, hooks, transports, signing tools, configuration includes, and authentication agents.

2

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

3

Hello @cyber.albert,

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 busymark doesn’t meet this criteria because of the following reasons:

  • The project seems to be very fresh, according to the upstream repository
  • I could not find evidence that the project has a strong enough user base currently
  • Being a markdown editor as described, I am not confident it cleanly qualifies for the IDE supported category

Considering this, I think busymark should not get classic confinement as of now.

I do believe a wide range of the issues mentioned in your reasoning can be worked around under strict confinement. You might be able to find some helpful advice for trying to get strict working for a majority of users in this thread concerning a similar snap.