On 17 apr 2012, at 21:26, "C. Michael Pilato" <cmpil...@collab.net> wrote:
> On 04/16/2012 09:53 PM, Thomas Åkesson wrote: > >> I would like to see a non-graphical implementation of the Secret Service >> API with a solid CLI. That would merit a project in itself, separate from >> Subversion (e.g. Apache Keywhatever). It seems like Dbus can be used >> either with a daemon or more light-weight with just libdbus. Are there >> any OS with pressing need for Subversion password storage that does not >> have libdbus? > > I'm not aware of any -- I mean, I assume the *BSDs all have libdbus support. > >> Alternatively, if there is a determination to implement encrypted storage >> within the Subversion project, how about basing that "module" on the >> Secret Service API, with or without libdbus? >> - All Subversion's requests for secrets done with the same API, >> untangling the code. >> - Internally stored secrets are just returned by the module >> (non-graphical POSIX-systems and potentially Windows). >> - Secrets stored in Gnome Keyring/Kwallet are requested using their >> Secret Service implementation, which is simply relaying the API calls. >> - Keychain is wrapped by the module. Not sure how difficult it is to map >> Keychain and the Secret Service API, but it would be a bit surprising if >> it turns out to be impossible. > > In theory, I'm okay with this. Where is Secret Service today in terms of > implementation, real-world usage, etc? I did some more digging into the Secret Service API: - Supposedly supported by KWallet in KDE 4.8, no definitive reports. http://arstechnica.com/business/news/2012/01/kde-48-released-with-qml-bits-and-new-password-framework.ars - Gnome seems a bit ahead and should use Secret Service since 3.0. Seems like the Keyring API was not far off. http://stef.thewalter.net/2010/05/gnome-keyring-230.html In terms of real-world usage there is no getting around that it is in early stages. After this round of digging I have to say it is likely too early to enable an efficient implementation process. Bugger. Perhaps the most pragmatic thing to do at this point is just staying as close to the Secret Service API as possible when designing new interfaces, like prompt callbacks (while untangling the current authn code). Doing so should minimise the effort to maintain the Keyring and Kwallet integrations going forward and make a future move to a (then) well-tested Secret Service API less painful. > Are you volunteering to join the coding effort? Erm... those C skills of mine are not that impressive, really. I should just shut up and focus on the Unicode specification work. Hope that will become useful, and implemented, at some point. /Thomas Å.
