Keyrings gsoc project status update

[Richard Laager]

On Wed, 2008-07-02 at 20:00 +0200, Vivien Bernet-Rollande wrote:
> The only problem would be if a
> recent file, using encryption, was opened by an older version of
> pidgin.

We generally go to great pains to keep compatibility, but this is only
going to be an issue if someone takes active steps to enable the master
password functionality, so it probably doesn't matter.

> The general idea is pretty close to Trannie Carter's code except I've
> added the possibility for return values (int result) and error
> management and forwarding, and options.

What sort of return values would be involved? Failures are handled by
the GError parameter. Success is error = NULL. When you're asking for a
password, that returned data is not an int so you already have a
separate parameter. I doubt that you need the result parameter at all.

> Older versions of this API
> would pass a master password but it makes sense to remove the
> masterpassword argument. In that case, the plugin would have to call a
> slightly modified version of purple_account_request_password() (this
> functions takes an account as argument, we would want it to take a
> string. So I'll write a function that takes a string, and then get
> purple_account_request_password() to use that function to avoid
> duplicate code).

I think the general idea here is good, though I'm not sure what
arguments you'll need. I'm sure you'll figure that out when you get
there.

> However, the plugin would still need to know if it is
> operating with a master password or not. The same thing goes with the
> master password change : plugins will call a modified version of
> purple_account_request_change_password(), and do everything themselves.

I don't understand this point.

> typedef void (*PurpleKeyringSetOps)(int ops);

What is this?

> For now, the only options passed to a plugin I can think of are wether
> to use master password or not, and wether the plugin is active or not.

The options bitmask you've described is for the plugin to pass things to
the core. The "active" bit is in the other direction, so it doesn't make
sense here. It's also unnecessary (you just ask for the current plugin
and compare that to a plugin to find out if it is active).

To tell whether a plugin uses a master password, you just check to see
if change_master != NULL.

Thus, I don't think you need a capabilities bitmask at all.

> Now, we want to keep track of what plugin is currently being used, and
> how.
> Trannie Carter's code allows us to have a different keyring for each
> account, but I'd rather have only one plugin doing all accounts. This
> means in our case we'll have a linked list of all registered plugins,
> and a single global pointer to the currently active plugin.

I agree with all of this.

> Also, I have a few questions :
>  - In a plugin, there seem to be several ways to execute stuff at
> startup : init_plugin, plugin_load, and plugin_actions. I understand
> that plugin_actions is there to register plugin actions. But what are
> the differences between init_plugin and plugin_load ? If what I
> understand is right, the keyring plugin should register itself in
> plugin_actions, but I might very well be wrong.

init is when the plugin is probed. load is when it is loaded. When you
start Pidgin (or another libpurple UI), all plugins are probed. Their
init functions are called at this point. Then, the selected plugins are
loaded. If you later enable a plugin, its load function is called.

The init function in a plugin is generally pretty empty.

For a keyring plugin, it would register itself with the core on *load*.
That said, we need it to be auto-loaded. This probably means adding a
new plugin flag as I *think* we currently autoload when type == SSL or
something.

>  - The windows PDAPI plugin will use MS librairies, and therefore
> headers from the SDK. Should I take these headers and include them as
> is in the pidgin tree ? Should I copy/paste only the useful parts ?
> Should I assume that the build system will have them installed ? Or
> should I, because of licensing considerations, re-write entirely the
> parts that I need ?

If they're not already in the current win32 build environment that we
use, then you'd have to ask Daniel what to do. Copying them into the
tree is almost surely going to violate their license.

>  - I believe we are not using OpenSSL for licensing reasons. Are we
> using another crypto librairy ? Or should I grab code from GPL/public
> domain files ? In that case, is mentionning the origin of that
> specific code in the source file enough, or should that be mentionned
> elsewhere ?

We use NSS and GnuTLS right now, through our SSL abstraction. There's
also some crypto code copied into libpurple. If you need something that
isn't provided by both NSS and GnuTLS, we'll need to copy it into
libpurple, so yes, it'd have to be under a GPL-compatible license.

Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://pidgin.im/pipermail/devel/attachments/20080702/14641526/attachment.sig>