Overnight, the Meta Team for WordPress.org flipped the switch for a new plugin author feature in the official directory. It allows plugin authors to opt into confirming plugin updates via email. Release confirmations will strengthen security and make sure any updates sent in are intentional.
Dion Hulse opened the original ticket six weeks ago with a detailed proposal and set of questions. WordPress 5.5 introduced automatic updates for plugin and theme authors. While auto-updates are completely opt-in for end-users, Hulse wanted to make sure that WordPress.org was on top of any potential disasters that may arise from the new system, such as accidental or even malicious plugin releases.
“I’d like to propose that we add an extra optional step into the release flow for plugins, not intended on adding friction, but intending to ensure that plugin releases only get made when they’re intended to,” he wrote. “A simple Email confirmation.”
At the moment, release confirmation via email is merely an opt-in feature that all plugin authors can take advantage of. However, the original proposal required it for high-usage plugins — there was never a definitive minimum install count that constituted “high usage” in the ticket.
The general agreement on how this feature should work seems to be:
- Opt-in for all plugin authors now.
- Forced opt-in and no opt-out for high-usage plugins soon.
- Opt-out for all other plugins in the future.
For larger plugins with multiple committers, there was some discussion on requiring confirmation from a separate committer who did not push the code live. This would essentially require two people to confirm that a plugin update is valid. This could potentially add to the friction that Hulse wanted to avoid in the original proposal. However, some friction for plugins with millions of installs might not always be such a bad thing. These plugins serve a massive user base and can damage WordPress’s reputation if a malicious actor gained commit access somehow. Having two people confirm an update is a good kind of friction in some cases.
However, requiring two-person confirmation is a more nuanced discussion that will need to happen. For example, Chris Christoff brought up examples in the ticket of not being able to send updates for plugins with two committers when one is on vacation or when the committers live in different time zones. Perhaps this will be an opt-in feature for plugin companies that choose to go this route in the future, depending on what fits their release flow best.
On the whole, the current implementation is a good starting position that will allow the community to iron out further details. This is about making WordPress more secure. If there is an extra step involved in publishing a code update, plugin authors should be on board with the process. Verifying the validity of a release sounds like a common-sense security feature. I would welcome WordPress.org making this a hard requirement — neither opt-in nor opt-out — in the long run after the feature has gone through a few rounds of real-world testing.
Theme developers do not have access to this feature at this time. However, the theme authors do not have access to SVN and must submit updates via a ZIP file. It is a much more manual process and should not be subjected to the same number of potential mishaps as plugin updates.
Enable email release confirmation form for plugin authors.
Plugin authors should now see a new administration option for each of their projects listed in the official plugin directory. The Danger Zone section of the Advanced View tab should display a new sub-section for enabling release confirmation emails. From there, authors merely need to click a button to turn them on.
It is important to note that, once enabled, release confirmation emails cannot be disabled from the same screen. Plugin authors are presented with the following notice before enabling the feature:
Warning: Enabling release confirmations is intended to be a permanent action. There is no way to disable this without contacting the plugins team.
Do not let the warning put you off if you are a plugin author. This is a good thing. Go ahead and enable it on at least one plugin if you want to test it first. I already have done so for one of my plugins. It is a simple process and helps add one additional layer of security over your plugins.
