[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.
and
> 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
tag).
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