Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#46615 closed defect (bug) (fixed)

Updates: No package signature can cause updates to fail

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

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 5 years ago.
46615.2.diff (3.9 KB) - added by dd32 5 years ago.
Note: untested
46615.2-2.diff (3.9 KB) - added by dd32 5 years 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 5 years ago.

Download all attachments as: .zip

Change History (24)

#1 @theKiwi
5 years 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 5 years ago by theKiwi (previous) (diff)

#2 follow-up: @bph
5 years 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.


5 years ago

#4 in reply to: ↑ 2 @theKiwi
5 years 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 5 years ago by theKiwi (previous) (diff)

@dd32
5 years ago

#5 follow-up: @dd32
5 years 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
5 years 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
5 years ago

  • Keywords has-patch added; needs-patch removed

#8 follow-up: @pento
5 years 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
5 years ago

Note: untested

#9 in reply to: ↑ 8 @dd32
5 years 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 5 years ago by dd32 (previous) (diff)

@dd32
5 years ago

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

#10 in reply to: ↑ 6 @theKiwi
5 years 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
5 years 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
5 years 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
5 years 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
5 years ago

#14 @dd32
5 years 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.


5 years ago

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


5 years ago

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


5 years ago

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


5 years ago

#19 @tellyworth
5 years 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
5 years ago

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