Trust in the system is more important than any single plugin or author
3 options when malicious code found: (we probably want to rename these)
Nuclear - for clear, unambiguous malicious intent
For every plugin by that author:
Flag as insecure/untrusted
Notify authors of plugins with a dependency
Decide if it can be forked/merged/etc
Change the plugin listing to explain why it was removed
No new plugins accepted from that author
Should this be permanent?
Thermobaric - where there’s a plausible explanation (this is a deliberately vague reason to give some flexibility)
As Nuclear but only for that plugin
For all other plugins:
Flagged as potentially insecure
Code review
If another malicious plugin found at any point, proceed to Nuclear
All new plugins from that author subject to code review
Should this be permanent?
Cleanup
For that plugin, standard security issue procedure
For every other plugin by that author:
Flag as potentially insecure
Code review
Process (tbd) - contact author etc
Nuclear Example: Things like this (P3) are unacceptable (and very probably illegal in the UK if not elsewhere) and following a process (TBD) would get the Nuclear option - not because the code was particularly bad, but because (assuming Wordfence are quoting accurately) the author said:
Last year we had some serious problems after someone obtained a huge list of license keys and downloaded all of our products. … The drop tables function was put in place to try to stop this at the time.
In other words, it was all intentional, they don’t think they did anything wrong, and they’d probably do it again.
Thermobaric Example: ???
Cleanup Example: PEAR. There was malicious code, but they didn’t add it.
Misc
Some notification should appear in the dashboard for plugins flagged as insecure
Big red warning if the plugin is activated
Yellow warning if the plugin is deactivated, and some extra hoop(s) to jump through to activate it
Should we consider adding support forums for plugins in our directory? It would be good to be able to centralize this, but we’d need to evaluate whether we’d be able to meet the extra resource demands this would impose.
Providing the forums is easy (though quickly expensive with load) - moderating them isn’t. We’ve nothing like the resources needed for moderating, so I ruled out doing that for now. However, if we put together a good value-add on top of e.g. Discourse that might be an option.
Let’s say we have 1000 plugins that need a support forum; assuming this is a paid offering these are likely to be some of the most popular plugins.
Does Discourse scale that far at all?
What’s the UX like with that many categories?
Assuming you let plugin authors manage their own category, how do you manage 1000 plugin authors?
If we assume an average of 1000 unique users per plugin (over time) that’s 1m users - is Discourse the right tool for that job?
I mentioned Discourse because we’re using it - I’ve honestly no idea if it’s the right choice. For a few 10s of plugin, no problem - maybe even for a few 100 - but for 1000+?
invisnet [2:04 PM]
there’s no reason we couldn’t add support for a little more control over who sees the beta releases
Code Potent [2:05 PM]
Now, that is a bit more interesting.
I want to restrict pre-releases/betas to users who are well-versed with the current release…to ensure that testers hit the ground running.
If it could be restricted by GitHub usernames - or even members of a GH team – I could see more of a (personal) use-case.
I’m not sure about this either, but keeping everything centralized under Discourse would definitely be easiest if it will work well enough. Maybe we can set up a forums test environment and try out some things (large numbers of subforums and users).
Another thing we could do is ask the folks at https://meta.discourse.org/ how well Discourse might scale for this use case.
@invisnet How exactly the rules should be drafted will depend on whether the directory is simply going to display plugins or whether we are going to have support forums.
I’m thinking, in particular, about the way we handle a report of a security flaw from a user. If we have forums and the report is made there, then we need to spell out how we are going to handle them in addition to outlining what will happen if we (i.e. you) find a flaw (or have it reported to us through a channel other than the forums). If, however, we don’t have forums, then we will be able to address potential security issues in just one way, irrespective of how we obtained the relevant report.
Just to be clear, this should not be taken as suggesting that I am not in favor of having support forums. In fact, I would much prefer to have them. It’s just that the way we draft the rules will need to take account of that fact.
Let’s assume for a moment that we have forums at some point (I doubt we will at the start, but it’d be nice to have eventually).
We should never have security reports via the forums - that’s the wrong way to do it and we’ll need to take those kinds of posts down. The difference there between us and WP is that we’ll have a well-defined way of contacting both us and the author; if it turns out that something is in the wild and being exploited then we can post something to the forum in addition to the normal procedure of flagging the plugin as insecure.
That’s the one scenario I’m still thinking about how best to deal with - if you automatically disable the plugin you might break their site, but if you leave it alone they may well get compromised.
Here’s a first draft of the security policy for plugins:
We are pleased to provide this plugin directory both as a convenience to our users and to support those developers who have created plugins designed to work with ClassicPress.
Just as ClassicPress takes a security-first approach, we ask that developers who submit plugins for listing in the directory take the same approach. If we identify a potential security problem with any of the plugins listed, we will:
notify the developer of the potential problem;
flag the plugin as potentially insecure within the ClassicPress dashboard of those users with the plugin installed;
remove the plugin from the directory while a code review is conducted; and
flag as potentially insecure all other plugins in the directory that have been created by the same developer while a code review is conducted for each of them.
Once an affected plugin passes code review, it will be eligible for reinstatement in the directory without being flagged as potentially insecure.
Plugin developers who are found to have included a security problem with malicious intent will be banned from having any of their plugins listed in the directory.
Anyone who believes that they have discovered a security problem with a plugin listed in the directory should report the issue as soon as possible to EMAIL ADDRESS. Such reports should NOT be made in the support forums. Any report of a security problem made in the forums will be removed.
In every instance, what constitutes a security problem, code review, or malicious intent are matters exclusively for the forum moderators and the ClassicPress security team leader to determine. Their decision is final.
This is the only part of the current spec that jumps out at me as needing improvement. I expect many plugin authors will want to release a version of their plugin that works with both WP+Gutenberg and ClassicPress. As long as the plugin is tested for compatibility with WP 4.9 and/or ClassicPress this shouldn’t prevent the author from also staying up to date with WP.
As a side-note would it be useful to flag authors with a rating or average response update time or something? I’m not personally a developer of plugins or dedicated themes so I’d be interested in hearing from actual devs - would this be an issue for you?
For clarity I’m trying to think from a user perspective where you might be off-put by a plugin that hasn’t been updated in a while - but perhaps is so simple/basic it doesn’t need updating . Or where plugins are flagged as “potentially unsafe” merely because the user checks the repository at a time when the plugin is is being actively updated but hasn’t been pushed live yet.
I’m not sure what current policy on either WP or CP is but is there potentially a notification system we can use for authors to let them know there’s been CP updates and they may want to check they’re all up to speed - and the ability for them (or maybe others) to flag things as tested, compatible and not a security risk?
That came from @anon71687268’s designed for ClassicPress thread I don’t think it should apply to plugins in the directory as this would rule out lots of plugins for no good reason.
As long as code is compatible and tested with ClassicPress it should be acceptable.
Yes, that applies to my ClassicPress-specific plugins post which is intended to highlight ClassicPress-only plugins – no dual support plugins, no conversions, no WP plugins rebranded for CP…which would be off-topic to the post.
It makes no difference to me if WP-supportive code makes it into the CP plugin directory.
