Open mislav opened 3 years ago
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?
@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.
hmm interesting @mislav I would prefer to get confirmation from https://github.com/orgs/snapcore/people before doing something as drastic as unpublishing.
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. 👍
Would snap clasic resolve some of these issues? Seems like getting around confinement would help a lot.
@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.
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
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.
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.
Also agree here. The command doesn't work right and causes issues which seem to be gh's fault and not the snap.
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 ...
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?
@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
@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).
@mislav There are multiple ways for a snap to access the file system, some more safe than others, but all pretty easy. Both snap and docker are containerized, but unlike docker snap is designed to—-among other things—package CLI user tools whereas docker is aimed at server workloads, and so your statement is flat out wrong. Plenty of tools with the same requirement as yours work well as snaps, such as VS Code. Bottom line: if you don’t want somebody doing a poor job packaging your software do it right yourself. People want things like snap and flatpak because they are better than the old packaging formats.
There are multiple ways for a snap to access the file system, some more safe than others, but all pretty easy.
I'm sure this project will welcome any advice you have on how to improve the existing snap. My team has zero incentive to publish a snap for GitHub CLI ourselves because we don't see what the user could possibly gain by us doing so? So far the only reason for us to publish an official snap would be to get ahead of the community publishing their own, worse snaps. This is a poor reason in my book.
We already publish an official .deb
package that, when installed, has full access to the filesystem. It has no dependencies apart from git
which it doesn't bundle so that the user is free to install & upgrade git on their own terms. In fact, our packages approach would have been perfectly fine for everyone had Ubuntu not offered its users a suggestion to install gh
in a way that is sub-optimal and subject to failures. De-listing gh
from the snap store would save a lot of people headaches and I've proposed it here because I thought it would be much less work than any other alternative.
Well, as a potential user I’d much prefer to type snap install gh
than have to add a repo on to every machine I stand up just to install your tool. So, don’t include me as a user who doesn’t care. I haven’t and won’t install your tool unless I see some huge need for it, but I’d have tried it out by now if it were a one liner to install. Not sure why you bother to write a cli tool and then have this arrogant attitude about distribution.
@mislav It is totally inappropriate for a Github client to have "full access to the host system". Installing random binaries people find on the internet, or adding random PPAs they come across like yours, is a huge security vulnerability and a major issue that packaging systems like Snap aim to solve. No one should be installing your deb if they care about security.
So, the motivation for you, is to provide a standard, cross-distro solution for distributing your product from an official source, using a secure distribution mechanism that doesn't require an end-user to give your application full root access to their system when it is in no way required. Yes, it does require classic confinement, but come on. Users installing a Github client are smart enough to figure that out. When installing from the Snap Store or Gnome-Software, classic confinement is granted automatically anyway. What the user will gain is security and piece of mind, much simpler installation, and pain-free distro upgrades.
You are really showing your bias in this thread and it is not helpful. Plenty of other Microsoft products are officially packaged as snaps, why is yours any different? Once you offer Snap and/or Flatpak packages, you can eliminate all of the other packaging methods you maintain and alleviate that burden from your team. This is a win-win.
@mislav It is totally inappropriate for a Github client to have "full access to the host system". Installing random binaries people find on the internet, or adding random PPAs they come across like yours, is a huge security vulnerability and a major issue that packaging systems like Snap aim to solve. No one should be installing your deb if they care about security.
So, the motivation for you, is to provide a standard, cross-distro solution for distributing your product from an official source, using a secure distribution mechanism that doesn't require an end-user to give your application full root access to their system when it is in no way required. Yes, it does require classic confinement, but come on. Users installing a Github client are smart enough to figure that out. When installing from the Snap Store or Gnome-Software, classic confinement is granted automatically anyway. What the user will gain is security and piece of mind, much simpler installation, and pain-free distro upgrades.
You are really showing your bias in this thread and it is not helpful. Plenty of other Microsoft products are officially packaged as snaps, why is yours any different? Once you offer Snap and/or Flatpak packages, you can eliminate all of the other packaging methods you maintain and alleviate that burden from your team. This is a win-win.
I completely agree on all counts. What's infuriating isn't so much that they don't offer a snap or flatpak, but that they go to lengths to make trouble for somebody who tried to help by doing so and claim it wasn't appropriate and yet betray a complete misunderstanding of how snap or flatpak works. @mislav For all the time you've spent trying to suppress somebody from making a snap, maybe you would've done better for your customers by just learning enough about it to help.
It is totally inappropriate for a Github client to have "full access to the host system". Installing random binaries people find on the internet, or adding random PPAs they come across like yours, is a huge security vulnerability and a major issue that packaging systems like Snap aim to solve.
@hackel Sure, I can see some of your points, but note that taking this discussion to be primarily about security is a bit off-topic. When I started this thread, it wasn't about the security of running the gh tool, but about its stability and robustness. The issues that gh users had with the current snap were in relation to git and filesystem and such. I think the security discussion is a valid one, but a more secure tool isn't an improvement if that tool doesn't work as a result.
If "classic" confinement solves these issues with the gh snap, then by all means, I encourage this snap to move to classic confinement, and this can be closed.
Finally, if a Linux user would not trust a PPA published by GitHub, that is valid, but that signals mistrust of the GitHub organization, not of the PPA mechanism. If you presume that GitHub may be acting maliciously or that our PPA might be compromised by an attacker, then you probably don't want to be installing any GitHub official binaries from any source. The most secure approach would be to build from source yourself, which is relatively trivial for our project.
But what I don't understand is, if you've chosen to trust GitHub as an organization, why you wouldn't trust a PPA published by GitHub but you would install a GitHub CLI binary maintained and built by a 3rd-party (@casperdcl
).
What's infuriating isn't so much that they don't offer a snap or flatpak
@jonbirge You admitted earlier in this thread that you aren't a user of GitHub CLI, so I do not understand what you are still engaged in this discussion. I may be biased against Snap, but at least I have a stake in this discussion since I have to maintain GitHub CLI and I care about our users' experience when installing the tool on Linux. You neither use gh nor are you willing to contribute concrete improvements to this repository to fix the very real issues I've raised with how gh behaves at runtime when installed through snap vs. being installed as a deb package.
@mislav I am an active user of GitHub and would love to use a good cli tool. That’s why I have a stake. But I’m not inclined to install a PPA on every Linux system I stand up just to install one package because you all have irrational issues with modern software distribution or the usual Linux zealotry over this and that distro.
I have offered a solution: you either leave this guy alone or build your own snap.
Wasted 30 minutes because of this. I know that I'll waste time with this on my next install of Linux, so future me would like to ask you to remove this piece of shit from snap please <3
@jyaif Per my original post, a lot of gh users have lost time with the snap distribution of gh, but that isn't reason enough for you to use harsh words in this thread. @casperdcl
wasn't acting in bad faith when they originally published the snap, and now we're all just trying to find a solution that would be best for GitHub CLI users. There is no need for inflammatory comments in the meantime; thank you! 🙇
The solution is using --classic like everything other package needing system stuff, moving on...
On Sat, Jul 9, 2022, 8:38 AM Mislav Marohnić @.***> wrote:
@jyaif https://github.com/jyaif Per my original post, a lot of gh users have lost time with the snap distribution of gh, but that isn't reason enough for you to use harsh words in this thread. @casperdcl wasn't acting in bad faith when they originally published the snap, and now we're all just trying to find a solution that would be best for GitHub CLI users. There is no need for inflammatory comments in the meantime; thank you! 🙇
— Reply to this email directly, view it on GitHub https://github.com/casperdcl/cli/issues/7#issuecomment-1179536614, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMUMHKSZJV6X24HYRNQXITVTFXDBANCNFSM5AYACA5Q . You are receiving this because you commented.Message ID: @.***>
@charlesritchea Would an average user know to add --classic
to the installation invocation when the OS presents them with instructions that omit --classic
?
$ gh
Command 'gh' not found, but can be installed with:
sudo snap install gh
@charlesritchea Would an average user know to add
--classic
to the installation invocation when the OS presents them with instructions that omit--classic
?$ gh Command 'gh' not found, but can be installed with: sudo snap install gh
Yes, snap tells you to use --classic when it's needed
Would an average user know to add
--classic
to the installation invocation when the OS presents them with instructions that omit--classic
?
If snap install
's instructions omit the --classic
flag, the snap cannot be installed in classic confinement. The creator of the snap must explicitly opt in to classic confinement, and the snap team must explicitly grant permission to every classic confinement snap published to their store. The process is documented here.
It is totally inappropriate for a Github client to have "full access to the host system" (...) So, the motivation for you, is (...) distributing your product from an official source, using a secure distribution mechanism that doesn't require an end-user to give your application full root access to their system when it is in no way required. Yes, it does require classic confinement, but come on.
A snap with classic confinement is not sandboxed, i.e. run without restrictions. This is very similar to the security implications of a regular DEB package. So the only real benefit of distributing gh as a snap is for Ubuntu users to not have to set up a dedicated repository (DEB). Users of almost all other distros don't have snap and its official repository (snapcraft store) preinstalled, so they would likely need to set that up first.
يعطي gh snap لمستخدمي GitHub CLI تجربة سيئة ، كما يتضح من عدد المشكلات التي تم الإبلاغ عنها لأول مرة في الريبو الخاص بنا ثم تم تحديدها بسبب التغليف المفاجئ / وقت التشغيل: https://github.com/cli/cli/ المشكلات؟ q = هل٪ 3Aissue + snap https://github.com/cli/cli/discussions؟discussions_q=snap
هذا غالبًا ما يكلفنا (مشرفو GitHub CLI) وقتًا لفرز وتقييم هذه المشكلات. في بعض الأحيان ، لا يكون من الواضح أن المستخدم قد ثبَّت gh عن طريق snap ، لأنه لا يقوم دائمًا بتضمين هذه المعلومات في تقريره. المشكلات النموذجية التي تم الإبلاغ عنها هي "أخطاء رفض الإذن" وأخطاء git clone وأخطاء نظام الملفات وأخطاء حالة الحافة الأخرى غير الموجودة في تصميمات GitHub CLI الخاصة بنا ، ولكنها موجودة في gh snap.
لا أعتقد أن سبب هذه الأخطاء صريح هو المستودع الخاص بك ، لكنني أعتقد أن snap (أو ، بشكل عام ، الحزم المعبأة في حاويات أو في وضع الحماية) ليست آلية كافية لتوزيع وتشغيل تطبيقات مثل تطبيقاتنا . يعد تثبيت برنامج gh binary رسميًا محليًا على النظام (إما بشكل مباشر أو من repo حزمة دبيان) طريقة متفوقة وثابتة إلى حد كبير للاستمرار في تشغيل gh دون مشاكل إضافية ، ومع ذلك ، عندما يكتب مستخدمو Ubuntu
gh
، يُقترح عليهم تثبيت snap ، والذي يهيئهم لتجربة سيئة:$ 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
Bd
This bug has been around for about 18 months now, but there hasn't been much in the way of meaningful change to solve the underlying issues. I'm going to provide what I believe to be an accurate summary (please correct me if I'm wrong in the summary, as my having an accurate understanding is crucial to my suggestions), followed by a series of suggestions to improve the situation.
This is going to be a fairly long read for a bug comment, so you might want to get some tea or coffee before continuing, but I hope it'll set us on a course for a positive resolution.
The reasons for requesting removal appear to be primarily based around packaging and confinement related issues being posted to the main repository rather than here or another appropriate place for snap-specific triage.
There have been some discussions of technical changes to the package to help with this (e.g. classic confinement, unpublishing the snap), but also discussion as to whether this is appropriate.
The technical changes, while potentially valuable in their own right (see below), are attempts to make technical fixes to a social problem. There are two competing points of view here that are causing the friction, and the obvious solutions appear to be contradictory. But if we look at the root concerns, I believe we can provide a compromise that works for everyone. The root issues, as I see them, are:
Given the entire section in the upstream documentation about unofficial packaging, it's clear that the project doesn't have an issue with third-party packaging, so as long as we can provide that third-party packaging in an unintrusive manner, the project will likely not have a problem with snap packaging.
There's both a technical side and a social side to this, and neither "camp" (the project developers and the snap packagers) can solve it on their own. Even in the most extreme realistic scenario (unpublish this package and hand ownership of the gh
snap name to the github cli developers, preventing another gh
package from being made), this doesn't prevent someone else from coming along and making another package with a different name, even with the best of intentions.
The first thing to do is to come up with a way to prevent the upstream developers from getting packaging-specific issues. For this, my suggestions are as follows:
First, make it more obvious that the snap package is unofficial. While people are used to packages in their default apt
repos, in pacman
, etc. being maintained by their distro maintainers, the nature of snap
's publication model blurs those lines. While some applications have unofficial snap packages, others such as postman, Slack, and Krita are all maintained by their upstream developers. Probably the biggest flag that something's unofficial is when it's published by Snapcrafters. This is a bigger tell than not having a checkmark next to the snap's name, as some officially-packaged snaps are also not from verified accounts. We can also include notes that this is an unofficial package in the description, much like the gimp, obs-studio and Discord snaps do. That's not perfect, but it should make it clearer.
Second I suggest that the upstream developers modify their bug reporting process slightly to direct users of third-party packages to check whether the issue is related to their packaging. I recommend doing the following:
Third, I suggest we find a way for upstream developers to easily "transfer" an issue to the snap packagers. To jump to a technical solution for this, if upstream would be willing to have a workflow that looks for a snap
label and provides a redirection response, any snap-related issues that slip through the cracks could be solved by simply tagging that issue with snap
. A combination of the existing sample workflow in the GitHub docs and the close-issue Action should do the trick.
These changes as a whole should both greatly reduce the snap-related issues reported upstream and, when one gets through, allow the upstream developers an easy way to hand off the issue. (This could also be expanded to cover other workflows, such as unofficial BSD packages. An ideal generalisation would allow full redirection of other appropriate issues to support forums, but that's a project in and of itself...)
The technical side has been discussed far more here already, and I don't believe I'm adding anything new with my suggestions. However, I am going to sum them up in a way that hopefully prevents some of the taking past each other that I've witnessed above.
This has been widely discussed, and I think it's a good idea. I would like to address some concerns related to it, though. As has already been pointed out, there is a process for reviewing classic confinement snaps, and as it happens, gh
fits quite clearly into one of the supported categories. Specifically, "tools for local, non-root user driven configuration of/switching to development workspaces/environments". In general, most development tools packaged in snap use classic confinement. One of the most comparable applications already packaged as a snap is GitKraken. The snapcraft site already tells the user to use --classic
, and if the user just tries to run it from a terminal they have the following interaction:
lengau@hyperion:~/Projects/cli$ gitkraken
Command 'gitkraken' not found, but can be installed with:
sudo snap install gitkraken
lengau@hyperion:~/Projects/cli$ sudo snap install gitkraken
[sudo] password for lengau:
error: This revision of snap "gitkraken" was published using classic confinement and thus may
perform arbitrary system changes outside of the security sandbox that snaps are usually
confined to, which may put your system at risk.
If you understand and want to proceed repeat the command including --classic.
lengau@hyperion:~/Projects/cli$ sudo snap install gitkraken --classic
gitkraken 9.0.0 from gitkraken✓ installed
lengau@hyperion:~/Projects/cli$
It's fair to criticise the UX of having to enter a second command (and I've filed a bug report to that effect), this is unrelated to the topic here. The point of this demo is to assuage any concerns that this would allow a weird situation of the package being installed with strict confinement when it's intended to have classic confinement and breaking in weird and wonderful ways.
This will also have some additional benefits that strictly-confined snaps don't get. For example, #32 wouldn't be an issue since we could use the system version of git, just as gitkraken, the various JetBrains IDEs, VSCode, and I'm sure many of the other development tools published as snaps do.
This is related to the social suggestion of using snapcrafters - rather than requiring manual work for each release to be published as a snap, using the tools that Snapcrafters have created can automate much of the process.
This should be minimal (possibly zero with classic confinement), but upstream accepting PRs for certain error checks to upstream could help to avoid these errors. (For example, if git errors out due to inability to access SSH keys, going into an "is this snap-related" check and returning a more useful message would help prevent some support requests.)
I'd love to help with this, but I believe the people from whom we'd need buy-in include both @casperdcl (who currently owns the snap package) and either @mislav or someone else on the upstream team who's willing to accept pull requests related to these suggested changes. If we can get agreement, I think we can improve the situation here for everyone.
Sounds reasonable to me
@lengau I would be happy to accept upstream fixes that improve user experience.
Thanks @lengau! I'd suggest:
classic
requestwdyt?
Thanks @casperdcl , that sounds great! I've emailed you from my personal email address, which is attached to my snapcraft account. Once you've added me I can take the next steps.
Keeping-in-the-loop type update: I've finally got around to filing the classic confinement request. I'll keep tracking it, but I may need @casperdcl to "make an appearance" in the thread, if you will, to confirm that everything is above board.
I also plan to make a nuke-and-pave style PR in the next few hours for this repo to match my one. I've been using the releases I published with no issue other than the inconvenience of manually downloading/installing the snaps, so I'm hopeful this will be pretty straightforward.
Looks like the --classic
request was granted :)
gh pr checkout 160
01818026488
thanks a lot at least i was able to snap remove gh
it gave me headache
Thanks @lengau @casperdcl for taking steps to make the gh snap better. I've renamed this issue as it became clear that the snap will be improved by changing the confinement type instead of unpublished.
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: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. https://github.com/cli/cli/issues/328