[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  |  Resolution:
 Keywords:                    |
------------------------------+---------------------

Comment (by dd32):

 Replying to [comment:5 Ipstenu]:
 > It's opt IN? I'm in :)
 >
 > I would like to ''EVENTUALLY'' make it opt-out and not opt-in, as
 updates are a big deal and this would give folks an extra layer of
 protection. But I can fight for that one later.

 IMHO:
  - Opt-In for all ''for now''
  - Forced-Opt-In and no Opt-out for high usage plugins ''soon''
  - Opt-Out ''some day'' in the future.

 > Which is this. When a new version of WP is released, and I update my
 plugins, sometimes I ''only'' update the readmes in trunk and the latest
 tag.
 Let's be blunt, that's why I included `Yes, I know about Tested Up To
 we'll figure something out.` in point three.
 It's a silly scenario we find ourselves in where people ''need'' to change
 their readme's in `/tags/` to make these kind of changes, they shouldn't
 have to update the files that exist on sites just to flag that.

 I would rather find a way we can work around this, without changing ZIPs,
 because having multiple versions of a plugin out there with varied file
 hashes sucks. Off the top of my head:
  - Readme changes are allowed, but doesn't rebuild the ZIP
  - Readme changes are not needed, because `Tested up to` can be set
 somewhere else for the latest release (UI option?)
  - Directory Readme isn't included in plugins at all, and it's replaced
 with a document that links to the WordPress.org plugins page for further
 details (This won't be liked by some..)

 This is only complicated in my mind by the fact that sometimes people want
 to update a typo in their plugins readme without releasing a new version,
 or those who constantly change their tags to find the perfect tags to give
 them the most search ranking.

 > That should (IMO) not require a sign off, but also should be 'honored'
 and my zips should be rebuilt.
 It's not ''really'' about malicious changes (although that's part of it),
 it's more about `plugin.1.2.3.zip` changing and not being able to be
 cached for a long period of time. Just like how plugins that use `Stable
 Tag: trunk` don't get versioned zips and `plugin.zip` is both version 1.0
 and 2.0 depending on what point in time you access it. It's a caching and
 signing nightmare. (Yes, we can (and probably will) start to use
 `plugin.zip?v=$unique_version_id` as the url soon)

 > Second, what about people who use TRUNK as their stable tag? Can we
 detect that and require confirmation for ''every'' single push? While
 annoying to the developer, it would hammer home the gosh darn point of
 trunk is not meant like that, please use tags.

 Point 2: `initially I'm thinking they'll be required to use tags for
 releases, releases from trunk will no longer be an option`.

 The alternative is just as you've said, email on every commit.
 If a plugin wants the higher-level of security (and they should) they
 should do things the right way and use Tags! Thankfully only 15% of
 plugins with >= 100k active installs use trunk, but that's still not a
 small number.

 I'd almost prefer to remove the ability to release from `/trunk/`
 entirely, and instead, add a UI button for "Release version x.y" that
 Checked the trunk files versions were correct, tagged it for them, and
 then updated the trunk `Stable Tag` readme field for them.
 (That's complicated for other reasons, but I would totally support it and
 probably use it myself)

 > > 5. Ideally, the committer who committed the release would not be able
 to be the sole person who approves the release as well [....].
 >
 > As long as this is an "IF you are the only committer, you can sign off.
 ELSE you need someone else." Then yeah, that's okay. [....]

 Agreed. I think it should be opt-in as well. Having a single committer
 should not be a detriment to the author, and we shouldn't result in a
 state where every committer ultimately just has two accounts just to work
 it.
 I would like to have three states:
 1. No confirmation needed (initial default)
 2. 1 Confirmation needed (default for high-usage plugins eventually)
 3. 2 Confirmations needed (Opt-in, Committer cannot make the release alone
 but can be 1/2 confirmations)

 If it makes it easier, I'd even be willing to make the 3rd choice NOT be
 selectable via the UI, and it be something that only Plugin Admins can
 enable for a plugin, as long as they're aware it's an option.

 For example, I own plugin `ACME Inc Gallery` I'm a two-person agency, we
 opt-in to have this confirmation enabled and either of us can sign it off.
 We require 1 confirmation which can be either of us (So the Committer can
 self-release, or Person1 can commit and Person2 can do the Email
 confirmation when they come online later and verify the diff looked
 correct).

 `EMCA Inc Best Gallery` is our competitor, the owner doesn't trust any
 single individual because they believe I've infiltrated his employee pool
 and will destroy them from the inside out. They require 2 Confirmations,
 Person1 Commits, Person1 Confirms via email, Person2 Confirms it via
 email, and only once Person2 confirms it triggers the release to go out.

 Being able to opt-in for 2 confirmations rather than 1 is intended ONLY
 for those larger plugins that have enough people backing it, where no
 individual should be able to unilaterally decide to release an update that
 changes their plugins from embedding Cat pictures to embedding Dog
 pictures.

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