Request - Framework for Secure Legacy Plugins

[vbresults]

From this:

PHP Code:

($hook = vBulletinHook::fetch_hook('global_start')) ? eval($hook) : false; 


To this:

PHP Code:

foreach (vBulletinHook::fetch_hook_includes("global_start") as $filename) {
    include_once $filename;
} 


In other words, drop each plugin's phpcode to the filesystem. From there, we can generate md5 sums corresponding to each plugin of each product and distribute them with a md5 sum php file, and add it to the built in file integrity checking tool.

We'd be dropping the plugin table's phpcode column, putting the php code in files, and the execution order as a prefix to the filenames. This requires plugins to be formatted differently, and a conversion tool for old plugins.

That said, conversion is simple, non-destructive, and there's not a lot of room for bugs, except references to the deleted phpcode column. It eliminates the use of the datastore that keeps sites infected, increases performance, and enables the use of file scanning tools.

[squidsk]

You can achieve similar results with no changes already by simply having the content of a hook be a php include or requires line with the file located in the system. Then just add the file with its md5 sum to a file for your mod that has a similar structure to the default md5sums file from vb. There's even a product for vb3.6 which will generate the vb5sums file for any files you point it to.

[vbresults]

It doesn't matter if it's not enforced or implemented at the vBulletin level (one mod doing this and others not, while still having the phpcode in datastore, achieves nothing). This, if implemented automates everything, and the converter is able to import mods in the old format.

[Gio~Logist]

I do most of my mods with the filesystem as it is now as well, by requiring.

I can DEFINITELY see the value in making this the standard for everyone though. Aside from just not having to create a plugin for each hook location I want to effect (which is beyond annoying), there can be a lot more benefits :up:

[Dave]

If the fetch_hook function is completely removed, it will break some plugins though because some of them use custom hooks in the code. (For example DBTech's chatbox plugin)

The only way this will work out for all other plugins is if vBulletin feels like implementing exporter/generator functionality that automatically converts the current PHP hooks system to the new one.

Besides that, it's a good idea.

[Gio~Logist]

Wouldn't be that hard to export plugins as phpcode in their respective "product directories.

All in all though, I think it really comes down to whether or not 3rd party development is a focus for vBulletin at the moment (although I agree it should be).

[squidsk]

Originally Posted by Gio~Logist

Wouldn't be that hard to export plugins as phpcode in their respective "product directories.

All in all though, I think it really comes down to whether or not 3rd party development is a focus for vBulletin at the moment (although I agree it should be).

Given vb5 uses a different plugin model rather than the eval one used by vb3 and vb4 the probability of this ever seeing the light of day is essentially zero. Further due to scoping differences between eval and importing a file this change would end up breaking a significant number of plugins.

As Dave pointed out this also does nothing about products that implement their own custom hooks. Further where are these "product" directories located and how will vb know to look there for any particular hook, or are you suggesting that it should look in the product directory for every product for every hook to see if there's a file that should run on that hook? If not how are suggesting vb knows that a product wants to use a particular hook? If so that's very inefficient.

[Paul M]

The hook code you are referring to does not exist in vB5, only vB4 & vB3.
No such major change will ever be made to them, since they are no longer in development.
(Even if they were, its unlikely this would ever have happened, since its a major redesign of the way hooks work).

As an aside, requesting changes to any vB core requires a Jira, its never going to happen (even for vB5) from a thread on this forum (or indeed on vbulletin.com forum).

[vbresults]

Originally Posted by squidsk

As Dave pointed out this also does nothing about products that implement their own custom hooks. Further where are these "product" directories located and how will vb know to look there for any particular hook, or are you suggesting that it should look in the product directory for every product for every hook to see if there's a file that should run on that hook? If not how are suggesting vb knows that a product wants to use a particular hook? If so that's very inefficient.

No problem, those in-product hooks can be handled/rewritten by the converter non-destructively just like the core hooks. The plugin table provides a database reference to the plugins, there is no apache-style recursive folder scanning.

Originally Posted by Paul M

The hook code you are referring to does not exist in vB5, only vB4 & vB3.
No such major change will ever be made to them, since they are no longer in development.
(Even if they were, its unlikely this would ever have happened, since its a major redesign of the way hooks work).

As an aside, requesting changes to any vB core requires a Jira, its never going to happen (even for vB5) from a thread on this forum (or indeed on vbulletin.com forum).

Yes, that is why I said Legacy plugins;

There have been updates made to vB 3.x recently so I was under the impression some of the staff here was informally keeping the product up to date, so wanted to go straight to the source.

I think due to the nature of the redesign it's actually not that big of a deal to implement on a technical level, almost nothing can break, but the benefits for people, especially those who got hacked, can be big.

Also, I can't log into JIRA and I'm showing as unlicensed here so I couldn't post it anywhere else.