On Friday 10 June 2016 10:00:45 Hans Vanpee wrote: > Tobias Ellinghaus <me@...> writes: > > Wrong. darktable uses whatever it's configured to use. > > True. It is the automatic selection that goes to kwallet for KDE and > libsecret for the other desktops. Does KDE come with kwallet by default and > is libsecret an option? Libsecret is a Gnome project so I suppose it is well > integrated with the Gnome desktop.
Actually it's a freedesktop.org project, not Gnome. https://standards.freedesktop.org/secret-service/ even says that it's a joint effort of Gnome Keyring and KWallet developers. That being said, it seems that KDE's KSecretService isn't done yet, even though reports of it working are over a year old. > > Libsecret itself doesn't store any passwords. It's just an abstraction so > > that > > > applications (like dt) only need to talk to one service. In the background > > the > > > secret service is supposed to hand the data to Gnome Keyring, Kwallet or > > others. So eventually only libsecret should be needed to make everyone > > happy. > Correct. In my first patch I used gnome-keyring specific standards > (libsecret rreplaces libgnome-keyring but it can use gnome-keyring as a > secret service). Yes, Gnome Keyring as a backend to the SecretService API is still used, as a library it's deprecated though. We used to support it directly in the past, but that is no longer possible. > > However, until now I didn't find any way to actually configure what > > backend > > should be used. Or to determine which is used. > > secret_service_get_sync() gets a proxy for "the" secret service. Does this > mean that only one secret service can run at the same time? Or is there a > mechanism to select one of several as default? 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. > 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? :-/ > dived in this stuff because I was frustrated with redefining my connections > every day. I understand that and I agree that it should be fixed somehow. [...] > > 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. > > I fully agree. > The two problems I found in backend_libsecret.c are: > - searching for the existing "darktable" keyring returned the first keyring > found (due to the g_strcmp0() interpretation bug) 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. > I do use the > default keyring if one exists, but that can be changed very easily. I'd still prefer to keep things nicely separated in the "darktable" collection in all cases. > Could you try the patch on your system? I am interested to know if it solves > the problem in other environments than Gnome-desktop/gnome-keyring? I will try to find some time in the next few days to play with this. > Hans Tobias
signature.asc
Description: This is a digitally signed message part.
