Fwd: Pidgin Password Patch

[Luke Schierer]

Some intro:

Shaun and I have exchanged a few emails here on a class project at his  
university.  The students in a computer security class would like to  
design a system to store passwords used in pidgin in a keychain.

In particular, they are looking at windows systems, but on my advise,  
they are looking at the gnome keychain as well.  They plan to submit  
their work as a patch or patches sometime this semester.  We have  
already discussed the fact that an implementation of password storage  
has to be able to handle the keyrings available on multiple platforms,  
as well as the absence of any available keyring.

Some limitations naturally apply, if you share a .purple directory  
between keyring and non-keyring systems, you might experience some  
funkyness, and if you use different keyring systems with the  
same .purple directory, you'll naturally have to store that password  
once on each system, and will potentially have issues if you ever  
change a password.  These are, I suspect, inevitable, but outside the  
scope of this email.

I'm not sure how best to answer this question, so I'm passing it on  
for further discussion.  My inclination is to think that this will be  
handled much the same way ssl is by libpurple, and that the specifics  
of windows or gnome keyrings will be in a plugin which interacts with  
generic libpurple bindings.  Does this seem reasonable?

luke

Begin forwarded message:

> From: CS Wagner <cs at kainaw.com>
> Date: January 24, 2008 11:31:05 EST
> To: Luke Schierer <lschiere at pidgin.im>
> Subject: Pidgin Password Patch
>
> A question came up in class that I feel you can answer very quickly...
>
> Does each implementation (ie, GTK) have its unique code for saving/ 
> loading passwords or is it in a central library (ie: libpurple)?
>
> The current assignment is to write a patch that can be added/removed  
> easily that will use any existing password management service that  
> is running on the computer.  I believe that is best because it  
> doesn't intrude on existing code.
>
> Thanks - Shaun
>