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).

[jonbirge]

@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.

[mislav]

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.

[jonbirge]

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.

[hackel]

@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.

[jonbirge]

@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.

[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.

@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.

[jonbirge]

@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.

[jyaif]

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

[mislav]

@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! 🙇

[charlesritchea]

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 <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMUMHKSZJV6X24HYRNQXITVTFXDBANCNFSM5AYACA5Q> . You are receiving this because you commented.Message ID: ***@***.***>

[mislav]

@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]

@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

[salim-b]

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.

[hsoonslami]

يعطي 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

[lengau]

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.

Summary

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.

My opinion

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:

1. The upstream authors don't want to be bothered by issues related to the snap packaging. (Or, to be more general, don't want to be bothered by issues specific to any unofficial packages. I'm sure if the Arch package had issues that caused an influx of issues, they'd make a similar plea on the Arch forums.)
2. Many users (myself included) would prefer to have the application available via snap.

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.

Proposal

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.

Social side

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:

1. Modify the bug report template to direct users of third-party packages to those packages' bug reporting systems to check for known issues.
2. Add configurations to report third-party packaging-related bugs.

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...)

Technical side

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.

Repackage with classic confinement.

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.

Depend more directly on upstream's releases

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.

Integrate any necessary snap-related error checking upstream.

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.)

Conclusion

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.

[casperdcl]

Sounds reasonable to me

[mislav]

@lengau I would be happy to accept upstream fixes that improve user experience.

[lengau]

In light of recent conversation and the fact that upstream don't have any interest in maintaining the snap package, I did some of my own exploration and ended up creating [my own version of the `gh` snap packaging](https://github.com/lengau/gh-snap). While it is heavily based on the work in this repository, my version uses a fairly different approach:

1. For regular releases and prereleases, it depends directly on the upstream tarballs containing the statically linked binary.
2. These releases are automated with a scheduled GitHub Actions task
3. The snap is classic-confined

Some other differences include:

• The summary explicitly notes that it is an unofficial package
• The snap is based on the bare base snap and doesn't contain anything other than the binary, the LICENSE file, bash completion, and snap metadata. Everything else depends on the packages available on the host machine.
• The repository includes nightly builds built from source. I included these to provide a demo of how the snap build could be integrated into the existing goreleaser build using the Goreleaser snapcraft plugin.

In my testing, the classic confinement does indeed resolve most of the issues discussed. Additionally, by relying on a combination of classic confinement and the official builds, the snaps built with my method should behave indistinguishably from the upstream releases if they were installed in /snap/bin/gh.

@casperdcl: If you'd be willing, I'd like to work towards turning the package I've made into the version published as gh in the Snap store. If you'd still like to retain ownership of the snap I'd be happy to work with you on how to migrate. Otherwise, I would be happy to take ownership with the eventual goal of shifting ownership to snapcrafters.

The steps that will need to happen to get the gh snap published with classic confinement are:

1. A collaborator on the snap will need to file a store-request for the gh snap. (If you don't want to do that, I'd be willing to do so if you make me a collaborator.)
2. Once classic confinement is enabled, modify the nightly release workflow to publish the nightly build to the edge channel
3. Modify the [upstream release workflow] to publish prereleases to the beta channel and full releases to the candidate channel
4. Test a candidate channel release and push it to stable.

After this, I would like to work towards integrating the snapcrafters tools for promoting to stable and hopefully move this snap into the safe hands of the snapcrafters team.

While Snapcrafters do seem to hope that upstream will eventually take ownership of each of their snaps, it's not unusual for snapcrafters to publish snaps of software whose upstream authors are either unwilling or unable to maintain the snap version, so I don't believe it upstream's unwillingness to maintain a snap build would be an issue.

Hopefully this can resolve the issues here to everyone's satisfaction. If so, I'd love to take the next steps.

[casperdcl]

Thanks @lengau! I'd suggest:

1. I add you as collaborator on the snap - I'd need your snapcraft email. If you don't want to post it here, you can contact me using the email on my GH profile :)
2. You file a classic request
3. You open PR(s) on https://github.com/casperdcl/cli
4. I add you as maintainer on https://github.com/casperdcl/cli
5. Hopefully at some point this repo gets transferred to https://github.com/snapcrafters

wdyt?

[lengau]

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.

[lengau]

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.

[casperdcl]

Looks like the --classic request was granted :)

[mdarifurrohoman]

gh pr checkout 160

[mdarifurrohoman]

01818026488

[dutkulang]

thanks a lot at least i was able to snap remove gh it gave me headache

[mislav]

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.