WordPress.org

Ready to get started?Download WordPress

Ideas

Plugins and Theme Repository Thorough Bug, Update and Security Review

  1. CottageCrafted
    Member

    And when I say "App Store", I mean that no one is forced to be on it (unlike Apple's store). I mean that there is a company trusted and referred by WordPress that thoroughly tests and checks for security all themes and plugins submitted to it before listing and refuses to list insecure ones. This would keep us end users from a lot of headaches.

    Posted: 5 months ago #
  2. Ipstenu (Mika Epstein)
    Half-Elf Support Rogue & Mod

    WordPress.com is for managed WP hosting with exactly what you just described: a managed, tested, security reviewed, set of themes and plugins that you can chose to purchase to add on to your site.

    We do remove any insecure plugins and themes we find right away, but the whole process of managing that is harder than it looks. For one minor example, let's say we pull a plugin that you're using. Do we disclose to everyone "Hey this has a flaw!" before there's a fix, which then makes you highly vulnerable to anyone nefarious? Do we wait till after, and put you in a place where you have to upgrade? Not everyone can upgrade right away, and there may be conflicts with other plugins. Do we forcibly pull a plugin off your site (and by the way, the screaming that would come with that....)

    It gets messier really fast, and we have yet to come up with a good solution.

    Which comes back to this. WP's plugin and theme repository are for free plugins written by anyone. That comes with certain risks and responsibilities, and while we do review plugins, we're human. Just like Apple themselves had a MASSIVE security hole (please upgrade iOS and your computers ASAP if you haven't already), we miss stuff :/ No amount of app stores would ever prevent that.

    Posted: 5 months ago #
  3. CottageCrafted
    Member

    Right. The main issue is that it's a "buyer beware" world as far as premium plugins and themes (that therefore are outside the WP.org site). I guess you're doing the best job you can on the WP.org side. It would just be good to have a (for profit) Securi-type review (before the product launches) site for SOME of the pay-for plugins.
    That won't fix all security issues (thanks for the Apple update) like you said, but would be better than stumbling round the net looking for good plugins. Are you saying that Automattic already does that for ANY self-hosted WP installation and other developers, or just for WP.com?
    Some companies is actually pretty good, but we kind of stumbled on them by accident. A new user might not know whether they are good firms or just a bunch of hackers. Any given company doesn't have EVERYTHING we'd like either.
    Not critical.

    Posted: 5 months ago #
  4. Ipstenu (Mika Epstein)
    Half-Elf Support Rogue & Mod

    Automattic does it for what they own - WPCOM

    Other hosts (WP Engine comes to mind) does it by disallowing plugins on their hosts.

    Posted: 5 months ago #
  5. George Lerner
    Member

    12345

    Partial solution, that could Easily be checked for the Plugin repository and by the Core:

    1) /wp-admin/network/plugins.php shows if are using the latest version of each plugin. But it doesn't indicate the Date of the latest version, or if the latest version date is a long time ago. Adding the date would be extremely easy.

    2) On plugins.php display the version of WordPress the plugin was written for, just like the repository page does. Display the user rating from the repository, for your installed version of WordPress with your installed version of the plugin.

    3) Plugin repository could list results of installing the plugin in a default configuration, with full error reporting on, testing for a) syntax errors, b) obsolete function calls, c) database errors, d) direct MySQL calls (e.g. bypassing WordPress security and roles), e) multi-site initialization errors (e.g. are tables created for the plugin when create a site? Does the plugin put data in wp_options or in wp_SITEID_options? ).

    The test site would be restored to default state after each plugin test. The test would be run at each plugin update posted to the repository. This sounds like something that could be easily automated.

    Not a guaranteed security or quality test, but a good check of the basics.

    Posted: 5 months ago #
  6. Ipstenu (Mika Epstein)
    Half-Elf Support Rogue & Mod

    We're working on that actually, George :) Well at least #1 and 2.

    #3 is more problematic since if YOU can find someone willing to test that of all 30k plugins... We do test all plugins' first submission for that. We don't require E (that is a plugin doesn't have to support multisite), but we do make plugin authors aware of it being potentially a problem.

    But... maintaining that. We don't. We can't. A theme is pretty much the same, when you get down to brass tacks. A plugin can be anything :(

    This sounds like something that could be easily automated.

    Wish it could. We have yet to manage to do it in a way that didn't net a bajillion false positives that we have to look at them all manually anyway :/

    Posted: 5 months ago #
  7. George Lerner
    Member

    12345

    @Ipstenu "We have yet to manage to do it in a way that didn't net a bajillion false positives that we have to look at them all manually anyway :/ "

    Nope. Purely objective reports.

    Have PHP error logging set to maximum, use software to count each category of error, report the findings. Already includes obsolete WordPress functions, obsolete PHP functions, syntax errors, mismatched variable types, uninitialized variables, and more.

    Look for occurrences of the most common MySQL function calls (instead of WordPress database functions), report the number.

    Get a list of tables after adding a new site (single MySQL query). Software subtract the list of tables started with. Report the difference (or maybe a little more secure, the # tables).

    Another test: Any plugin using wp_ instead of the actual table prefix, isn't programmed well.

    Similarly, # rows in [tableprefix]_options before and after (shouldn't change, plugins should use [tableprefix]_[siteid]_options).

    Show the whole list in a new tab in the Repository, for each version, and watch plugin authors clean up their act!

    Posted: 5 months ago #

RSS feed for this topic

Reply

You must log in to post.

  • Rating

    12345
    1 Vote
  • Status

    This is not a core suggestion