[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