The master Password SoC project

Vivien Bernet-Rollande vivien.bernet-rollande at etu.utc.fr
Sat Mar 22 13:29:29 EDT 2008


Hi everyone.

This is my first message on this mailing list, so I'll introduce myself first.
If you don't care about who I am, just jump to the 3rd paragraph. I'm Vivien,
from France (so please forgive any grammar or spelling mistakes). I'm currently
in my third year at the University of Technology of Compiegne. Personnal hobbies
and interests include coding and scripting (mainly C, C++ and bash, a bit of
Lisp, python and php/xhtml/css/javascript from time to time), security related
stuff (cryptography, exploitation techniques, reverse engineering), recycling
old hardware, playing with my OS (Ubuntu/Debian/OpenBSD, and sometimes others),
Roleplaying (D&D, Shadowrun, and a couple others), reading (Pratchett & Asimov
ftw !), hanging out with friends, and trying to convert people to Free Software
(because it's free as in speech, often free as in beer, fun, and works great),
oh, and having sex, but who doesn't ? oh, sorry for you in the back.

Regarding my programming experience, I started programming in high school on my
TI-80, then tried out VB. Then I got a TI-89, and played with it a bit. I found
a C compiler for it and started writing simple C programs. That's about when I
realized VB was evil, and started using C on my computer (i had an old P2 that
an aunt had given me). In the same time, I discovered Linux, and started to play
with it from time to time. I'm now a 95% time Linux user, until someone gets
Oblivion to run in wine with my old ATI graphic card :). Personal projects
include mainly small tools for personal use (such as justifying text), what I
call "toy code", just written to try out something I read about, and, of course,
a few bigger school projects. I've been wanting to get involved in a bigger open
source project for quite some time now, and I figured the Summer of Code would
be a great opportunity to get started.

Now, as you probably guessed by reading the object, I've browsed through the
project ideas from Pidgin, and I'm interested in one particular project. This is
the one about "Master Password Support for Multiple Platforms". Why this project
?
Well, for one, it's a project I'm quite confident I can handle. Pidgin is not
the huge amount of code FreeBSD is, so I think I can get to know and understand
the existing code base pretty fast.
Also, I has always bugged me that pidgin stores the passwords in cleartext. I
know that in theory, as it needs to decrypt them, anyone could decrypt encrypted
passwords, but still, using even a simple obfuscating algorithm would prevent
people from just reading the password. So, when I came across this project, i
really liked the idea.

I've had a quick look through the Doxygen doc on the wiki, and on the plugin
howto stuff, to get a quick idea of what has to be done, and here the outlines
of what I came up with :
- 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.
	Second, modify the librairy itself (probably somewhere around the
purple_account_request_password() and purple_account_set_password() functions)
so that it first asks registered plugins if they can get the password, and, if
needed, ask the user himself. Of course, the same would go with set_password(),
meaning that it would tell the new password to registered plugins, so they can
store it. It might also be possible to give the password to only one plugin that
the user would choose, to avoid the password being stored everywhere. This
specific part requires some more thinking about.
	Those new interfaces would of course be documented so that it would be easy for
other developers to use them.

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

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

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

Now regarding development platforms, I would code mainly under Ubuntu Linux, so
Gnome Keyring would probably be the first supported pass safe. But I can run
tests on Windows XP, Debian, RedHat, Ubuntu, FreeBSD, and I'll even have access
to an iMac during the summer, meaning that I'll play with most of those
platforms.. I'll probably need to find a computer running Vista, or have someone
perform tests for me.

An important thing is the schedule I would be able to work on. Here in France,
Summer Holidays start on the end of june. I'll have exams the last week of june,
so I obviously won't be able to work on the project that week, nor the two weeks
before that. And, of course, before that, I have class.

Here is a basic schedule of when and how much I could work :
now -> 12/04 	(class) lurk on irc chan + devel mailing list, get feedback on my
SoC application, get to know people, etc.
12/04 -> 20/04 	(spring holidays) start reading and understanding existing code,
play with plugin API, password storing tools APIs, ask questions
20/04 -> 30/04 	(class) Lurk more, continue to think about different possible
implementation
30/04 -> 04/05 	(4 days weekend) Have detailed and precise outline of everything
that has to be done, write a precise schedule, getting community feedback
04/05 -> 08/06 	(class) analyzing feedback, start coding (~10h/week)
08/06 -> 28/06 	only school related work, exams
28/06		end of exams, cleanup room, pack stuff
29/06 		move to parents home for the summer
30/06		Start coding, everyday, most of the time. I basically have nothing
planned for the month of july and the first half of August.

Here is an estimated idea of how things should advance :
04/05 : everything planned, documentation gathered, only code left to do, start
coding on evening and weekends
10/07 : working plugin Interface on Ubuntu + simple test plugin
13/07 : Plugin interface working under all OS
15/07 : Working basic Gnome Keyring plugin
16/07 : Working basic KWallet plugin
20/07 : Plugin merging the two previous ones working
25/07 : Config interface working
30/07 : Plugins for apple-keychain, and a least one windows equivalent, maybe
more
05/08 : heavy testing done
08/08 : maybe some more bug fixing/adding support for more safes
11/08 : code cleanup, documentation
16/08 : packaging for major releases out for testing

Of course, all this is just an estimation, and might be shifted depending on how
much I manage to get done before my exams, or if there are things I overlooked.
As I said, a detailed schedule should have been written by the 4th of may.

Any feedback or questions on either the technical side of the project, my
schedules, SoC-specific issues, or anything else, are ,of course, most welcome.
I'm currently iddling on the pidgin IRC chan under the handle "Scrouaf". If I'm
not answering, it means I'm akf.

I really like the project, and I'm definitely looking forward to working on it,
so... well, I really hope it'll work out. Thanks for reading me.

-- Vivien Bernet-Rollande




More information about the Devel mailing list