master password gsoc project

[Richard Laager]

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
exists.

Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://pidgin.im/pipermail/devel/attachments/20080509/9b1153bf/attachment.sig>