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

Making WordPress.org noreply at wordpress.org
Wed Aug 5 16:02:55 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):

 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.

 Two major thoughts, and they're both around semver stuff :)

 First, I see a small drama with

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


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

 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.  That should (IMO) not require a sign off, but also should be
 'honored' and my zips should be rebuilt. Perhaps we could change that to
 the size of the change? A readme-change to bump the tested up to is fairly
 small, it should only be at most two readme.txt files (trunk and latest

 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.

 Also by using tags, you get the possibility of incorporating rollbacks
 later! See? Future us'es will be happy!

 Less major thought:

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

 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. I would prefer to see
 exceptions to it, personally, since if we could eventually make this a
 requirement, it's 'okay' to self-approve in some situations. Not everyone
 is always available to approve in a pinch, and not all dev-shops are
 created equal in size/performance/etc.

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

More information about the wp-meta mailing list