On Thursday 09 June 2016 06:14:14 Hans Vanpee wrote: > Tobias Ellinghaus <me@...> writes: > > Reading the libsecret docs I couldn't find any way to tell it to create a > > non- > > > session collection. But that seems to be in line with the rest of that > > library/system, it is hardly documented at all. It's also not obvious to > > me > > how to actually configure the backend used to store the secrets passed to > > the > > > service. > > > > So if you found a way to make the collection permanent I am interested. If > > your patch is merely renaming the collection to "Login" then we can't > > accept > > > that patch as it wouldn't fix anything. > > > > Tobias > > Hi Tobias, > > Indeed, the libsecret documentation isn't detailed enough and I needed some > guesswork and trial and error to find a solution. It works but I am still > not 100% sure that this is the way to go. > > Anyway, the "Login" collection unlocks automatically and most applications > (like Google Chrome, etc) store their passwords in this place. I did try to > make a new collection using libsecret but it didn't work. We would need to > password protect this collection (or leave passwords un-encrypted) so some > GUI work would be involved. "Login" is already there and it does all the > work for us :-)
Unless you provide a link to the specifications that guarantee that "Login" exists that would be no better than using "darktable" I fear. :-( > What happens in backend_libsecret.c's dt_pw_storage_libsecret_new() > function? It first checks if a "darktable" collection already exists by > iterating over existing collections and it uses g_strcmp0 to compare each > label with "darktable" (line 87). The surprise is that this function > returns 0 when both strings are equal but the if-statement expects TRUE > when they are equal. As a result the first non-darktable collection is > selected from the list. This happens to be the "session" collection (it has > no label). And now we are storing all credentials in "session", thinking > they go to "darktable". Oh, good catch. I wonder why no one found that bug earlier. Thank you very much. I will have a look and fix that at least. > I added a constant for the "Login" string and changed the logic for finding See above, it's not a fix, just a band aid hiding the problem for you (and maybe others, we don't know that). > the collection. I use g_list_foreach with a callback to iterate over the > collections list because this seems to be better in line with GLib standards > and it doesn't rely on the underlying struct details. > > I'll try to get the patch to you somehow. Tobias
signature.asc
Description: This is a digitally signed message part.
