[wp-hackers] Code reviews for plugins?

Mark E mark at simplercomputing.net
Mon Aug 23 03:08:31 UTC 2010



On 08/22/2010 03:15 PM, Jeff Chandler wrote:
> I wrote a post back in 2009 asking if something like what is bring
> described here is nothing but a pipe dream.
>
> http://www.wptavern.com/is-a-plugin-validation-team-a-pipe-dream
>
> May be worth reading as well as the comments attached to the post. It's
> a topic and suggestion that keeps coming up but no one seems to know how
> to tackle without the intricate process of vetting one plugin against
> another.

 > What happens if a plugin has been reviewed and flagged as
> awesome but a week later, has a security vulnerability discovered.
> Doesn't that make the whole system broke and worthless?

The answer is simple: Ditch the review process, because obviously nobody 
involved is qualified to manage it.


That said, there are issues about code review that people will not agree 
on - nor should they. Examples:

Some people are entirely anal about insisting on the use of camel case.

Other people are hell bent on using a class even if it only wraps one or 
two incredibly basic functions.

Other people insist that all your css goes in a subdir, all your forms 
go in a subdir, all your JS goes in a dir, etc - even if your entire 
plugin is entirely user-facing and can be contained in one really really 
really small file.

What all that boils down to is people saying "you need to write code 
like ME - I cannot tolerate diversity"

That sort of thinking has absolutely no bearing in a code review process 
unless code might be intended as a core patch, or core addition - that's 
different since that code ought to integrate seemlessly into existing 
style.

Personally, I don't care how people write code as long as three things 
happen:

- No potential function or class name collisions (e.g. be original and 
think ahead)

- No unnecessary overhead. If code isn't needed yet, don't load it. If 
you intend to use data, cache it internally.

- Think like an intruder and defend your code against becoming an 
vehicle for intruders.

So, in terms of code view for plugins, that's all I'd be looking for. 
All the rest is rather pointless.

That latter security item is the biggest hurdle.

One really really really big problem with policing anything is that as 
soon as you start you accept liability. If you fail at any time, you are 
perceived as being liable. On the other hand, if you don't police, no 
one can accuse you of doing a bad job and drag you into court over it.

That's the situation ISPs have faced for about 15 years. And so they 
don't police your activity or your content. They might spy on you, and 
they might reprimand you if someone brings your activity to their 
attention, but they don't police you. And thus they are held liable for 
what you do. They're only a conduit - just like the WP plugin and theme 
repo.

My opinion, if it isn't clear already, is to forget about screening the 
repo. That's not the responsibility of Automattic.

Mark


More information about the wp-hackers mailing list