Making WordPress.org

Opened 2 years ago

Last modified 14 months ago

#5747 accepted task (blessed)

Block plugins using invalid `Update URI` headers

Reported by: dd32's profile dd32 Owned by: dd32's profile dd32
Milestone: Priority: high
Component: Plugin Directory Keywords: needs-patch
Cc:

Description

WordPress Core now supports the Update URI header for plugins, initial support was added to the update checks in r16912-dotorg, but now we need to ensure that Plugin updates served from WordPress.org never have that header set to either a) an invalid url or b) a URI which is not the W.org hosted plugin.

There are two benefits of the header:

  1. Plugins which are not hosted on W.org can state that, and a future plugin using the same slug won't override it
  2. The slug can be determined on W.org much easier, if the plugin defines it. We don't need to compare the slug/name/author/etc in order to find the right plugin.

The header formats which should be supported for hosted plugins should be either:

  • https://wordpress.org/plugins/$slug/
  • w.org/plugins/$slug
  • Not set

The first is the URL to the public page for the plugin, the second is the id attribute exposed in the update check response. The ID here once was the post ID but I changed it a few years ago.

Anything that is not those two formats, should cause the plugin import on WordPress.org to be aborted, and for that update to never be served from WordPress.org.

An example of this is, ACME Inc commits an update containing:

Plugin Name: ACME Widgets
Author: ACME Inc
Update URI: https://github.com/acme/widgets

That should NOT be packaged and/or served by WordPress.org, the commit should simply be ignored until corrected.

See https://core.trac.wordpress.org/changeset/50921 & r16912-dotorg for the API code

Change History (8)

#1 @dd32
2 years ago

  • Summary changed from Block plugins using `Update URI` to Block plugins using invalid `Update URI` headers

This ticket was mentioned in Slack in #docs by dd32. View the logs.


2 years ago

#3 follow-up: @joyously
2 years ago

Will it check that the slug given matches the slug of the plugin, so it's not pointing to another WP plugin?

#4 in reply to: ↑ 3 @dd32
2 years ago

Replying to joyously:

Will it check that the slug given matches the slug of the plugin, so it's not pointing to another WP plugin?

Yes, that's the intention of this paragraph, I assumed that it would be assumed that the $slug would be the given plugins slug.

The header formats which should be supported for hosted plugins should be either:

Last edited 2 years ago by dd32 (previous) (diff)

This ticket was mentioned in Slack in #meta by tellyworth. View the logs.


19 months ago

#6 @dd32
14 months ago

#6238 was marked as a duplicate.

#7 @dd32
14 months ago

  • Keywords needs-patch added
  • Owner set to dd32
  • Priority changed from normal to high
  • Status changed from new to accepted

#8 @dd32
14 months ago

The header formats which should be supported for hosted plugins should be either:

Just a note on this, If a WordPress.org plugin includes that header, it's actually useful for api.wordpress.org/plugins/update-check/ as it gets to skip a bunch of plugin-matching code and go straight to "Oh good, this plugin is XYZ" without having to do something like "The slug looks like XYZ.. the author is different.. the plugin name is XYZ.. it's probably XYZ".

Blocking it entirely is possible, and requested in #6238 which I'm not against.

Note: See TracTickets for help on using tickets.