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

Making WordPress.org noreply at wordpress.org
Thu Aug 6 17:08:40 UTC 2020


#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 Ipstenu):

 > * 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.

 That would be nice. Any plugin with other a million users for sure should
 be no-opt out. I understand what Chris' concern is, but I don't think
 allowing them to NOT click-to-approve will help that.

 > I think a really critical, and perhaps incorrect assumption that can be
 made, is that larger plugins == more employees === more committers.

 I thought the assumption being made was "More committers == more people
 who could approve a change." A plugin with 5 million users could still
 have one committer, and that's (terrifying but) fine. An email
 confirmation to push a new release in THAT scenario is that it could
 prevent a hacker from pushing code without permission.

 FWIW that actually did happen at least once. Someone's account was
 compromised and code was pushed.

 Anyway. I don't think requiring a second person to sign off is ideal
 globally. Maybe we should separate those?

 Thinking out loud here...

 1. We allow Opt-In click-on-email to approve new versions for all plugins
 2. Plugins over X installs are auto-opt-ed in, no opt out
 3. We allow OPT IN "submitter cannot self-approve a release."
 4. Plugins over X installs must opt OUT of submitter-cannot-self-approve
 UNLESS they're the only committer

 So we would have two options

 * Require confirmation to release new versions
 * Disallow self-approvals

 They're both 'opt in' for now, but eventually it would shift over. We
 could grey out the 'disallow' and not let it be checked if there's only
 one committer, and conversely could grey it out and not allow it to be UN
 checked if there are at least **5** committers and the plugin has over a
 million users or something.

 Yes, I said five committers. I got there by looking at
 https://wordpress.org/plugins/browse/popular/ and grabbing the 4mil+ user
 ones.

 * CF7 -- 1 committer: They would NOT need an alternate to sign off on
 release
 * Yoast SEO -- 5 committers: They would need an alternate to sign off
 * Akismet -- 5 committers: They would need an alternate to sign off
 * Classic Editor -- 1 committer: They would NOT need an alternate to sign
 off on release
 * Woo -- 15 committers: They would need an alternate to sign off
 * Elementor -- 3 committers: They would NOT need an alternate to sign off
 on release
 * Jetpack -- 9 committers: They would need an alternate to sign off
 * Really Simple SSL -- 2 committers: They would NOT need an alternate to
 sign off on release

 And just to grab one more....

 * Monster Insights -- 2 committers: They would NOT need an alternate to
 sign off on release

 I feel like this would allow us a little more flexibility, while still
 giving space for people who want to run a tighter shop with regards to
 deployment.

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


More information about the wp-meta mailing list