[wp-meta] [Making WordPress.org] #5352: Plugin Security - Add email confirmation prior to releases being processed

[Making WordPress.org]

#5352: Plugin Security - Add email confirmation prior to releases being processed
------------------------------+--------------------
 Reporter:  dd32              |      Owner:  (none)
     Type:  enhancement       |     Status:  new
 Priority:  normal            |  Milestone:
Component:  Plugin Directory  |   Keywords:
------------------------------+--------------------
 With auto-updates in WordPress 5.5 becoming as simple as a few mouse
 clicks, it's time to take a closer look at the Plugin Release flow, to
 mitigate potential disasters such as accidental and 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. A
 simple Email confirmation.

 How it would work:
  - A committer would be able to click a link in an email triggered by
 their commit that updated their `Stable Tag` value
  - That link would be a special page on the plugin repo (only accessible
 via the email link, that link would be timed so maybe 24hrs? expiring once
 used?)
  - That page would have a confirm button, that signifies the release is
 intentional (and not just an accident on a committers part, error on
 WordPress.org's part, and definitely not by someone else who had managed
 to spot the committers 64-digit crazy-random password by in a video from a
 WordCamp ..last year).

 This would be optional for most plugins, but required for high-usage
 plugins (after initial opt-in testing proved reliable). I'm not sure what
 cut-off point should be used for that, 1 Million installs? 100k installs?

 The plugins team would be able to bypass the release restrictions to
 approve a release in an emergency, but only when doing so through a secure
 tunnel (on WordPress.org, that's `is_super_admin()`). They would be the
 only ones who could disable this for a plugin as well once enabled.

 Multi-factor authentication (See #77) is often touted as a solution here,
 but this is intended on being larger than just protection against a single
 compromised account, consider this protection against malicious intent as
 well.
 By requiring that multiple people sign off on a release we can ensure that
 we only ship code to WordPress users that those who support a plugin
 intended on being released, and not just by an accident or disgruntled
 employee while everyone else is asleep.

 Implementation details and sticky points:
 1. This would be implemented by seeing the `Stable Tag` header change in
 the plugins readme.
 2. For plugins with it enabled, initially I'm thinking they'll be required
 to use tags for releases, releases from trunk will no longer be an option.
 This is so we can use the `Stable Tag` change as the trigger for
 confirmation.
 3. Changes to tags after the release is made will be forbidden (or at
 least ignored), that's so a malicious tag change is ignored. Yes, I know
 about `Tested Up To` we'll figure something out.
 4. Once opt'd in, only the plugins team can disable it for a plugin. This
 is to avoid a compromised account being able to disable it.
 5. Ideally, the committer who committed the release would not be able to
 be the sole person who approves the release as well, which would
 effectively make this always a 2+ person scenario. Maybe an exception
 would be the same person can sign it off, as long as it's not forcefully
 enabled for the plugin due to level of usage.
 6. The confirmation-of-release page would list all of the releases that
 are pending that the logged in user can approve (and the status of those
 releases), in order to make it easier on those who manage multiple plugins
 to bulk-approve releases at the same time.
 7. Only those who have been a committer on a plugin for >1 week should be
 able to sign off a release. (Also, Committers should know when a new
 committer is added - #5351)
 8. Commits to trunk would still be OK and not require sign-off as long as
 they don't alter `Stable Tag`, that allows for plugins to preload their
 strings into translate.wordpress.org or use it as their primary
 development platform.
 9. Release Pipelines and other tooling should remain unaffected, as long
 as they use tags for releases. Authors would have an extra email
 confirmation step, but that wouldn't break their release script I would
 hope.
 10. Email isn't perfect, and not all emails are received. That's going to
 be frustrating for authors and the plugins team alike, so perhaps we can
 allow a logged in user to trigger the email by an "admin alert" for a
 pending action on their plugin page, or if they follow an expired link.

 Thoughts? Have I missed something major here?

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/5352>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org