Plugin Directory: Prevent adding new users/transfering ownership of FEATURED or BETA plugins

[Ipstenu]

Due to the high profile nature of those plugins, and the potential for abuse if a plugin is given to someone who turns out to be malicious, we should prohibit (technically speaking) a plugin with either the beta or featured flag from being transferred to another dev, or having devs added by themselves

Yes, this means the plugin team would have to do it, but it would protect us from potential malicious acts.

[Ipstenu]

#5733 was marked as a duplicate.

[dd32]

WIP of finer-grained caps

[dd32]

In 11744:

Plugin Directory: Introduce specific capabilities for various actions, rather than just using "edit access".

See #5654.

[dd32]

In 11745:

Plugin Directory: Introduce specific capabilities for various actions, rather than just using "edit access". Take two.

See #5654.

[dd32]

In 11746:

Plugin Directory: Display a "no-self-management" notice when a plugin is within the beta/featured categories.

[11744] included some code to require reviewer caps for plugins within those categories for certain actions:
https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/class-capabilities.php?rev=11744&marks=65-79#L61

See #5654.

[dd32]

In 11747:

Plugin Directory: Restore the $user variable which was inadvertantly moved during testing.

See #5654.

[dd32]

In 11748:

Plugin Directory: If no user is specified, or the user is logged out, short-circuit the plugin capability checks.

See #5654.

[dd32]

Just noting some tweaks that could maybe be done here:

• Allow plugins with Release Confirmation enabled to add/remove committers; especially if #5744 is implemented
• Allow the plugin author to add someone, but simply have it automatically email the plugins team + CC'ing all the existing committers for confirmation.

[Ipstenu]

You mean to use 'release' confirmation as a 'approve committer changes' confirmation too? I mostly like that, assuming the person who submits the change req is NOT the one who approves (i.e. no self-approvals) but at the same time, it could be a problem if two people decide to be evil together.

This is a rabbit hole :/

There should be a checkbox Plugin Admin can flag to say "This plugin is huuuuge but we trust them."

[dd32]

Replying to Ipstenu:

You mean to use 'release' confirmation as a 'approve committer changes' confirmation too?

Well, that's what #5744 is requesting. Personally I'm not sold either way :)

I was thinking that, adding a new committer for a plugin with release confirmation enabled doesn't allow them to push code... except that it does, they can make a new release, unless the double-sign-off is required.. So yeah.. Double-sign off OR not-the-committer sign off would be needed.

This is a rabbit hole :/

Agreed! I think maybe we can just leave this as-is.. So I'm going to close this ticket.