Master password branch integration - ready for a review
tomkiewicz at cpw.pidgin.im
Tue Jun 4 15:31:14 EDT 2013
2013/5/22 Bjoern Voigt <bjoernv at arcor.de>:
> I have updated my Pidgin
> sources (default branch), copied it and applied your diff
> Patching, compiling and installing on openSUSE 12.3 worked without
The diff was rather for easy lookup for changes - sources should be
built directly from repo  (your method worked fine two weeks ago,
but I guess it won't apply well today).
> Two remarks:
> * For testing purposes it may be helpful to be a bit more
> verbose. For instance, if Pidgin moves passwords from
> accounts.xml to KWallet it can be a good idea to tell the
> user, that passwords were moved.
The indicator of password migration process is disabling and enabling
keyring selector dropdown. If everything works fine, no clutter
notifications will be thrown (on the other hand, if someting goes
wrong, a message will be issued). For testing purposes, there is
always a debug log.
> I am also unsure what
> happens, if for instances KWallet and GNOME Keyring contain
> different passwords for the same Pidgin accounts and if the
> user switches between them in preferences. (Until now I did
> not tested it.)
They will be merged: existing GNOME keyring passwords will be left,
and all KWallet passwords will be written (possibly overwriting gnome
ones) to the new keyring. Please note, that in common situation, there
will be no passwords in GNOME keyring, because the current keyring
will be set as KWallet. Even, if gnome keyring was set previously,
when switching from gnome keyring to the other one, all passwords from
the old one were wiped.
> * I tested Pidgins behaviour for new users (by renaming
> ~/.purple). Pidgin started the accounts assistant. I cancelled
> the assistant and looked in preferences. The default Keyring
> is internal keyring without password. Personally I think, that
> it's better to have the desktop keyring manager as a default.
> I think Pidgin should behave like the build-in messengers of
> the desktop environments (Gnome: Empathy; KDE: Kopete or
> Telepathy (newer KDE default)). It's possible to detect the
> desktop environment by checking environment variables like
> KDE_FULL_SESSION (KDE).
I think, there could be an first-run-dialog with question like "Do you
want to encrypt your passwords? Yes/No/Tell me more", which could
direct user to prefs window or just ask him for master password and
select the keyring automatically. But I'm afraid, that raising number
of dialogs that are triggered on the first run (there is already
accounts window shown) will be against good GUI rules. I'm not sure,
what I should do here.
Are there any other comments? Can I just merge this code to trunk, or
wait for code review that someone wants to do in the near future?
More information about the Devel