Now that the WordPress plugin competition for 2009 is complete, Ozh has published his reviews of each plugin that was entered into the competition. Some of his reviews mention particular security issues that were discovered along with some shoddy coding. Once I read his reviews, it occurred to me that if the plugins in the competition had these issues, just imagine the state of plugins being hosted in the repository. If every plugin in the repository was reviewed as closely as the competitions were by someone like Ozh, I’m afraid of what the results would be.
This leads me back to the idea that the WordPress plugin repository needs a plugin validation team. This team would be a group of individuals of Ozh’s caliber that would review each line of code for any plugin that was initially submitted to the repository. They would make sure that the coding guidelines were met, bad code was corrected, and would not approve of a plugin until all checks were passed. Unfortunately, it’s too late for the repository to have such a team/process. In order for it to be truly effective, the plugin repository would need to be wiped out to start fresh with these new guidelines/practices in place. Something I don’t see happening anytime soon.
Currently, WordPress plugins are encouraged to be built around these WordPress Coding Standards. There is also documentation on how to write a plugin for WordPress. When a plugin is submitted to the repository for inclusion, the plugin is manually checked by someone to make sure that the submission came from a human rather than an automated process. I’m not sure if each line of code is checked or if it’s just a once over but once the plugin is approved, the author then has SVN access to that plugin which is an automated process. There in lies another problem. These revisions are not checked because there are hundreds to thousands of them each day. So the other risk here is a popular plugin authors account gets hacked, that person publishes malicious code into the plugin to trigger an upgrade notice and now potentially hundreds of blogs are compromised. Thankfully, this hasn’t happened yet but I wonder if it’s a matter of when, not if.
That's A Lot Of Plugins
So even if there was a plugin validation team, there is no second line of defense unless you consider that to be the countless number of eyeballs reviewing the code as they install plugins onto their blogs. However, this raises another point.
I believe that the expectation for end users to dive into the code for plugins and themes they install onto their site is unrealistic. Essentially, everyone who uses WordPress would need to have a good understanding of PHP including the security aspects of it in order to make good decisions on whether a theme or plugin would be safe to install on their site. Matt Mullenweg and the WordPress project can not control end users blogs to make sure they are upgraded, they can’t control plugins or themes to ensure they are upgraded, they can’t control end user decisions but what they do control are the repositories. I think these repositories are a huge responsibility for the WordPress project and that in the beginning, more should have been done to ensure quality code would only be accepted into the repository. This is the way it’s worked for phpBB3 and so far, seems to be working well for them. Sure, if something like this were put into place, there wouldn’t be as many plugins or themes on the repositories but in this case, the end justifies the means. Good code and less insecure plugins and themes more than trump the amount of choices that would be available.
Clear Policies Related To Mod Validation For phpBB3
Now that a validation team simply wouldn’t work because the repository is in full swing, I think the potential is high that it is a ticking time bomb filled with insecure or improperly coded material. But, I don’t know PHP from ABC so I can’t confirm or deny my suspicion. The worst case scenario is that a new line of thinking takes place regarding the repository. Great place to pick from a large variety of plugins that fill a need but if you don’t know PHP to check how they were created, you may be installing the demise of your site. Of course, it would take some popular plugins to be compromised or, some popular sites to be compromised due to a plugin installed from the repository for this line of thought to gain any steam but considering how easy it is now to install plugins from the repository, it could certainly happen.
I see this entire issue as one of the big problems facing WordPress. Thankfully, nothing drastic has taken place so far but as more plugins are added to the repository, old ones are not pruned off (yes I know that some WordPress 1.5 plugins work on 2.8), and the bar to entry to use WordPress is lowered even more, the ingredients are slowly coming together to increase the risk for all who use the software.
As far as solutions to the problem, I can’t think of any off the top of my head that would not require the plugin repository to just start over. I suppose all end users of WordPress could read PHP For Dummies to be better educated on what is going on between plugins and their WordPress powered site but that would be expensive and some folks just want to publish content, not develop. Any solution that goes into place now which would make inclusion into the repository a more stringent process wouldn’t work because of the thousands of plugins submitted before them.
If the team is not going to make it harder to get into the repository then there should be clear warnings letting users know that while they host plugins, they can not be held responsible for any damage that may occur to their site from a plugin they installed from the repository. If I installed a plugin from the repository and it caused my site to be compromised, I would blame not only the plugin author, but much of the blame would be pushed onto the repository for hosting the plugin which made it easily available to millions of people.
Your Answers:
I find this subject to be a huge problem. You may not. Let me know in the comments what you think. Also, if you have any ideas on how this problem can be solved, particularly without requiring the plugin repository to start over, tell me about them.
