name: repobeam
description: RepoBeam is a desktop Git client for Linux and Windows. It shows commit history, stages whole files or single hunks, and resolves conflicts side by side. For actions that change history, it shows the commit graph as it is now and as it is expected to look afterwards before anything runs. It drives Git directly. There is no RepoBeam account or server. It ships as a Windows installer, a .deb, an AppImage, and this snap: https://snapcraft.io/repobeam.
snapcraft: The source repository is private. This is the confinement-relevant part of the
current strict snapcraft.yaml. I can share the full file and the CI workflow that builds it.
base: core24
confinement: strict
apps:
repobeam:
command: bin/launch-repobeam --no-sandbox
extensions: [gnome]
environment:
GIT_EXEC_PATH: $SNAP/usr/lib/git-core
GIT_TEMPLATE_DIR: $SNAP/usr/share/git-core/templates
plugs: [browser-support, home, network, network-bind, removable-media, ssh-keys, gpg-keys]
parts:
repobeam:
plugin: nil
stage-packages: [git, git-credential-oauth, openssh-client, ca-certificates, gnupg, xdg-utils]
upstream: PRIVATE. Website: https://repobeam.com. Releases and public issue tracker: https://github.com/ferchichibaha7/repobeam-releases
upstream-relation: I am the developer of RepoBeam and its only publisher. The snap is built by the same CI workflow, from the same commit, as the Windows installer, the .deb and the AppImage.
supported-category: IDEs. GitKraken (https://forum.snapcraft.io/t/classic-confinement-request-for-gitkraken/14682) and Sublime Merge (https://forum.snapcraft.io/t/classic-request-for-sublime-merge/14223) were granted classic confinement as Git clients in this category.
reasoning:
A Git client has to run whatever the user’s Git setup names. Git starts these programs itself. Each user and each repository decides what they are, so they cannot be known when the snap is built:
- repository hooks (
pre-commit,commit-msg,pre-push), installed by tools such as husky, pre-commit and lefthook, and whatever they call: linters, formatters, test runners,make,node - credential helpers set in
credential.helper: libsecret, Git Credential Manager,gh auth git-credential, password managers - the SSH agent,
core.sshCommand, and SSH-format commit signing with a key held in the agent - filters and custom transports, such as Git LFS
Here is what happens under strict confinement. I reproduced each point with the current stable revision (1.6.3, revision 9) on Ubuntu.
-
Repository hooks fail, so Git refuses the commit. The same commit succeeds from the host terminal.
$ cat .git/hooks/pre-commit #!/bin/sh make --version >/dev/null && echo "hook: checks passed" host: git commit -m test -> hook: checks passed snap: git commit -m test -> .git/hooks/pre-commit: 3: make: not found (exit 1) -
The user’s SSH agent is unreachable. Inside the snap,
ssh-add -lprintsError connecting to agent: Permission denied.ssh-keysgrants read access to~/.sshonly, and no interface exposes the agent socket. Keys held only by an agent (1Password, KeePassXC) cannot be used. Neither can passphrase-protected keys that the agent normally unlocks, or SSH commit signing with those keys. -
The user’s Git configuration is not the one in effect. Git runs with
HOME=~/snap/repobeam/<revision>, so~/.gitconfigis not read. Author identity, signing settings,includeIfrules and credential helpers all silently differ from the terminal. On my machine the snap commits under a different spelling of my name. -
HTTPS remotes need a separate sign-in. The user’s credential helper cannot run, so the snap bundles
git-credential-oauth. It signs in through the browser with an OAuth app that must ask for GitHub’sreposcope, which is read and write access to all of the user’s repositories, just to push to a private one. Users who already have a working credential helper are asked for a new, broad token instead. With classic confinement, the snap removes this helper and uses the one the user already trusts. -
“Open in terminal” cannot start the user’s terminal.
/usr/bin/x-terminal-emulatordoes not exist inside the snap.
What I tried under strict confinement:
- I bundled Git, OpenSSH and GnuPG as stage packages.
ssh-keysandgpg-keysare declared and not auto-connected. RepoBeam checks them withsnapctl is-connectedand shows the user thesnap connectcommand. This makes key files readable, but not the SSH agent.- A bundled OAuth credential helper handles HTTPS (point 4).
- I considered
personal-filesfor~/.gitconfig. It would make the configuration readable, but the configuration mostly names programs (helpers, hook tools, signing programs) that still could not run. Point 1 fails even with a correct configuration.
So under strict confinement the snap behaves like a different Git from the one in the user’s terminal. Users with hooks, an SSH agent or a credential helper cannot commit or push their own repositories the way they normally do.
How RepoBeam will behave under classic confinement:
- It runs as the user. It never asks for root and installs no service or daemon.
- It starts Git and, through Git, only what the user’s configuration and repositories specify. It also starts the user’s terminal when they click “Open in terminal”.
- It uses the host’s Git when one is installed and recent enough. Otherwise it uses the Git bundled in the snap, so a missing or old host Git does not break it.
- The bundled OAuth helper and the credential settings RepoBeam passes to Git inside the snap are removed.
- It sends no telemetry. Its only network activity is an update check (api.github.com, api.snapcraft.io) and Git operations against the user’s own remotes, including a background fetch every five minutes that never prompts for credentials.
Build and migration plan:
-
The build uses core24 without the gnome extension. Electron’s runtime libraries are staged and ELF-patched so the snap does not depend on host libraries.
-
Before the first classic release, I will test it on Ubuntu 22.04 and 24.04, Debian 12 and Fedora.
-
Existing strict installs will not refresh to a classic revision on their own. The last strict release will tell users inside the app to run
sudo snap refresh repobeam --classic. RepoBeam already checks the store for new versions. The release notes and repobeam.com will say the same. -
I understand that strict confinement is generally preferred over classic.
-
I’ve tried the existing interfaces to make the snap work under strict confinement.
