Hi, folks.
The current situation around the Plugin API is pretty unacceptable. Two
APIs are currently in use (and I must admit that I failed at creating a
plugin API with security in mind), developers are confused as to which
API is the preferred one, and all in all there is no real security in
either of the APIs.
My (second :) proposal:
* Plugins, when loaded, reveal what privileges they need in order to
function.
* The PluginManager, responsible for loading, managing, and unloading
plugins ask the user via the web interface whether the user wishes to
grant this plugin the privileges it asks for. If the user declines the
privileges for the plugin it will not be executed.
* Plugin use special methods from the PluginManager to retrieve wrapper
objects that allow only the specified access possibilities.
The following privileges might be possible:
* Requesting keys from freenet.
* Inserting keys into freenet.
* (Read or read/write) access to the global queue.
* Integration into the web interface.
* Access to a couple of state variables.
* Full access to the node (DANGEROUS - might do just about anything).
For every one of the privileges a wrapper object needs to be created
that only allows access to the exact methods the privilege is about.
In the future additional privileges may be created. If a plugin asks for
a privilege the node doesn't know about (because it's too old) the
plugin won't be executed and the user will be advised to update his
node to a more current version.
What do you think?
David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20060726/3444f1f9/attachment.pgp>
