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.
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.
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.
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 .
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.
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?)
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?
There always is : 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>”
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
[2]:
“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
.
: You could add an error message that says why Tuba didn’t start and more debug messages for the console.