[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