Enable classic confinement for the gh snap

[mislav]

The gh snap gives GitHub CLI users a bad experience, as evident by the number of issues that are first reported in our repo and then determined to have been caused by snap packaging/runtime:
https://github.com/cli/cli/issues?q=is%3Aissue+snap
https://github.com/cli/cli/discussions?discussions_q=snap

This often costs us (GitHub CLI maintainers) time to triage and asses these issues. Sometimes it's not evident that the user has installed gh via snap, as they don't always include that information in their report. Typical issues reported are "permission denied errors", git clone errors, filesystem errors, and other edge-case bugs that aren't present in our own builds of GitHub CLI, but are present in the gh snap.

I do not believe that these bugs are explicitly caused by your own repository, but I do think that snap (or, more generally, containerized or sandboxed packages) is an insufficient mechanism to distribute and run apps like ours. Installing an official gh binary locally on the system (either directly or from our debian package repo) is a vastly superior and stabler method to keep running gh without extra trouble, and yet when Ubuntu users type gh, they get suggested to install the snap, which sets them up for a bad experience:

$ gh

Command 'gh' not found, but can be installed with:

sudo snap install gh       # version 1.12.1-pre.0-15-gbf5b34d0, or
sudo apt  install gitsome  # version 0.8.0+ds-4

See 'snap info gh' for additional versions.

I do not know of ways to fix these issues, but I would much rather that the gh snap isn't featured so prominently, and the only way I can imagine fixing that is by unpublishing gh from the Snap store. An even more ideal solution would be so that nobody is allowed to publish a snap for GitHub CLI again, but I guess neither of us has that level of control over the Snap store.

Thank you for reading.

Ref. cli#328

[woodsmanlucas]

Hey just curious how do I get back on the non snap version? I see the install instructions here: https://github.com/cli/cli/blob/v2.0.0/docs/install_linux.md but when I run
$ snap remove gh
and then those instructions I get
$ gh --version bash: /snap/bin/gh: No such file or directory
I assume I have the wrong directory for the bash alias. How do I fix that? What is the file for the normal install?

[mislav]

@woodsmanlucas You can run type gh in your shell to see what would be executed: a command, a shell function, or a shell alias.

After installing the Debian package, the path to it should be /usr/bin/gh, I think.

[casperdcl]

hmm interesting @mislav I would prefer to get confirmation from https://github.com/orgs/snapcore/people before doing something as drastic as unpublishing.

[mislav]

Sure thing! I just wanted to make sure you're aware of the influx of issues we're seeing reported in our issue tracker due to Snap. 👍

[jaron-l]

Would snap clasic resolve some of these issues? Seems like getting around confinement would help a lot.

[mislav]

@jaron-l "Classic" does sound like it would be a better confinement method for CLI tools such as ours. However, if users are required to explicitly opt into classic by means of --classic flag at install time, and if the default suggestion from Ubuntu when one types gh remains just sudo snap install gh (i.e. without the --classic flag), I think we'd still have a problem because I imagine the typical user not knowing that they are supposed to install in classic mode.

[casperdcl]

sudo snap install gh won't work if it's a --classic snap... you'd get an error message saying the --classic flag is required

[jaron-l]

sudo snap install gh won't work if it's a --classic snap... you'd get an error message saying the --classic flag is required

Can confirm this. "Classic" is the type of snap and the user gets prompted to add it if it's not there saying that they they need to add it if they know the risks. A good example of this is the vscode snap.

[charlesritchea]

I use Ubuntu as my primary OS and I expect for many snaps to require classic, for them to fail without --classic and for me to retry with --classic. When I tried to use the snap gh it failed because it couldn't write to /etc. IMO the snap should not exist the way it is right now and agree with the original post.

[cardonator]

Also agree here. The command doesn't work right and causes issues which seem to be gh's fault and not the snap.

[nextgenthemes]

Not an expert on snaps yet BUT to confirm what was said earlier, when this would be packages in the classic snap format the user must install with --classic and can NOT install it "wrongly". The first message would suggest it without --classic I think, but they would be reminded when trying that they need the switch.

I do think snap is actually a good way to distribute this. I installed the media player Clementine today and I needed to set a specific option to read and write from mounted drives. It had permission to my home directory by default. So even for the sandboxed snaps there are ways to get more permissions, but I think for this the classic package is probably the only thing that makes sense. Still because snap works on so many distros it is better than to maintain so many packages.

So my suggestion would be not to unpublish it, but to do a proper classic snap that has all the permissions and just acts like a normal binary from any other package manager that is distro specific.

Because of the tight integration into Ubuntu and derivates, it thinks it's amazing to have a message suggest an installation method for something that is outside the regular repos. That is FAR superior to having to add a PGP key, repo ... and install through apt ...

[jonbirge]

So, @mislav, you guys can't build a proper snap and so you take your ball and go home? One of the links you provide as "evidence" of snap being insufficient is a thread on somebody using docker?

[ChrisNzoka]

@mislav Are you saying "remove gh from your machine and rest".
I tried to instal gh using sudo apt install gh
The machine returns E: Unable to locate package gh

[mislav]

@jonbirge I admit that I wouldn't know how to build a better snap. My argument is that gh should never be packaged and distributed in any “containerized” format. From the Wikipedia page about snap:

Snaps are self-contained applications running in a sandbox with mediated access to the host system.

GitHub CLI, by design, should not be running in any kind of sandbox. It wants to have full access to the host system. It's true that some of the resources I've linked to are about Docker, not snap, but the argument is the same.

@ChrisNzoka GitHub CLI installation instructions for Debian/Ubuntu include information on how to add our own Debian package repository to your package sources. Without that, apt install gh will not work (or it will install the wrong thing).