Use this thread to brainstorm ways to ma…
Use this thread to brainstorm ways to make plugin repo more secure in terms of what code makes it in there.
Recent comments
siobhyb on OPW Introduction – Hello… Dan on JSON REST API Tips Tuesday – Relea… on Summer of Code Revisions scribu on Migration project for GSoC Bryan Petty on Summer of Code Revisions
Jonathan Dingman 9:19 pm on October 1, 2009 Permalink
Right now, people can submit their plugin for approval, be accepted (or denied), and upload their plugin. Then, they can make updates. Ok, so far so good.
While I don’t think it’s scalable to have code reviews on every little code update of every plugin, which would turn us into the Apple AppStore, I do feel there ought to be some sort of level of accountability. I can’t pinpoint exactly how it should be in effect, but I feel there needs to be — beyond someone going onto IRC and reporting it to MarkR (as an example).
Maybe even having a “report form” on each plugin page, letting people flag plugins as “this plugin requires a link back” or “this plugin has known vulnerabilities” or “this is spam” and have someone, even a volunteer, manage it, and/or forward the suggested action to take to an Automattic employee.
I feel that there needs to be some additional level of accountability set in place for plugins, since it’s becoming an even more important part of WordPress than it was just a couple years ago.
Millan 11:59 pm on October 1, 2009 Permalink
Good points, Apple AppStore level of control is just insane and it’s not a good way to go. Right now, except for approval of plugins I think that there is almost no control over what’s happening there (correct me if I am wrong).
But first thing needed is a cleanup. There are so many plugin that are not maintained or even downloaded for years. I am not exactly sure, but my guess is that no more than 2000 of almost 7000 registered plugins are active.
Ken 3:58 pm on November 5, 2009 Permalink
Rather then approval ala AppStore, plugins that got and pass audit could have a badge… one that would be desired, but not required. We could concentrate on popular plugins first, and ones marked by Dingman’s (crowd source) flagging suggestion. I think that the review should primarily audit security on the plugins, not indepth quality reviews
.
But I agree with Millan, the repos need some cleaning. On the mailing list, deleting was brought up, but that’s not “exactly in the open source model”. Rather, I’d like to see some tag that marks a plugin abandoned (as judged by review or author’s explicit declaration, to prevent old but good plugins’ removal), and that removes it from the default search only. It’d still be findable for someone who’s interested in reviving it though a separate search. A tag for “unsafe” could be useful too, maybe block installation though the WP admin but still allow .org download (for someone to fork and fix).
With the new compatibility feature, something has to be workable here
Aaron D. Campbell 4:14 pm on October 2, 2009 Permalink
It seems to me that there are two basic approaches here. Either put together a team to do this or crowd source it. Both have their advantages and disadvantages. Obviously a team would be reliable, but overwhelmed by the amount of code that needs to be audited (however, there are probably some ways to mitigate this, but I’ll get to that in a second). I’m really worried about the idea of crowd sourcing the security of code. Mostly because most of the “crowd” doesn’t know what they’re doing. The vast majority of the complaints you get will be because the person couldn’t get it to work, there was a plugin or theme conflict, or because they blame it for something else that they did wrong. In theory crowd sourcing is nice…mostly because it spreads out the work load, making it seem manageable. I’m just worried that this isn’t something that can be handled this way (unlike plugin compatibility with WordPress versions, which I think would work well if crowd sourced).
Maybe there could be a sort of hybrid system where it’s crowd sourced and then passed to a team of people that check out the plugins that were reported, but I worry that this would increase the workload of the team rather than decrease it.
In the spirit of decreasing that workload, I have a couple ideas for that:
Some people could be “white-listed authors”, and their plugins wouldn’t need to be checked. For example, you could white-list all Automattic employees as well as people like Joost De Valk (and of course, in my opinion people like me as well). It seems like this could greatly reduce the number of plugins as well as the number of updates that need to be checked.
Also, it seems like there could be some effort put into highlighting *possible* bad code. Maybe certain functions (including usage of the WP_Http class or functions that write to the file system) or a certain amount of changed code would raise a red flag?
Jonathan Dingman 12:31 am on October 6, 2009 Permalink
Junsuijin, sivel and myself were talking today and brought up this idea.
Requires no moderation and it could help strengthen the plugin community as whole.
Recommendation: Don’t allow any linking within description, FAQ, installation, notes, screenshots, or any place. ONLY allow the two links, plugin link and author homepage link. All existing links (and future links), strip the hyperlink and have it display as thislink.com instead of the complete hyperlink.
Additionally, removing these links, it would force plugin authors to actually put real information in each section. Right now, there are a number of plugins that have just a link as their FAQ, going to their homepage. I feel this is bad usability for when users are installing a plugin via the web and because it’s just one more step for them to take to read about the plugin. It shouldn’t be that difficult to read the FAQ of a plugin. All information should be provided on the wp.org page.
How would this help?
Links would still be there for information purposes if someone really needed to go to it.
It would help weed out bad plugins that really don’t provide any value to the community (sort of
It would give spammers less to work with and force plugin authors to be more intentional about how they package their plugins
Would almost eliminate entirely, the SEO spam problem in the repo right now
Matt 1:27 pm on October 6, 2009 Permalink
While I was part of this discussion I don’t agree with this necessarily. I of course prefer not to find these types of links in the docs, but removing all the links is a bit harsh. There are plenty of valid reasons to include links such as to an external support forum, or license file.
I would however like to see where if the majority of a section is linked nothing displays at all. For example people drive huge amounts of traffic to their sites by only placing a link in each section saying, visit my site for this information.
alphawolf 8:40 pm on October 5, 2009 Permalink
Instead of reviewing every single plugin, why not start reviewing or removing all the plugins rated less than 3 or 2 stars by the community? Or mark insecure or sth. like that (not open to the public until it has been reviewed or banned forever) …That would even give the rating system a meaning.
Matt 1:30 pm on October 6, 2009 Permalink
Ratings do not necessarily mean that the code is bad or insecure. It could just be a poor implementation. In some other cases you will find that ratings go down due to retaliation for say not helping in the support forums. Or I have heard of other authors giving bad ratings to competing plugins. I think removing a plugin based on ratings would be unwise.
alphawolf 5:55 pm on October 6, 2009 Permalink
Good points, but your first ones are potential causes for bad or insecure code anyhow. A plugin with poor implementation could mean the author doesn’t really care about WP coding standards (which include security standards) and an author who doesn’t seem to care about his plugin (as of giving support in the forum) could result in an outdated plugin not matching the security aswell.
But I get your point.
aarondcampbell 3:33 pm on October 8, 2009 Permalink
While it may not be a definitive solution, I’d say that low rated plugins that have a decent number of ratings (maybe 50+?) would probably be ones that could be checked first.
Mark Barnes 12:36 pm on October 7, 2009 Permalink
There’s a balance that needs to be struck. It would be relatively easy to write a reasonably popular plugin, then make a change which (for example) sent the users password to a remote site upon successful login. Only human review could prevent that, I think. On the other hand, I don’t want to wait for human approval every time I commit.
Aaron D. Campbell 12:11 am on October 20, 2009 Permalink
Was there any sort of resolution on this? Or are we still brainstorming?