Neochat autoconnect requests

sgmoore · August 11, 2023, 12:35pm

Hello! I need the following autoconnects for neochat for it to properly function. It is our (KDE) matrix client.

network-manager-observe password-manager-service ( to fix a bug where you could only log in once and it would just hang when you tried to relaunch it https://bugs.kde.org/show_bug.cgi?id=473003 )

Thanks Scarlett

@Igor

kenvandine · August 11, 2023, 2:31pm

+1 for me on network-manager-observe

It looks like neochat uses libsecret, which now has more sandbox friendly support built in. I would expect this to work without access to the entire password-manager-service interface. Perhaps that can be investigated more, I know I was able to drop password-manager-service in some snaps with libsecret.

sgmoore · August 11, 2023, 2:55pm

Please see the bug report. I was unable to relaunch neochat ( it just hangs there ) Once I added the password-manager-service and connected it works and relaunch works as expected. Am I missing something on the “works out of the box with libsecret”? Because it doesn’t here.

ogra · August 11, 2023, 3:24pm

Have you checked with snappy-debug to see if there are actual denials when the hang happens? (Perhaps there is a less privileged interface that could help)

sgmoore · August 11, 2023, 3:33pm

Yes many org.freedesktop.Secrets.* denials. I have searched for an interface but I am not seeing one for libsecret. I am missing something here. Thanks all for your insight.

Scarlett

sgmoore · August 14, 2023, 1:04pm

Nevermind. I see what I need to do.

alexmurray · August 15, 2023, 2:08am

@sgmoore any chance you could quickly document what is required here? I imagine other snaps will want to use libsecret via the portal interface so it would be great to have that listed somewhere for others to find.

sgmoore · August 15, 2023, 11:39am

I would love to if I actually new what it is I am supposed to do. After looking at other snaps I thought it was as simple as adding a dbus slot. But that was just rejected by the store. You are right, it would be lovely to have it somewhere for others to find. I am currently still in the ‘others’ group I am afraid. I am off to dig further into portals, pretty sure we don’t have this right in our apps yet.

dclane · August 15, 2023, 1:05pm

Hi @sgmoore - my apologies on this one. I withdrew neochat’s ability to provide the dbus endpoint org.freedesktop.secrets after considering that it should be provided (at least on Ubuntu) by the gnome keyring. Perhaps @kenvandine you might have some advice regarding this?

sgmoore · August 16, 2023, 2:32pm

I am at a loss here.

desktop: usr/share/applications/org.kde.neochat.desktop
environement:
QT_QPA_PLATFORMTHEME: flatpak
QT_QPA_FLATPAK_PLATFORMTHEME: kde

is set, so portals should be working? yet upon relaunch it continues to hang. The output:

neochat(23940)/(quotient.e2ee) \[31munknown\[0m: Error loading pickling key - please fix your         keychain: "An AppArmor policy prevents this sender from sending this message to this recipient; type=\"method_call\", sender=\":1.78\" (uid=1000 pid=23940 comm=\"neochat \" label=\"snap.neochat.neochat (enforce)\") interface=\"org.freedesktop.Secret.Service\" member=\"OpenSession\" error name=\"(unset)\" requested_reply=\"0\" destination=\":1.39\" (uid=1000 pid=4830 comm=\"/usr/bin/kwalletd5 \" label=\"unconfined\")"

neochat(23940)/(quotient.e2ee) [31munknown[0m: Could not load or initialise a pickling key, will use a mock key for pickling neochat(23940)/(default) [31munknown[0m: qrc:/WelcomePage.qml:90:9: QML Connections: Detected function “onProcessed” in Connections element. This is probably intended to be a signal handler but no signal of the “Loading_QMLTYPE_307” target matches the name. neochat(23940)/(default) [31munknown[0m: qrc:/WelcomePage.qml:90:9: QML Connections: Detected function “onShowMessage” in Connections element. This is probably intended to be a signal handler but no signal of the “Loading_QMLTYPE_307” target matches the name. neochat(23940)/(default) [31munknown[0m: qrc:/WelcomePage.qml:86:17: Unable to assign [undefined] to QQuickAction* neochat(23940)/(default) [31munknown[0m: qrc:/WelcomePage.qml:84:17: Unable to assign [undefined] to bool neochat(23940)/(default) [31m[34munknown[0m: Save the access token to the keychain for “@sgmoore:kde.org” neochat(23940)/(default) [31munknown[0m: Could not save access token to the keychain: An AppArmor policy prevents this sender from sending this message to this recipient; type=“method_call”, sender=":1.80" (uid=1000 pid=23940 comm=“neochat " label=“snap.neochat.neochat (enforce)”) interface=“org.freedesktop.Secret.Service” member=“OpenSession” error name=”(unset)" requested_reply=“0” destination=":1.39" (uid=1000 pid=4830 comm="/usr/bin/kwalletd5 " label=“unconfined”) neochat(23940)/(default) [31munknown[0m: Couldn’t save access token neochat(23940)/(default) [31munknown[0m: Could not save access token to the keychain: An AppArmor policy prevents this sender from sending this message to this recipient; type=“method_call”, sender=":1.82" (uid=1000 pid=23940 comm=“neochat " label=“snap.neochat.neochat (enforce)”) interface=“org.freedesktop.Secret.Service” member=“OpenSession” error name=”(unset)" requested_reply=“0” destination=":1.39" (uid=1000 pid=4830 comm="/usr/bin/kwalletd5 " label=“unconfined”)

but when I connect password-manager-service everything works as expected. I am all ears for ideas. Thanks Scarlett

dclane · August 17, 2023, 6:12am

I’m not sure what correct portals based approach is (I also would love to know if anyone else is able to chime in), but I have looked at our historic position on password-manager-service and we have been quite consistent in not granting it an auto-connection; instead requesting that publishers advise users to snap connect <snap>:password-manager-service or use the Permissions feature of the Store GUI to accomplish the same thing.

The rationale is:

When connecting the password-manager-service, your snap is able to access all stored secrets, but also your snap’s secrets can be accessed by any other applications with access to the service (including snaps which also have the password-manager-service connected). Since this may not be desirable or obvious to users, in general, we discourage auto-connection of password-manager-service and instead suggest that applications using this interface detect its availability (eg, with snap is-connected password-manager-service) and show a dialog with instructions on how to connect the interface manually (eg, with snap connect, the snap store GUI, etc). Ideally when instructing the user, the details of the access will be explained so the user can make an informed choice. While this is an extra step for the user, if done well the process should provide additional trust that your snap and the system as a whole are working together to keep the user’s passwords secure. Alternatively, the snap may choose to store the secrets outside the keyring in an area private to the snap.

+1 for network-manager-observe
-1 for password-manager-service

sgmoore · August 17, 2023, 11:39am

I can agree with you on the password-manager-service point. I will go the dialog route. However, I really want to know why my ‘portals’ don’t seem to be working with libsecret. The documentation leads me to believe it should be working. It isn’t! I guess that is for another topic.

So for this thread, only network-manager-observe

Thanks, Scarlett