KDE Utils/kwallet/FeaturePlan42: Difference between revisions
Line 32: | Line 32: | ||
=== Make sure passwords are saved === | === Make sure passwords are saved === | ||
This relates to Bug {{Bug|105752}}. We should come up with a way to store passwords before a session crashes. Of course shouldn't disturb the user (which is why I ([[User:Lemma|Lemma]]) don't like the timed solution proposed by a comment in this report). Complete rewrites of the kwl file should happen at points in time when the user is used to waiting (ie. opening the wallet after a crash, saving the session). | <s>This relates to Bug {{Bug|105752}}. We should come up with a way to store passwords before a session crashes. Of course shouldn't disturb the user (which is why I ([[User:Lemma|Lemma]]) don't like the timed solution proposed by a comment in this report). Complete rewrites of the kwl file should happen at points in time when the user is used to waiting (ie. opening the wallet after a crash, saving the session). | ||
General idea: On adding new passwords, append the encrypted password entries to the kwl file without rewriting it completely. If the session crashes the passwords are still here. The kwl file could be cleaned up upon reopening the wallet. As far as I know this might work. We'll see. | General idea: On adding new passwords, append the encrypted password entries to the kwl file without rewriting it completely. If the session crashes the passwords are still here. The kwl file could be cleaned up upon reopening the wallet. As far as I know this might work. We'll see.</s> | ||
This is already fixed and will be in 4.1. Benchmarking showed that syncing the wallet on every change (with a very small timer) is feasible. | |||
=== Overhaul the interface === | === Overhaul the interface === |
Revision as of 15:07, 14 June 2008
General ideas
Single signon
The user shouldn't have to enter his password twice (once for logging in, once for opening the default wallet). The main problem is that the wallet will still have to be password protected, so we need a way to transmit the password to the daemon.
Gnome keyring provide a hack (is it?) for this:
We could basically do something quite similar to this for kwallet:
- Extract the kwalletd to run standalone.
- Adapt/rewrite the gnome mini-pam module to start kwalletd and pipe the password to it using some sort of socket.
- This would probably have to be optional (default policy might be to NOT enable it and let the user choose the level of security he wants).
- It's important to consider security implications.
Sascha Peilicke will look into this matters and come up with a plan. This is a core issue so we'll have to discuss it on kcd.
Inter-desktop integration
Sascha proposed making kwallet/keyring cross-desktop so the user would need only a single authentication backend running. For this to work we'd either need a single API and multiple implementations or a common backend implementation - probably something for freedesktop.org. Coordinating that would take a hell lot of time so this is more or less a long-term goal. In the process we have to consider binary API compatibility.
It would also be nice to have software not tied to a desktop use this (ie. Firefox).
Make sure passwords are saved
This relates to Bug Bug #105752. We should come up with a way to store passwords before a session crashes. Of course shouldn't disturb the user (which is why I (Lemma) don't like the timed solution proposed by a comment in this report). Complete rewrites of the kwl file should happen at points in time when the user is used to waiting (ie. opening the wallet after a crash, saving the session).
General idea: On adding new passwords, append the encrypted password entries to the kwl file without rewriting it completely. If the session crashes the passwords are still here. The kwl file could be cleaned up upon reopening the wallet. As far as I know this might work. We'll see.
This is already fixed and will be in 4.1. Benchmarking showed that syncing the wallet on every change (with a very small timer) is feasible.
Overhaul the interface
The interface will have to be reworked. We were talking about:
- Overall goal:
- Make the manager a little shinier and a breeze to use
- Make it a program that eases managing personal account data rather than an editor for account data stored by various programs (yes, I know it already is, but the emphasis is on EASES :-)).
- Using model/view classes
- Improving usability (have a look at various bugreports concerning that)
- The current gui only provides basic undo support (you can only undo changes to a password/map that hasn't been saved yet). I think we could improve on that - it has to be "secure enough" though as I don't like the idea of having passwords stick around everywhere in memory.
- Maybe choose a one-window solution instead of the current two-window solution
- No need to reinvent the wheel, learn from what others have done, eg: