master password gsoc project
rlaager at wiktel.com
Fri May 9 15:16:55 EDT 2008
On Fri, 2008-05-09 at 01:25 +0200, Vivien Bernet-Rollande wrote:
> - secure memory handling
This one is going to be tricky to handle properly. And frankly, I'm not
sure it's that big of a deal. I would focus on other goals first.
> The modifications to libpurple would be :
> - register used signals on startup
> - when a pass is needed, emit signal, if no reply, use "normal" prompt
> - when a pass is stored, emit signal, get a return value, and if no
> one wants it, put it in xml
Using signals is one way to do it. Another would be to implement it like
logging (and our SSL support as well): The core would have pluggable
password storage back-ends. It would also provide one such back-end
(which would use plain-text in accounts.xml).
Gary, Sadrul, etc.: As far as GObjectification goes, would it be better
for this feature to use signals or a struct with function callbacks?
As you said, the user would set a default password utility. For existing
users, we'd default to the "Internal Plaintext" back-end. For new users,
we'd default to the appropriate one for their environment.
When the core needed a password, it would ask for it from their selected
back-end. When you need to save a password, you save it to the selected
back-end. To manage transitions, when the back-end preference is
changed, a dialog would come up asking if the user would like to copy
all their passwords to that back-end.
Your per-safe plugins would then be hidden plugins that would register a
back-end. Thus, a distro could compile Pidgin with both GNOME-Keyring
and KWallet support. But, at run-time, if you were in GNOME and didn't
have the kwallet library available, that plugin would just silently fail
to load (which is fine). Thus, you'd see only GNOME keyring.
I'd rather see the secure password storage stuff in libpurple rather
than as a plugin. Doing it in the core isn't really going to add that
much code -- just a thing abstraction layer over the code that already
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the Devel