On 18.03.2013 13:50, Alberto Mardegan wrote: > Hi all! > I'd like to discuss about our plans for a password/secret storage > service which could be used by applications to store and retrieve secret > data. > > On the desktop, we are currently using the GNOME keyring, which we > cannot use as-is on UbuntuTouch given its dependency on Gtk+. The GNOME > keyring itself implements part of the "Secret Service" freedesktop.org > API [0], which AFAIK is also implemented by KDE's KWallet. > > Whatever solution we choose, I'd recommend to expose an API compatible > with the freedesktop.org's one; it might not be exactly what we need, > but on the other hand I don't see a strong reason to do things differently. >
Having had a brief look at the API only, but the first question that comes to my mind is whether the X-centric approach of tying authentication dialogs to window IDs is feasible. I think we should rather focus on the application-instance centric approach that we are implementing for the rest of the system. What are your thoughts on this aspect? > That said, the next question is what we want to use; given that the > "Secrets Service" API is not terribly complicated, and that the GNOME > keyring is tied to Gtk+, I don't think that the effort of extracting and > reusing the non-Gtk+ parts of the GNOME keyring is worth it. > > Someone suggested that we could implement the freedesktop API inside the > signond daemon, which is at the core of Online Accounts; given that the > daemon is easily extensible (it already provides an extension API for > plugins), it might not be a bad idea, considering also that signond will > be one of the main users of this API (it needs it to store account > passwords and authentication tokens). > However, while not being against the idea, I'd like to give it some more > though before pushing it forward. > > Another question is how the secrets DB should be stored. In MeeGo we > were using the SIM "Run GSM algorithm" [1] to obtain a byte array which > would be unique to the user's SIM, and use that as a LUKS key to decrypt > the secrets storage which was mounted in its own loop partition. > So the plan was to disable the password storage when the SIM was removed > or deactivated. > At the end we had to disable this feature because of problems with the > SIM service (which from time to time reported that the SIM was being > removed while in fact it was still there), but the infrastructure was > all in place -- and as far as Online Accounts is concerned this is still > usable, since we took off from the MeeGo code. Only the SIM interface > needs to be re-written for oFono (provided that it can offer the same > functionality). > > Anyway, regardless of what the access key is (whether it's the SIM or > anything else, like a lock code or screen gesture), it might be a good > idea to consider the possibility of having the secrets storage being > made unavailable when some conditions are not met. > > +1! > So, those above are a few aspects to consider. There are many ways to > implement the secrets DB, and if you think you have more ideas, you are > very welcome to list them here. > I'm bringing up this discussion because this service is essential for > Online Accounts (right now on UbuntuTouch our password database is not > encrypted), and if there's something I can do to get this done, > including writing code, I'd be happy to help. > Consider this e-mail as me volunteering for this task -- but first we > need to decide how to do it. :-) > > Ciao, > Alberto > > [0]: http://standards.freedesktop.org/secret-service/ > [1]: > http://en.wikipedia.org/wiki/Subscriber_identity_module#Authentication_key_.28Ki.29 > -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
