3 posts were split to a new topic: Disable Vulnerable Plugins
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.
7 Likes
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.
1 Like
Yes, that phrase could do with some work.
The idea is to ensure that no WP-specific code is loaded (or available) at runtime under CP, not to prohibit a single shared codebase.
Update: that phrase has had some work - feedback welcome!
2 Likes
Quoted for posterity after the changes… this looks good to me.
2 Likes
This does not make sense to me.
Will CP have 3 ways to update a plugin? (that sounds like WP-specific code)
Will every code change to a plugin be audited? (no way to have the manpower for that)
Would there be a way to opt out of auto updates? (there are times updates are not wanted – e.g. Gutenberg)
I think the user would be confused as to what they are getting. With WP, if it’s listed in the admin Plugins search, it has been reviewed (initially at least). If there is a security problem, the plugin is closed so it does not show as available. But there are plugins available everywhere, and the user knows that those external ones have not been reviewed. The plugin author is rewarded with exposure to users by putting the plugin in the WP repo.
Some consideration should be given to what restrictions are put on plugins that are shown to the users, such as advertising or hijacking the admin or removing the plugin Deactivate link or crypto mining or tracking users or phoning home or sending spam, etc. I assume you want to be fair, but if you don’t restrict it, fairness goes out the window.
No, just 2 (we’ll most likely leave the existing WP-based plugin mechanisms in place for people who want to install plugins from the WP directory). There may be some variations in how plugins in the ClassicPress plugin directory are presented but they will be hosted the same way (for example, on GitHub).
The technical meaning of patch-level is important here. Plugins that are audited by ClassicPress will be required to use the semver version specification which is major.minor.patch (e.g. 1.2.3). In this example, 1.2.3 to 1.2.4 would be an automatic update, but 1.2.3 to 1.5.0 would not.
A patch version update (only the third number increases) means there are no breaking changes, only minor changes or bugfixes. The responsibility would be on the plugin author to follow this standard.
Please don’t use the words “repository” and “directory” interchangeable. They have a very different meaning in CP.
Maybe you know, that in CP we don’t have repositories, just a directory. WP has a repository. Old member knows this, but suppose, this thread will read a novice.
And if you think about the differences, you will find answers to some questions and worries above.
5 Likes
What are the main obstacles to running our own repo? Obviously there’s cost and management but what else is there? Security?
Regarding cost, anyone have a clue what it would actually cost to run a repo with 1000+ plugins / themes? And in that respect, what are the chances of getting A N Other Hosting Provider to sponsor us? Is that something worth exploring?
1 Like
Why do we want our own repo?
1 Like
It won’t be a repo, it’s just a directory. The rest of your questions are valid.
2 Likes
Why not?
It was discussed here on the forum somewhere… sorry, I can’t find it now among all the related posts. I think it boiled down to cost, liability, and ease of implementation since it didn’t require a ton of infrastructure.
3 Likes
Thanks @anon71687268. That’s all I was asking - what are the obstacles.
If it’s impractical for the reasons you mention then so be it.
I’ll have a look for the related posts as I’m still interested in seeing the detail, just to satisfy my own curiosity.
3 Likes
Sorry it was a short question, but it was a real one: what is it that a repo provides that a directory doesn’t that we might care about?
I’ve come to the conclusion that for now there’s absolutely nothing, but I may not have thought of everything - that’s the great thing about having other people involved in a project.
2 Likes
Sorry it was a shorter answer 
My question was a real one too. The main reason I asked was because it occurred to me that if the main obstacle was cost, then that might be a potential opportunity for sponsorship. I wasn’t questioning the decision, just wondering what the obstacles were.
In answer to your question, all other things being equal, wouldn’t a repo perhaps make things logistically a bit easier - from both a developer and end user perspective? We want to make things as easy as possible for both and certainly for users switching from WP. I think it may also give a greater sense of security to the end user knowing that they are downloading from a trusted source.
Anyway, that was where I was coming from. @anon71687268 outlined the reasons why the decision was made to go for a directory rather than a repo and I’m fine with that. But as I say, the potential for sponsorship was what led me to raise the issue in the first place.
3 Likes
If it was a repository you’d need to check your code into it as well as your own development repository. Being a directory, you’ll be able to link it to your own GitHub repository so less work from a developer point of view.
For the end user, they’ll install from the directory in the ClassicPress dashboard, so no difference in effort.
4 Likes