Thursday, July 16. 2009
fd.o secret storage project
Comments
Display comments as
(Linear | Threaded)
Very nice! Looking forward to only having to unlock only one storage system to access my passwords.
Hi,
Am I right that there will still be two backend implementations?
Have you considered one service, with just different UIs for managing it?
While a shared protocol would allow you to run GNOME apps in a KDE session more easily (which is great), you still have difficulty if you switch sessions with the same app.
If the suggestion is just to run one of the keyrings in both sessions, then why not do that for everyone?
Thanks,
James
Am I right that there will still be two backend implementations?
Have you considered one service, with just different UIs for managing it?
While a shared protocol would allow you to run GNOME apps in a KDE session more easily (which is great), you still have difficulty if you switch sessions with the same app.
If the suggestion is just to run one of the keyrings in both sessions, then why not do that for everyone?
Thanks,
James
That's actually not quite settled yet. Of course GNOME will keep using Keyring. KDE might switch to Keyring as well or keep its own daemon based on several factors.
Keyring currently still has some GNOME library dependencies (which shouldn't be too hard to get rid of). Furthermore there's stuff like the authorization dialog (that's currently gtk-only as well).
Keyring currently still has some GNOME library dependencies (which shouldn't be too hard to get rid of). Furthermore there's stuff like the authorization dialog (that's currently gtk-only as well).
That's clearly a great idea, I wish you guys will be successful at it, more so if you manage to persuade Mozilla to join in !
We need more of this kind of initiatives to bring the different environments together while keeping their originality.
Cheers !
We need more of this kind of initiatives to bring the different environments together while keeping their originality.
Cheers !
AFAIK firefox already has under the hood infrastructure for gnome-keyring.
implementing it would be possible. and let's not forget that firefox is an opensource project, so patches welcome.
implementing it would be possible. and let's not forget that firefox is an opensource project, so patches welcome.
This is probably a good step forward, I hope that my wish comes true and also mozilla comes into the process so I can manage passwords with the keyring of my choice.
Another note: please keep it as platform independent as possible, as this issue is problematic on Windows (at least) too.
Thanks, and good luck.
Another note: please keep it as platform independent as possible, as this issue is problematic on Windows (at least) too.
Thanks, and good luck.
Bah.. just realized gmail sent all of the comments to my SPAM folder.
Yeah, I'll keep an eye on multi-platform.
Yeah, I'll keep an eye on multi-platform.
This is really good news! I am really looking forward to hear more about it.
Now if knetworkmanager-applet and the gnome networkmanager would use the same wallet (even though through different code), they could now share passwords. That's really cool
Now if knetworkmanager-applet and the gnome networkmanager would use the same wallet (even though through different code), they could now share passwords. That's really cool
Yeah, though there's more to it. What we're currently working on is providing a service any application can connect to using a common protocol.
Afterwards we (or the applications providing similar services) will have to agree on a way to label and store those passwords so they can be commonly used.
While that's not something for every type of password (I wouldn't want Evolution to use my KMail password) it makes sense for some, eg. Web passwords, Web form data and WiFi authentication (didn't even think of the last item before - thanks for bringing it up!).
Afterwards we (or the applications providing similar services) will have to agree on a way to label and store those passwords so they can be commonly used.
While that's not something for every type of password (I wouldn't want Evolution to use my KMail password) it makes sense for some, eg. Web passwords, Web form data and WiFi authentication (didn't even think of the last item before - thanks for bringing it up!).
I'm hoping for thorough research, like reading this: http://plan9.bell-labs.com/sys/doc/auth.html
What about providing support for systemwide storage of passwords in the API?
I think in some places this might come really handy like passwords for systemwide NetworkManager connections etc.
So you could run a systemwide daemon which takes care of storing these systemwide passwords but it could also provide the containers for the single users.
Regards, Elias P.
I think in some places this might come really handy like passwords for systemwide NetworkManager connections etc.
So you could run a systemwide daemon which takes care of storing these systemwide passwords but it could also provide the containers for the single users.
Regards, Elias P.
Certainly something to keep on the radar, but it's probably not going to be in our first version of the spec.
We're currently mostly concerned with designing a cross-desktop interface for functionality we already have. If we succeed, something like "make available to all users" might not be out of scope though
We're currently mostly concerned with designing a cross-desktop interface for functionality we already have. If we succeed, something like "make available to all users" might not be out of scope though
actually all i want is that when i login that kwallet is already open (kdm kwallet integration)
Yes, SSO-Support (Single Sign On) would be great - but I don't know how this could be implementend in a sane cross-platform compatible way - PAM is only available on POSIX platforms, but not on Windows. Maybe ConsoleKit is helpful here?
Great, as someone who moved from KDE to Gnome, have to say that KWallet was one of the things I miss most. And bringing all the data I had in kwallet was a pain.
Please make sure you address the need of the user being able to poke a user name and password (and some notes) in there for later use, I have heaps of applications that will never use the API (sigh...) so just need a way to store things safely. Gnome keyring is (AFAIK) hidden from the user. There are some standalone apps to do this but none as elegant as KWallet.
David
Please make sure you address the need of the user being able to poke a user name and password (and some notes) in there for later use, I have heaps of applications that will never use the API (sigh...) so just need a way to store things safely. Gnome keyring is (AFAIK) hidden from the user. There are some standalone apps to do this but none as elegant as KWallet.
David
Yes we are (and I really wish LWN would quit it with the "Mozilla doesn't care about Linux" nonsense, we have a great relationship with all kinds of OSS projects).
For a new login storage backend to be implemented in Mozilla, it must implement this interface:
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/passwordmgr/public/nsILoginManagerStorage.idl
(Forget about initWithFile).
If you could consider this as you write the spec, this could significantly reduce the time needed for us to integrate.
For a new login storage backend to be implemented in Mozilla, it must implement this interface:
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/passwordmgr/public/nsILoginManagerStorage.idl
(Forget about initWithFile).
If you could consider this as you write the spec, this could significantly reduce the time needed for us to integrate.
It seems quite possible to integrate that as most methods of the interface match what we are doing.
The only thing I'm unsure about is the process of "unlocking" secrets and negotiating the session. I wonder if this is possible on-demand eg. when getAllLogins is called as we'll have to wait for the server's reply. A cheap workaround might be to unlock the respective collection on opening FF.
The only thing I'm unsure about is the process of "unlocking" secrets and negotiating the session. I wonder if this is possible on-demand eg. when getAllLogins is called as we'll have to wait for the server's reply. A cheap workaround might be to unlock the respective collection on opening FF.
Very interesting initiative. I recently found the Firefox plugin "KDE Wallet password integration", which addresses some of the concerns here. Between it and ksshaskpass, I've been able to merge almost everything into my KWallet.
Calendar
|
September '10 | |||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | |||
Tracked: Jul 16, 20:44
Tracked: Jul 16, 23:48
Tracked: Jul 17, 00:42
Tracked: Jul 25, 23:22
Tracked: Jul 25, 23:23