Tuba (mastodon client) fails to launch on Librem5 / gnome-keyring discussion

Trying to get the mastodon client Tuba (successor of Tootle) to work on my Librem5 I came across the issue that it would ask me for a to me unknown password to unlock some keyring or wouldn’t start at all.

If you’re bugged by the same problem you might find a solution in the issue on github.

If someone had the time - @guido.gunther confirmed on Matrix that Tuba tries to use the keyring marked as default in seahorse. There are open questions around this issue someone could look into and help improving the software. I’ll write them down on github.

Edit: corrected issues link - thanks @wimdows

I do not have the same problem. I installed Tuba yesterday and it works as it should.
If you have installed the Keyring app (Seahorse). You have two passwords for two keyrings. The password Tuba asks for, is the same as the one I use to unlock the phone. (Not the disk encryption one.) I remember the Seahorse installation as being a bit ‘murky’. Only afterward I realized I had to set two different passwords for it: a ‘default’ one (which is used when I start up Geary), and a ‘login’ one (which is the one Tuba asks for).
The latter one in my case happens to be the same as the one I use to unlock the phone. I must have set the login password myself, but I don’t remember doing so.
So, my question to you would be do you remember setting two passwords for Seahorse?

If I double click the login password in Seahorse, I see a list of apps that require the login password. I can delete these without having to type the particular password. Tuba is in this list. I have deleted entries from this list that went with apps I had uninstalled. But I haven’t tried what happens when I delete Tuba from the list.

By the way: if someone knows how to safely uninstall Seahorse, please tell me how. I find using a password safe a bit cumbersome. So, I am thinking of getting rid of it.

Oh, and your link leads to a 404…

1 Like

Only if there have been two keyrings created. Each keyring can have it’s individual password which protects the set of passwords stored in that keyring. The fact that you have two keyrings might be part of the reason why it worked for you (the additional questions I wrote about on github in the issue I mentioned).

I fooled a lot around with my Librem5 always trying to get it back to the standard settings. But that doesn’t always work out and sometimes one might think that a setting changed couldn’t influence other programs later, but nearly every time it does.

I remember deleting the password for a keyring, because I didn’t want to be asked for it every time after a restart and the first login to phosh. So I deleted it. In my case I guess there’s been another keyring that had a long forgotten password set. For some reason Tuba tried to use that keyring. After I deleted that old keyring (might have been migrated from my Pinephone running Mobian) Tuba refused to start at all.

Anyway, if you want to help to get to the root causes of the issue I mentioned you could look into the questions still open about it.

It is not seahorse that saves the passwords. It’s gnome-keyring-daemon on the Librem5. seahorse is just an application to let you look at the keyrings stored in gnome-keyring-daemon.

purism@pureos:~$ apt-cache rdepends `dpkg -S /usr/bin/gnome-keyring-daemon`
Reverse Depends:

If you’d remove gnome-keyring you’d break the above list of packages. You would risking that phosh (your graphical shell, gui) and gnome-sessions (the software starting up your graphical environment) wouldn’t work anymore.

BTW: Good that Tuba worked for you out-of-the-box. The message has been intended for other users possibly running into the same issue others and I ran into :slight_smile: .

I’m also unable to open Tuba. I just assumed no one else could either. I think the only other program I haven’t been able to open was pixel dungeon.

Well, I never used a password safe before, so I am not familiar with the inner workings. That I did not run into the problem you describe is mostly down to luck, I guess.

I do not think I set up more than one keyring - actually I am pretty sure of that. Seahorse only mentions one ‘Default keyring’ and a 'Login". The ‘Login’ entry contains passwords for Tuba and for the Authenticator app, and for the Default keyring. The Default keyring contains a password for Geary.
When I start up the phone, it asks for the encryption password, the unlock password, the sim pin, and for the default keyring password. This fits with the fact that I have Geary marked as a startup application.
When I run either Authenticator or Tuba, I have to enter the other password, the one that is stored as the login password. The dialog box does name this as a ‘login keyring’ and tells me that it did not get unlocked at start up.
A bit confusing, actually.

Mine still work install it through flatpak

If I delete the login keyring Tuba does not start up any longer. When I restore the keyring files , it works again.

I am also in the “2 keyrings, Tuba works” camp, with Tuba installed from Flathub. Other apps from Flathub also use the Login keyring.

1 Like

What I find weird, is that Geary keeps requesting a new keyring it calls “Default keyring” when I run it without an existing password in the safe.

So, the Login keyring already exists, and other apps (like Authenticator and Tuba) are happy to accept the password that goes with this keyring, but Geary wants to initiate its own keyring, and wants to call it ‘default’ - which it is not, because that would be the login keyring.

Who comes up with stuff like this?!

To state the bloody obvious: one keyring with one password should be enough.
Any advice for how to accomplish this is most welcome…

(Should this be in another thread? Or should this thread have had a different title to begin with?)

1 Like

the workaround is to add a keyring matching the name the app needs.

Tuba Flatpak - login.keyring

The app developer needs to fix it, Flatpak apps have been causing more issues than .deb apps from my experience.

1 Like

Ah! I think I know what happens with Geary wanting to create jts own keyring.

Both Authenticator and Tuba are assigned an encrypted(?) password, while Geary needs to send the man-made, unencrypted password for the smtp server.
Maybe they can’t be stored in the same keyring.
Could that be it?

I use Geary .deb version and there are no issues. It is using the keyring i created and set as default, and renamed. So maybe your experience is with the Geary Flatpak app?

I checked: it is the Geary version that came with the phone; it comes from the PureOs repository, not the flapak one.

Hey everyone,

I haven’t been able to reproduce it so this is pure speculation:
It sounds like this gnome-keyring bug; a fix for it landed on version 42.0.

This OS issue comment also seems related

I don’t think there’s anything I can do from my side, otherwise any pointers would be welcome!

There always is :wink: : You could add an error message that says why Tuba didn’t start and more debug messages for the console.

It has been somewhat painful to find it out using dbus-watch, wireshark and strace and there might be others who do not stumble over the github (btw, why github?) issue or over this thread.

The error message that shows up when it fails (user interaction failed) is the same both for when the keyring is not found (the original issue) AND for when the user selects “Cancel” when asked to provide the keyring password (with the exact same error code) (that’s probably the case for any other libsecret issues besides those two) making writing any helpful debug messages a bit hard. At the same time, I’d rather avoid asking users to delete keyrings as it could lead to potential data loss. Maybe something along the lines of:

“Error while searching for items in the secret service: user interaction failed”
“If you didn’t manually cancel it, try creating a password keyring named login using Passwords and Keys (seahorse) or KWalletManager”
“read more: <link to your issue comment or a wiki page>”

That sounds great! Thanks a lot - especially for making that fantastic client!

BTW: will or even does it speak the ActivityPub Client Protocol, also? Would be a great thing if it could be used one day for microblog.pub as well.

1 Like

Nope. I haven’t really gotten too deep into the spec (so take the following with a grain of salt), but my main pain points are

  • it shifts a lot of the work to the client
  • it’s limited/generic[1] - auth, permissions, media upload[2], streaming[3], notifications are not defined

[1]: which makes sense I guess, for example mobilizon has different needs than mastodon and peertube

“Servers MAY support uploading document types to be referenced in activites, such as images, video or other binary data, but the precise mechanism is out of scope for this version of ActivityPub. […]”
6.12 Uploading Media

[3]: streaming (websockets) is an important one for Tuba

I can open an issue for it, but don’t expect any progress unless the c2s spec gets more fleshed out