Opened 6 years ago
Closed 6 years 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: |
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)
Change History (24)
#2
follow-up:
↓ 4
@
6 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.
6 years ago
#4
in reply to:
↑ 2
@
6 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.
#5
follow-up:
↓ 6
@
6 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:
↓ 10
@
6 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.
#8
follow-up:
↓ 9
@
6 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 aWP_Error
when it cannot (example).
#9
in reply to:
↑ 8
@
6 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 aWP_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).
@
6 years ago
46615.2.diff contained a logic error and simply disabled softfail rather than disabling signature verifications.
#10
in reply to:
↑ 6
@
6 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
@
6 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
@
6 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. 🙂
#14
@
6 years ago
46615.3.diff is a rethinking of 46615.2-2.diff
download_url()
andWP_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
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.