Register Members List Search Today's Posts Mark Forums Read

Reply
 
Thread Tools
  #1  
Old 23 Mar 2016, 07:54
vbresults vbresults is offline
 
Join Date: Apr 2009
Framework for Secure Legacy Plugins

From this:

Block Disabled:      (Update License Status)  
Suspended or Unlicensed Members Cannot View Code.

To this:

Block Disabled:      (Update License Status)  
Suspended or Unlicensed Members Cannot View Code.

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.

Last edited by vbresults; 23 Mar 2016 at 13:15.
Reply With Quote
  #2  
Old 23 Mar 2016, 12:22
squidsk's Avatar
squidsk squidsk is offline
 
Join Date: Nov 2010
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.
Reply With Quote
  #3  
Old 23 Mar 2016, 13:11
vbresults vbresults is offline
 
Join Date: Apr 2009
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.
Reply With Quote
  #4  
Old 23 Mar 2016, 13:11
Gio~Logist's Avatar
Gio~Logist Gio~Logist is offline
 
Join Date: Jun 2004
Location: San Francisco
Real name: Giovanni Martinez
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
__________________

ModernvB.com - vBulletin Mods & Services - ModernvB.com vBulletin 3 Mods - ModernvB.com vBulletin 4 Mods - Hire ModernvB
Full-Time vB Development - If you can think it, we can build it.
Reply With Quote
  #5  
Old 23 Mar 2016, 13:31
Dave Dave is offline
 
Join Date: Jun 2010
Real name: 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.
__________________
https://technidev.com - security, development, exploits, vBulletin
dave[at]technidev[dot]com

Contact me for custom vBulletin 3/4 work & server/website management.
Reply With Quote
  #6  
Old 23 Mar 2016, 13:35
Gio~Logist's Avatar
Gio~Logist Gio~Logist is offline
 
Join Date: Jun 2004
Location: San Francisco
Real name: Giovanni Martinez
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).
__________________

ModernvB.com - vBulletin Mods & Services - ModernvB.com vBulletin 3 Mods - ModernvB.com vBulletin 4 Mods - Hire ModernvB
Full-Time vB Development - If you can think it, we can build it.
Reply With Quote
  #7  
Old 23 Mar 2016, 16:42
squidsk's Avatar
squidsk squidsk is offline
 
Join Date: Nov 2010
Originally Posted by Gio~Logist View Post
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.

Last edited by squidsk; 23 Mar 2016 at 17:22.
Reply With Quote
  #8  
Old 23 Mar 2016, 17:16
Paul M's Avatar
Paul M Paul M is offline
 
Join Date: Sep 2004
Real name: 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).
__________________
Former vBulletin.org Staff Member


Cable Forum
Please do not PM me about custom work - I no longer undertake any.
Note: I will not answer support questions via e-mail or PM - please use the relevant thread or forum.
Reply With Quote
  #9  
Old 24 Mar 2016, 01:24
vbresults vbresults is offline
 
Join Date: Apr 2009
Originally Posted by squidsk View Post
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 View Post
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.

Last edited by vbresults; 24 Mar 2016 at 01:35.
Reply With Quote
Reply



Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


New To Site? Need Help?

All times are GMT. The time now is 07:21.

Layout Options | Width: Wide Color: