Tobias Ellinghaus <me@...> writes: > From what I understand there should only be one Secret Service, which in turn > uses one backend (like Gnome Keyring or KWallet/KSecretService) to do the > actual work. Exactly what I thought. That's why secret_service_get_sync works without specifying a service.
> > This is all new to me and I > > Even though I have looked into that for years now (storing passwords was one > of the first contributions I did in darktable) I am still not sure about many > things and can't manage to find any documentations. > Did I already mention that? :-/ Documentation is rather poor and libsecret is relatively new and unstable. > > > Directly talking to kwallet works like a charm. But that is not the issue > > we are having. The problem is that libsecret isn't working as intended. And > > limiting its use to environments where Gnome Keyring is used in the back > > is not acceptable as it's intended to work across different DEs. Another option is to use libsecret with Gnome Keyring and use Kwallet directly. It would make pwstorage somewhat heavier but at least it should work for everybody. > I'll fix that once we have the rest in place. Only fixing that issue while the > subsequent creation of the "darktable" collection fails is IMO even worse as > that will fail and thus darktable won't even try to store any password anymore > in the future. Unless the user notices it and sets the configuration option > again. So having the password in the session is less bad I guess. > > > - using "darktable" as an alias when creating a new keyring. Libsecret seems > > to support only the "default" alias (that is what the error message says > > when trying another value). Changing the user's default to darktable would > > be bad behavior, so I use no alias at all in my second patch. > > Right, I never saw a hint that creating other aliases wasn't possible (why is > there an API for it in the first place?) or what the aliases are used for, but > if it works without one I won't complain. As said before, documentation isn't clear at all. I found this after trying to create a darktable collection with a darktable alias and reading the error message after the call. It clearly states that "default" is the only alias supported for now. You could give it a try on KDE and see what happens. > I'd still prefer to keep things nicely separated in the "darktable" collection > in all cases. >From a user experience point of view, using "default" is more convenient: no new password needs to be created to protect the collection and locking/unlocking follows the same rules as all other applications. For users who don't want to fiddle with secret service settings this is the easiest solution. Of all the applications I use there isn't one that creates its own keyring, there must be a reason for that. Hans ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
