UpdateURI fails to prevent it's intended purpose

[edouble74]

Line:
​https://github.com/WordPress/WordPress/blame/ab357891753b86b192d6efd6713a3bca35fc8b76/wp-includes/update.php#L466

The isset( $updates->response[ $plugin_file ] ) check should not be present, as it defeats the purpose of UpdateURI and the original addition/commit ("This allows third-party plugins to avoid accidentally being overwritten with an update of a plugin of a similar name from the WordPress.org Plugin Directory.")

If there is already a response from the plugin check at ​http://api.wordpress.org/plugins/update-check/1.1/, the plugin with UpdateURI is skipped and therefore, the apply_filters( "update_plugins_{$hostname}"... is also skipped.

If a plugin author specifies an UpdateURI, this should always take precedence over a similar named plugin in the WordPress plugin repository

Commit:
​https://github.com/WordPress/WordPress/commit/9fbc705dc0740bdd2a4d80569f11e400520e599e

I can submit a pull request to ​https://github.com/WordPress/wordpress-develop if we can agree this is a bug

The isset( $updates->response[ $plugin_file ] ) check should not be present, as it defeats the purpose of UpdateURI and the original addition/commit ("This allows third-party plugins to avoid accidentally being overwritten with an update of a plugin of a similar name from the WordPress.org Plugin Directory.")

If there is already a response from the plugin check at ​http://api.wordpress.org/plugins/update-check/1.1/, the plugin with UpdateURI is skipped and therefore, the apply_filters( "update_plugins_{$hostname}"... is also skipped.

If a plugin author specifies an UpdateURI, this should always take precedence over a similar named plugin in the WordPress plugin repository

Trac ticket: https://core.trac.wordpress.org/ticket/57719#ticket

@SergeyBiryukov is there maybe a reason I'm not grasping in regard to the addition of the isset check?

[afragen]

When I test this by setting the local version of Akismet to 5.0 and adding Update URI: true to the headers, no update shows.

Are you seeing something different ?

[edouble74]

Replying to afragen:

When I test this by setting the local version of Akismet to 5.0 and adding Update URI: true to the headers, no update shows.

Are you seeing something different ?

After testing again, I now see that the server side repo endpoint response is filtering out elements with an UpdateURI. My mistake, I hadn't expected that behavior, and not sure now how I was getting a different result.

Still a bit confused as to how an update could then be present in isset( $updates->response[ $plugin_file ] ), but maybe its related to the older endpoint and backwards compatibility.

I'll do a bit of further testing and see if I can reproduce, but looks like we can close this.

Apologies!

Works as intended, I see that the update check endpoint on wordpress has filtered out the plugin that has Update URI

[SergeyBiryukov]

Hi there, welcome to WordPress Trac. Thanks for the follow-up!

[webdados]

I'm cross-commenting here the same I commented in #59631 as I believe is relevant for both tickets.

IMHO, setting the "Update URI" (to false for example), should deactivate any update or information request to the wordpress.org API.

On the wp_update_plugins routine, all the installed plugins are queried on wordpress.org, even if they're not part of the repo, and have specifically set Update URI as false (as mentioned here ​https://make.wordpress.org/core/2021/06/29/introducing-update-uri-plugin-header-in-wordpress-5-8/).

I suggest we make the "false" value on "Update URI" a clear instruction from the developer that the plugin does not belong to the repo and it should not be included in any API call whatsoever.

As we stand now, we might be creating serious confidentiality issues and even breaking the GDPR laws. If someone develops a private plugin for a company, there's not reason why .org should receive it's headers which may include information about the developer and the company that should not be shared by 3rd parties (in which case WordPress.org is the 3rd party).