With the help of the Snapcraft team, I’ve now been able to publicize the app again on the Snapcraft store now the enclosures are migrated. It is recommended to install the beta channel currently if you are working from a fresh install.

For existing installs the edge channel will remain using the strict enclosure for the moment, and refreshing to the latest version there will ask you to install the beta channel, which is using the classic enclosure and requires a manual upgrade:

@bb441db It works!

sudo snap connect github-desktop:password-manager-service

Can you try running the following command and see if that fixes it? (assuming desktop is the snap’s name.)

sudo snap connect desktop:password-manager-service

See: https://forum.snapcraft.io/t/nextcloud-client-snap-app-armor-issue/4366/4

If this fixes it, we should add this to the snap.

plugs: 
  - 'password-manager-service'

For the moment I’m going to leave this open to address these three things:

• write some notes in the install guide for Snap to indicate the connect step is important here #93
• improve the error handling here to display a better error message
• investigate whether the app can request to connect (and potentially retry) to the password manager

@ipkpjersi I believe this is something that’s a security measure we’ve encountered - this document suggests that the permission we had for password-manager-service is not auto-connect, which means the user likely needs to connect the app to be able to read/write credentials.

This worked on my machine with the latest build: sudo snap connect github-desktop:password-manager-service - I was able to sign in fine after that.

I will admit I am a little sad to hear that this latest snap version on the snapcraft store has one or more regressions after the previous snap had other issues as well for me.

The previous Snap version had the “classic” confinement (which meant it wasn’t confined at all) so I’m not surprised it was much better. Releasing packages with this setting required approval from Snapcraft to do, and isn’t something they encourage. This version now uses the “strict” confinement, which is important for many reasons, but I suspect we’ll have some more tweaks to the config to get it working smoothly.

It’s not clear to me how to correlate errors like this to the right interfaces/plugs, so any pointers from those more experienced with Snap packaging would be greatly appreciated. cc @flexiondotorg

If this issue and #91 are fixed, is deploying an updated snap to the snapcraft store possible or does it take a long time to publish updates to there?

I can deploy to the Edge channel pretty in about an hour, and that’s what I’ve been working towards over the last few weeks in my spare time. The hold up has been around getting permissions to publish to the existing package in the store (this wasn’t started by me) but it was enabled in the last 24 hours.

Looks like I regressed this with the newest Snap on the store (1.5.0-linux5)

An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.145" (uid=1000 pid=4101 comm="/snap/github-desktop/37/app/github-desktop --type=" label="snap.github-desktop.github-desktop (enforce)") interface="org.freedesktop.Secret.Service" member="OpenSession" error name="(unset)" requested_reply="0" destination=":1.14" (uid=1000 pid=2562 comm="/usr/bin/gnome-keyring-daemon --daemonize --login " label="unconfined")

See https://github.com/shiftkey/desktop/issues/68

Should be fixed in a newer release, I don’t think it’s in the snapcraft repos yet.