Making WordPress.org

Opened 3 years ago

Closed 22 months ago

#5654 closed enhancement (fixed)

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

Reported by: ipstenu's profile Ipstenu Owned by: dd32's profile dd32
Milestone: Priority: normal
Component: Plugin Directory Keywords:
Cc:

Description

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.

Attachments (1)

plugin-capabilities.diff (18.8 KB) - added by dd32 23 months ago.
WIP of finer-grained caps

Download all attachments as: .zip

Change History (11)

#1 @Ipstenu
3 years ago

#5733 was marked as a duplicate.

@dd32
23 months ago

WIP of finer-grained caps

#2 @dd32
23 months ago

  • Owner set to dd32
  • Status changed from new to accepted

#3 @dd32
23 months ago

In 11744:

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

See #5654.

#4 @dd32
23 months ago

In 11745:

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

See #5654.

#5 @dd32
23 months ago

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.

#6 @dd32
23 months ago

In 11747:

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

See #5654.

#7 @dd32
23 months ago

In 11748:

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

See #5654.

#8 @dd32
22 months ago

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.

#9 follow-up: @Ipstenu
22 months ago

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

#10 in reply to: ↑ 9 @dd32
22 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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.

Note: See TracTickets for help on using tickets.