master password gsoc project

[Vivien Bernet-Rollande]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi everyone.
I'm the student that will be working on the "master password" project
this summer.
I don't have lots of time these days, as I have midterms this week and
next week. But I'm doing a break today, and spend some of it thinking
about my project.

I've been contacted by C. Shaun Wagner, who's a student at the
Missouri University of Science and Technology last week. He has some
code that allows users to encrypt passwords in KWallet or using
Windows CryptoAPI. His project is hosted here :
http://kainaw.com/libpurple/

The code is actually a plugin (well, two, one for windows, and one for
KDE) that, when started, will decrypt all passwords and store it in
memory using purple_account_set_password(). It also offers the ability
to encrypt all the passwords in the xml file, and put them all back
(in case we don't want to use the plugins anymore).

It's pretty nice, pretty simple, but lacks a few things. For example,
when one creates a new account and remembers the password, he'll have
to ask the plugin to encrypt the passwords again. The plugin will then
go fetch the password, encrypt it, and set it as not remembering the
password.

The windows version works a little differently. It uses windows'
CryptProtectData() and CryptUnprotectData() functions to encrypt
passwords, and then stores them in an another xml file. I've learnt
however windows offers a service called "Protected Storage", which
allows, well... password and key storage.

All this code is under GPL, so I'll most likely re-use at least part
of it. I don't know what GPL-specific issues will arise there, but i
am confident GPL is about free software so it shouldn't be hard to get
that working.

A few words now about the project itself.
I'm going to outline the way I see it, I'd like feedback, ideas,
comment on this. I prefer doing this as soon as possible so I can fix
possible issues before encountering them, and particularly, before I
realise I have to rewrite the whole code because I got something wrong
or forgot something.

So. The goals are the following :
 - clean layering
 - secure memory handling
 - changes to libpurple should be as few as possible, as much code as
possible should be in a plugin, at least for the first version

The project will therefore have three layers :
 - a few patches to libpurple
 - a pidgin plugin for configuration and more
 - safe-specific plugins

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
 - either add something to account managment to mark passwords as
"remembered but managed by a plugin", or use another signal to ask if
the password is stored somewhere ( in
purple_account_get_remember_password() )
Those are the bare minimum I can see for now. It allows to build a
plugin that will be called whenever passwords are to be manipulated.

Then we have the plugin itself. It will be interface-dependent, and
will basically connect to the signals, and serve as an interface for
safe-specific plugins. It will also provide a configuration interface,
allowing to select the safe-specific plugin to use. Among other
things, it must be able to handle passing from one configuration to
another. It must also be general enough to allow safe-specific plugins
to be as powerful as possible.

Communication between the master plugin will work the following way :
 - when loaded, the safe-specific plugin tests if the presence of the
master plugin. I'm not sure how to handle loading of plugins in
incorrect order. Or rather, I'm not sure how to handle it in a clean
way. If all is OK, it calls a function of the master plugin to
register. This call will give the master the different callbacks to
use, as well the options that can be used. Therefore communication
will be done mainly through those callbacks. Functions that should be
registered will be :
 - connect to safe
 - disconnect
 - test connection to safe
 - list available accounts (maybe)
 - get password
 - store password
 - test if a password is known (for
purple_account_get_remember_password() )

I think that's pretty much most of it. Please point me to anything
important I might have forgotten.

- --    Vivien
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFII4wB30k75O5OLaURAkNfAKCUzYo2aaDUIr27Md3ohonv0bLQNACeOdeq
cHTTU4rYTjVxKOVYQKfBVoE=
=TTJp
-----END PGP SIGNATURE-----