AppArmor policy error accessing password manager about desktop HOT 16 CLOSED

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:

from desktop.

@bb441db It works!

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

from desktop.

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'

from desktop.

See #68

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

from desktop.

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

from desktop.

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.

from desktop.

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

from desktop.

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

from desktop.

I have not been able to replicate this issue. The snap is working just fine for me (although - perhaps it is because I already had my credentials saved? Not sure...) with logging into GitHub.

from desktop.

Now that this is done, there's another problem.

Cloning into '/home/nato/Documents/GitHub/FirstRun'...
/snap/github-desktop/35/opt/GitHubDesktop/resources/app/git/libexec/git-core/git-remote-https: error while loading shared libraries: libcurl.so.4: cannot open shared object file: No such file or directory

Should I open a separate issue for this?

from desktop.

I believe this is being tracked at desktop/dugite-native#109 :-)

(oops, probably not; don't think it's relevant to the snap build?)

from desktop.

Thanks!

Wow, issues are being tracked at so many places at once x)

from desktop.

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. 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 am unsure how the snapcraft store works in terms of publishing updates since I believe there was a couple months between this release and the last release, whereas there has been extremely frequent releases on this fork.

from desktop.

Just updated to snap store version and encountered this error.

I would suggest including the connect instruction in the error message, people tends to ignore the install guide (I did). And maybe include an opt-out choice (instead of "close") as well.

from desktop.

I would suggest including the connect instruction in the error message, people tends to ignore the install guide (I did).

We already have a similar scenario here about the Keychain access:

If someone wants to try making a similar isAppArmorError(e) function here to make the error message friendlier I'd be happy to work with them on reviewing and merging the change.

from desktop.

it's clear all the intentions of this data

from desktop.