The master Password SoC project

[Mark Doliner]

On Sat, 22 Mar 2008 18:29:29 +0100, Vivien Bernet-Rollande wrote
> - modify existing 
> libpurple code to allow plugins to hook into password related manipulation.
> 	This means two things : first, add an interface that plugins can 
> call during startup to tell that they want to be asked when a 
> password is needed, and eventually be given new passwords to store. 
> This would probably be done by modifying existing plugin API code. 
> I'm not perfectly sure about that because the C Plugin howto is not 
> complete, so I'd probably have to read through the code to be sure. 
> It might also be possible to simply add a couple functions to 
> register password-related plugins, but reusing an existing interface 
> would make development of plugins easier. The general idea would be 
> to stay as close as possible to the existing plugin architecture.

It would probably be better to just use our signals API.  libpurple could emit
a signal for "password-requested," then your plugin could connect to the
signal and provide the password.

> - after that, write plugins themselves. It would probably be 
> interesting to merge the plugins for the most popular password safes 
> in a single plugin, so it would be more convenient for the user. 
> Once one plugin is written, the others should be quite similar, so 
> merging them would allow code re-use and faster development.

If the various safes depend on 3rd party libraries then it might be smart for
each one to be a separate plugin, so that users who want to use KWallet don't
need to have GNOME Keyring installed.

> - Finally, write a configuration interface for the plugin, so the 
> user can choose what password safes to get password from, where to 
> store them, etc.

I think before you start implementing this we would want to decide on where
the preferences should go for configuring this.  Either in a plugin, or in
Pidgin's normal Preferences dialog.

If done as a plugin, you could probably have a "Master Password" plugin that
lets the user choose one of the available safes and then loads the appropriate
plugin to use that safe.

If the preferences should go in Pidgin's preferences dialog then the list of
available safes would be present by Pidgin, and Pidgin would be responsible
for loading the appropriate plugin for that safe.

> Of course, once all this is done, there would be a testing phase,
>  making sure the plugin works with all supported protocols, as many 
> password safes as possible, and on all supported platforms. 
> Community feedback on the configuration interface will also be 
> important there.

It would be important to make sure things keep working even if the user stops
using the safe they had chosen.

> After that test phase, there would be the packaging 
> phase. This would mean building .rpm/.deb/.exe/other packages so 
> they are easy to install on different systems. And of course, making 
> sure they play well on different environments.

If this is done as a summer of code project then you could probably make your
changes directly in our source repository, and the plugins would be
distributed with Pidgin.  For any plugin that adds an external dependency it
should probably go into its own RPM or deb.  For Windows we generally include
everything the user needs in our installer, and we could probably chose one
safe to use and include support for that in the .exe that we distribute.

-Mark