Sounds good. However:

• Plugins are trusted code, they can access the database directly and do whatever they like. We should make it clear what they should do, but given our model, I don't know if we should invest energy here.

• I assume this is not a blocker for v1.3, but it has the target version. I believe the convention we used is to only mark blocking ones as targeted for v1.3.

Plugins are trusted code

True, but what is the extent of such trust ?

As a user I would not want to have to analyze a plugin's code before installing it (I may not even be able to), to ensure it won't mess with my DB.

I think it's a given that plugins should only be able to alter their own schema, and enforcing that gives confidence to users that their system's integrity will not be damaged.

"Making things clear what they should do" is not enough in this case IMO.

I assume this is not a blocker

Definitely not a blocker for the release, so if you want to drop the target that's fine by me.

mm...

Not quite sure how you plan on stopping someone doing:

$i = new mysqli($g_host, $g_dbuser, $g_dbpass, $db_name);
$i->query("DROP TABLE mantis_users_table);

I mean, after all, there's no reason you have to use either adodb or my db layer in the untrusted plugin code.

You'd basically need to not allow a plugin to contain PHP code to enforce this rule

Dropping the target.

Changing the schema is one aspect of many that are problematic with the concept of trust:

1. Broken plugins break MantisBT - so if a public has a syntax error, this can completely break your experience.

2. Plugins can steal your data - they may not change schema, but they may steal your issues, user names, passwords, etc.

So my point is that we either go with the integrated / trusted plugins model (note that this is not a statement about their quality, but the model), or a model where plugins are hosted and run outside MantisBT, but embedded. So in this case they have only limited access to data we give to them, they can break without breaking core, etc.

Given the above, I wouldn't spending any energy on this. It is the poison we chose with the plugin architecture we have today. And users will have to choose plugins that they believe work and are trust worthy. Testing + backup is always a good thing.

I think there is a misunderstanding here. I did not mean to completely restrict plugins from touching the schema at all or intentionally performing malevolent action, of course I am aware that it would be impossible given our architecture.

My idea was simply to make sure that the plugin's schema() method is not able to alter tables outside of the plugin's domain, which should be fairly easy to implement with a few minor changes in the plugin_upgrade() API.

This addresses the issue of inadvertant updates to the core schema, e.g. due to lack of knowledge about plugin development.

Right,

I'll see if I can build either something to achieve this into a new db layer, or (more likely) at least something that you can easily extended to do this.