Mirroring the WordPress Plugin Directory, Short Sighted and Half the Equation

Introduction

This was a response to a Facebook post about how wordpress.org could block access to mirroring it’s content. I had some thoughts that I ended up sharing and think its important for it to be online, I might not be getting everything right. But every great idea is spawned from not so great idea.

WordPress.org Blocking Mirroring and Charging for Access

I responded to someone stating that WordPress.org could just block those trying to mirror it’s data and potentially charge for access. This is true, here is my response.

Yes, WordPress.org could block access to those looking to mirror the plugin directory, and they could even charge an access fee to mirror the plugin directory. However, as history has shown, methods will be available to bypass this, and perhaps eventually those will be exhausted.

Mirroring is Short Sighted and Half of the Equation

Mirroring the WordPress Plugin directory is shortsighted and only half the equation. It is not the major roadblock to moving away from a single point of failure which is currently wordpress.org

Eventually, plugin developers will stop updating at wordpress.org for several reasons; I’m not going to go into that right now. Those developers are most likely already publishing their plugins on github.com or a public version control system. As with many other software, such as docker, you can reference a git public repository to build a docker image. Why isn’t this already supported in WordPress? beccause we already have wordpress.org and unfortunately it’s going through something right now and it’s affected the installation of plugins. The cause, it doesn’t matter because it should never have happened.

A standardized method for installing plugins is available: a zip file. You can either install a plugin from the WordPress plugin directory or upload the zip file directly to your WordPress site. But how do we replace the WordPress plugin directory? How do we detach the plugin files from the directory, which is an index of plugins that have been approved to be published? Simple: We break everything up and separate the functions of each so that they’re not tied so closely together.

Proposal to Decentralize the WordPress Plugins Directory

This is my proposal to decentralize the WordPress Plugins Directory.

Step 1 – Installing Plugins

We need to be able to install a plugin from a .zip file easily, using a URL and extending it later to a git repository and a specific branch or tag. This would allow for easily downgrading plugins, for testing or troubleshooting.

Step 2 – Plugin Package Signatures

The primary method of installing a plugin would be a zip file; as such, we need to make sure the zip file hasn’t been tampered with; this is where package signing comes into play. Similar to how Debian and Ubuntu sign their packages, a similar method can be developed. If a mirror is taken over, and plugins modified, those plugins will fail signature checks. The same could be done with a git repository, if it’s taken over and code is modified, they will not be signed and will fail to install.

I won’t go into specifics; it’s not my area of expertise, and it requires more thought about how it’s designed and implemented. Scott Arciszewski talks about this in the following blog article.

Trust Rules Everything Around Me – Semantically Secure

As I write this, the most recent big move by Matt Mullenweg in his ongoing dispute with WP Engine was to abuse his position to seize control of a WP Engine owned plugin, justifying this act with a security fix. This justification might, under other circumstances, be believable. For example, if WP Engine weren’t actively…

scottarc.blog

Step 3 – Plugin Database

Lastly, we need a plugin index or plugin database. The plugin database will hold data about a number of plugins, its author, and where it can be downloaded. The plugin database can be downloaded and updated within your WordPress site. Once you have the index, you can then search for plugins within the database, verify its legitimacy by its signature, and eventually install it using the author’s mirror or a backup mirror if the package passes signature verification.

Step 4 – Plugin Registry Database

Unfortunately there are number of situations where a plugin is no longer suitable to be installed due to a number of reasons.

• Bad actors have taken over a plugin, either through purchase or hacking and have stolen signing keys.
• Plugin authors disappear due to a number of reasons and a plugin is left unmaintained, and as such security issues are not fixed.
• A plugin has a security issue, and the author hasn’t addressed it appropriately.

A plugin registry database can be used to achieve the following results.

• Block specific plugins from being returned in search.
• Block specific plugins from being installed, enabled and disabled manually.
• Notify of potential issues with plugins in many different categories, such as security, PHP compatibility, bad actor, and unmaintained.

The plugin registry databases are not controlled by a specific entity, anyone can create the databases, and they can be updated at any time. You can subscribe to multiple lists and pin databases over others. You can also create special rules to prefer one database over another.

I saw vendors already in the WordPress security space, such as Patchstack or WordFence, providing these plugin registry databases. They would also sign their databases on each release, and as such these can also be mirrored and distributed.

Step 5 – Local Caching

There are many self-hosters and small hosting companies that host many WordPress sites, and as such, having a local cache of WordPress plugins ensures that they’re able to provide redundancy to plugin updates and improve the speed of plugin updates. This will also ensure mirrors are hammered with requests and bandwidth.

Step 6 – Mirroring

With the above steps, mirroring is possible by anyone, either in their homeland or by Cloudflare. Setting up a DNS record, some small configuration, and running a docker container are all that is needed.

Conclusion

Having a limited amount of knowledge can be dangerous, and the above proposal could be missing many different scenarios or considerations. However, I still believe it’s a good starting point for improvement. I’m open to corrections to anything in this article.

Changelog

• Nothing yet.