Dev1 Galaxy Forum / secret-tool & gnome-keyring (Cannot spawn a message bus when setuid)

Re: secret-tool & gnome-keyring (Cannot spawn a message bus when setuid)

dummy@example.com (golinux) — Wed, 06 Oct 2021 07:27:29 +0000

gour . . . I did not write that.

My response is here a few posts up.

Re: secret-tool & gnome-keyring (Cannot spawn a message bus when setuid)

dummy@example.com (gour) — Wed, 06 Oct 2021 07:12:03 +0000

golinux wrote:

MXlinux has systemd installed, so i guess that's the reason it's working there.

It could be, although I didn't enable it.

Anyway, had some other issues - not being able to permanently set default sound device, Viber was restarting setup procedure after every reboot etc., so for the time being, I reverted back to Debian/Sid...

Re: secret-tool & gnome-keyring (Cannot spawn a message bus when setuid)

dummy@example.com (golinux) — Tue, 05 Oct 2021 16:43:28 +0000

MXlinux has systemd installed, so i guess that's the reason it's working there. it's probably working on antiX too, haven't tried it, but dbus-user-session is in antix repos without systemd dependency (with consolekit, not elogind).
I'm not sure whether systemd was installed on MXlinux...

It is available for installation. Or activation might be a better word:

https://mxlinux.org/wiki/system/systemd/

Re: secret-tool & gnome-keyring (Cannot spawn a message bus when setuid)

dummy@example.com (gour) — Tue, 05 Oct 2021 12:14:48 +0000

xinomilo wrote:

even though i use clear text password in /etc/msmtprc, i did try ~/.msmtprc with secret-tools and get the same error message..

Nice to not be alone. :-)

MXlinux has systemd installed, so i guess that's the reason it's working there. it's probably working on antiX too, haven't tried it, but dbus-user-session is in antix repos without systemd dependency (with consolekit, not elogind).

I'm not sure whether systemd was installed on MXlinux...

so i got no workaround for devuan, i'd only suggest the 2nd auth method (GPG). probably better than figuring out what wrong with dbus, glib, gnome-keyring, libsecret, etc...

Thank you for taking time...yes, I'll probably use pass...

Re: secret-tool & gnome-keyring (Cannot spawn a message bus when setuid)

dummy@example.com (xinomilo) — Tue, 05 Oct 2021 09:24:33 +0000

even though i use clear text password in /etc/msmtprc, i did try ~/.msmtprc with secret-tools and get the same error message..
reading the bug report, this seems pretty messed up...
debian dbus-user-session depends on systemd, not sure if it's coming to Devuan anytime soon (?). MXlinux has systemd installed, so i guess that's the reason it's working there. it's probably working on antiX too, haven't tried it, but dbus-user-session is in antix repos without systemd dependency (with consolekit, not elogind).

so i got no workaround for devuan, i'd only suggest the 2nd auth method (GPG). probably better than figuring out what wrong with dbus, glib, gnome-keyring, libsecret, etc...

secret-tool & gnome-keyring (Cannot spawn a message bus when setuid)

dummy@example.com (gour) — Mon, 04 Oct 2021 07:36:04 +0000

Hello,

just migrated my desktop machine to devuan/ceres after short usage of mylinux-21 (migrated from debian/sid) and I'm very pleased with the work done by the Devuan devs hoping to stick with it for a long time!

There is one problem I'm experiencing when msmtp tries to access password stored by libsecret from the gnome-keyring...

Hee is the output I get when trying to test email with msmtp:

$ echo "hello there" | msmtp -v -a default some-email@gmail.com
ignoring system configuration file /etc/msmtprc: No such file or directory
loaded user configuration file /home/user/.msmtprc
secret-tool: Cannot spawn a message bus when setuid
msmtp: cannot read output of 'secret-tool lookup user someuser'

However, just retrieving passwd from the store does work:

$ secret-tool lookup user someuser
paswdxyzsfsdfd

The bug is reported here and apparently fixed in version gnome-keyring/40.0-3, but there is problem due to missing dbususer-session package - see the comment, so wonder what is possible workaround besides using some other password-storing/retrieving mechanism?

Let me add that the same setup was working under MXlinux/sysvinit...