Master password

[Vivien Bernet-Rollande]

Hi.
Some of you probably remember me. I'm the guy who worked on the master
password Summer of Code project.
To put it simply, I've got a couple weeks of free time ahead of me, so
I figured I should get this whole thing done and merged properly. I
pulled the branch out a few hours ago, merged with trunk, and fiddled
a bit with it.

The current status of the branch is the following :
 - a few things need to be cleaned up (trailing spaces, empty lines
added, etc). This should be quick.
 - I just spotted a bug. Passwords are lost when going back to the
"default" keyring. I'm unsure whether it was already there or if it
was introduced by other changes I merged in.
 - the Gnome Keyring plugin is perfectly functional.
 - the Kwallet keyring is not built through the normal build process
and was never tested. I need to integrate it properly.
 - there has been modifications to the jabber prpl that will require a
few changes to use the async API.

Now, about the whole "removes API" thing.
The patch doesn't actually remove API. It does introduce modifications
that are not perfectly backward compatible, but I can't think of a
case where it would actually be a problem.

A few words on how my code works. It has four main entry points :
purple_account_get_password_async()
  try to get the password from account->password
  try to get the password from the configured keyring
  pass it to callback
purple_account_set_password_async()
  set the password from account->password
  set the password from the configured keyring (if configured to save it)
  pass possible error to callback
purple_account_get_password()
  try to get the password from account->password
  try to get the password from the configured keyring if the keyring
supports synchronous mode
purple_accunt_set_password()
  simply call purple_account_set_password_async() with no callback.

The "default" keyring plugin is compatible with the classic
accounts.xml format, and supports both sync and async API. The Gnome
Keyring also supports both, but will leak a few bytes of memory if
used in sync mode (this could be corrected using complex objects such
as linked lists or hashtables, I just didn't bother). If used in sync
mode, the gnome keyring plugin will block while prompting for a master
password.

In most cases, the prpl gets the password through
purple_connection_get_password(). The plugins that used
purple_account_get_password() have been corrected (except those new
changes in jabber). When connecting an account, this is what happens
(both before and after my patch) :
if (we have no password) then
   if (the protocol requires a password) then
      prompt for a password
   end
end
create a connection using the password or NULL.

The prpl then uses the password from that connection to do what it has
to do, and never needs to use the new async API.

The problem arises when the prpl says it doesn't need a password, but
actually needs one. (ie it tries to connect without and then falls
back to using a password). This is the case of the jabber prpl, and
possibly other unofficial plugins. The jabber prpl does the following
(if we do not have a password stored) :

We start the connection anyway, without a password.
The server asks for a password.
We prompt the user for a password
We store the password with purple_account_set_password().
We then use purple_account_get_password() to get that password later on.

Since we stored the password in the account, we will be able to get it back.
I can't think of any use of the API where a problem would actually arise.

So, simply put, the code is backward compatible :
 - always if you use the default keyring
 - unless you do something really weird, and the configured keyring
only supports async mode.
Weird things would include messing directly with the xml, or requiring
a password without a connection.

The original idea was to keep only the async code for 3.0, and keep a
backward compatible API for 2.x.

My main question is the following : is that backward compatible layer
enough to fit in 2.7, or should I focus on integration for 3.X and
simply drop it ?

--
Vivien Bernet-Rollande