WordPress.org

Make WordPress Core

Opened 7 months ago

Closed 6 months ago

#46615 closed defect (bug) (fixed)

Updates: No package signature can cause updates to fail

Reported by: pento Owned by:
Milestone: 5.2 Priority: high
Severity: major Version: 5.2
Component: Upgrade/Install Keywords: needs-testing has-patch
Focuses: Cc:
PR Number:

Description

It's currently not possible to update the WordPress nightly build from within the dashboard, as it fails a signature check.

Downloading update from https://wordpress.org/nightly-builds/wordpress-latest.zip…

The authenticity of wordpress-latest.zip could not be verified as no signature was found.

Installation Failed

The root cause of this appears to be WP_Upgrader::download_package() returning a WP_Error a soft signature check failure occurs. WP_Upgrader::run() correctly checks for the soft failure, Core_Upgrader::upgrade() does not.

This will likely also cause issues with plugins that rely on WP_Upgrader::download_package() to return the download package file name when it can continue, and a WP_Error when it cannot (example).

Attachments (4)

46615.diff (1.2 KB) - added by dd32 7 months ago.
46615.2.diff (3.9 KB) - added by dd32 7 months ago.
Note: untested
46615.2-2.diff (3.9 KB) - added by dd32 7 months ago.
46615.2.diff contained a logic error and simply disabled softfail rather than disabling signature verifications.
46615.3.diff (5.5 KB) - added by dd32 7 months ago.

Download all attachments as: .zip

Change History (24)

#1 @theKiwi
7 months ago

Yes - since sometime later in the day on 22 March 2019 EDT my site is also giving this error. Currently on WordPress 5.2-alpha-44976. I've attempted the update several times since but every time it fails.

Last edited 7 months ago by theKiwi (previous) (diff)

#2 follow-up: @bph
7 months ago

@theKiwi if you need to update your site - it seems via wp-cli it'll work. wp core update --version=trunk

This ticket was mentioned in Slack in #core by bph. View the logs.


7 months ago

#4 in reply to: ↑ 2 @theKiwi
7 months ago

Replying to bph:

@theKiwi if you need to update your site - it seems via wp-cli it'll work. wp core update --version=trunk

I have tried to install wp-cli on my Mac OS X server, but I'm out of my depth trying to get it to run - I get told

Parse error: parse error in phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Bootstrap/IncludeFrameworkAutoloader.php on line 34

Another thing I noticed - the last update time is wrong - it's back at the start of Unix time

Last checked on December 31, 1969 at 8:00 pm

I guess I'll wait a day or two and see if it "fixes itself" with a subsequent update.

Last edited 7 months ago by theKiwi (previous) (diff)

@dd32
7 months ago

#5 follow-up: @dd32
7 months ago

46615.diff copies the missing code from WP_Upgrader to Core_Upgrader.

Signatures for the nightly builds will also be available in the next few hours, so existing trunk installs will be able to update.

#6 in reply to: ↑ 5 ; follow-up: @dd32
7 months ago

Replying to dd32:

Signatures for the nightly builds will also be available in the next few hours, so existing trunk installs will be able to update.

Nightly signatures are now resolving. For those who had issues upgrading, you should now be able to.

#7 @dd32
7 months ago

  • Keywords has-patch added; needs-patch removed

#8 follow-up: @pento
7 months ago

@dd32: Nice work! Do you have thoughts on the second part of this problem?

This will likely also cause issues with plugins that rely on WP_Upgrader::download_package() to return the download package file name when it can continue, and a WP_Error when it cannot (example).

@dd32
7 months ago

Note: untested

#9 in reply to: ↑ 8 @dd32
7 months ago

Replying to pento:

@dd32: Nice work! Do you have thoughts on the second part of this problem?

This will likely also cause issues with plugins that rely on WP_Upgrader::download_package() to return the download package file name when it can continue, and a WP_Error when it cannot (example).

We're a little protected here in that currently a softfail is only returned for WordPress.org domains, so something updating from github for example wouldn't hit this scenario unless they'd enabled verification (or another plugin had).
I don't know how often a 3rd party updater would be calling WP_Upgrader::download_package() without also running it through WP_Upgrader::run(), That's really not something that should be done IMHO (Core_Upgrader is a.. special case).

However, there's also the case of someone calling download_url() directly for a WordPress.org domain (or other signed domain) where that is also now likely to return an unexpected WP_Error.

One options is to disable the signature verification for both WP_Upgrader::download_package() and download_url() by default as long as we're supporting a softfail. 46615.2-2.diff does that (But it's mostly untested).

Last edited 7 months ago by dd32 (previous) (diff)

@dd32
7 months ago

46615.2.diff contained a logic error and simply disabled softfail rather than disabling signature verifications.

#10 in reply to: ↑ 6 @theKiwi
7 months ago

Replying to dd32:

Replying to dd32:

Signatures for the nightly builds will also be available in the next few hours, so existing trunk installs will be able to update.

Nightly signatures are now resolving. For those who had issues upgrading, you should now be able to.

Yes, my site has now autoupdated twice today, so it seems to be fixed.

But it is still telling me that the last update check

Last checked on December 31, 1969 at 8:00 pm

rather than today's date.

Roger

#11 @pento
7 months ago

Thanks for testing this, @theKiwi!

On the update-core.php page, if you click the "Check Again" button, does the last checked date change?

#12 @pento
7 months ago

  • Priority changed from highest omg bbq to high
  • Severity changed from blocker to major

As we now have signatures on the nightly builds, I'm dropping the priority of this.

I like the direction 46615.2-2.diff is going, while folks probably shouldn't be hooking into the guts of the update API... this is WordPress. We should assume they are. 🙂

#13 @pento
7 months ago

In 45046:

Upgrades: Allow upgrades to proceed when a soft failure occurs on package signatures.

In particular, this allows downgrading from WordPress 5.2 to 5.1.1, if sites wish to opt out of the beta.

Props dd32.
See #46615.

@dd32
7 months ago

#14 @dd32
7 months ago

46615.3.diff is a rethinking of 46615.2-2.diff

  • download_url() and WP_Upgrader::download_package() will not attempt signature verification when the old syntax is used
  • 3rd party clients would then be unaffected by this change, even if they request a signed location
  • Other code written to use either of those functions, and accessing WordPress.org URLs would need to update to enable checking of signatures
  • When the Softfail is removed, we can either deprecate the new parameter, or flip it to checking by default

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


7 months ago

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


6 months ago

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


6 months ago

This ticket was mentioned in Slack in #core by chanthaboune. View the logs.


6 months ago

#19 @tellyworth
6 months ago

In 45262:

Upgrade/install: fix verification bugs and scale back signature checks.

This fixes several bugs in the signature verification code:
Disables signature checks on certain incompatible PHP versions that cause math errors when opcache is enabled;
Prevents a spurious URL and subsequent error when downloading a zip file with query arguments;
Prevents errors triggered by third-party upgrade scripts as per #46615;
Disables signature tests for Plugins, Themes, and Translations, leaving only core updates.

At the 5.2 release the API servers will only provide signatures for core update packages, which is why messages are suppressed for plugins and other package types. Signatures for those other items will become available later.

Props dd32.
See #39309, #46615

#20 @pento
6 months ago

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.