wp-cli / checksum-command Goto Github PK
View Code? Open in Web Editor NEWVerifies file integrity by comparing to published checksums.
License: MIT License
Verifies file integrity by comparing to published checksums.
License: MIT License
The meta api allows for multiple checksums for a file by returning an array. e.g. for plugin wptouch version 4.3.22 the checksums for the file lang/wptouch.pot
are:
{
"md5": [
"ee40a33bff8f84acd1d3497e7bc2f32c",
"1ece63d7ab1970a349aeed4fb8737f9a"
],
"sha256": [
"dff12d0d154f72f1296f1ad614cc5c8cfd562ffe869e9d6171be95916838663c",
"0db91fb078011c813b6e0122823a08625a58a0474450782be17ee99c00939aed"
]
}
I've got a POC patch which fixes wp checksum plugin
- KrisShannon/checksum-command@5121fba - but it doesn't include tests and I think maybe the "are these two equal strings or is this a string in this array" logic should be separated into it's own utility function.
Describe the current, buggy behavior
Running wp core verify-checksums
fails when the .org API server times out and throws a RuntimeException
. A timeout should be handled gracefully, and an error or warning thrown instead. Here is the exception error.
Error: RuntimeException: Failed to get url 'https://api.wordpress.org/core/checksums/1.0/?version=+%276.0&locale=en_US': cURL error 28: Operation timed out after 10000 milliseconds with 0 out of -1 bytes received.
This was reported in the Slack #cli channel on June 30th. It was also noted the the URL version number contains extra characters but still returns the checksum payload.
Describe how other contributors can replicate this bug
NOTE: This will be difficult to replicate unless you can simulate the .org API server timing out because it works 99.99% of the time.
wp core verify-checksums
Describe what you would expect as the correct outcome
A warning (or error) should be returned instead of the command throwing an exception error.
Let us know what environment you are running this on
OS: Linux 3.10.0-327.18.2.el7.centos.plus.x86_64 wp-cli/core-command#1 SMP Fri May 13 02:05:28 UTC 2016 x86_64
Shell: /bin/bash
PHP binary: /usr/bin/php
PHP version: 7.4.30
php.ini used: /etc/php.ini
MySQL binary: /bin/mysql
MySQL version: mysql Ver 15.1 Distrib 10.1.48-MariaDB, for Linux (x86_64) using readline 5.1
SQL modes:
WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /home/oowygruc6apk5l7u4dxvchhjz/public_html
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.6.0
Could it be that wp core verify-checksums
causes
Error: 'verify-checksums' is not a registered subcommand of 'core'. See 'wp help core' for available subcommands.
in v1.5.1? (released just 3 days ago)
Should the files and folders ignored via .distignore
be ignored in checksum verification?
The following changes need to be made to move the command over to the v2 structure:
composer require wp-cli/wp-cli:^2
composer require --dev wp-cli/wp-cli-tests:^0
.travis.yml
file from wp-cli/wp-cli
:
wget https://raw.githubusercontent.com/wp-cli/wp-cli/master/.travis.yml
"scripts": {
"lint": "run-linter-tests",
"phpcs": "run-phpcs-tests",
"phpunit": "run-php-unit-tests",
"behat": "run-behat-tests",
"prepare-tests": "install-package-tests",
"test": [
"@lint",
"@phpcs",
"@phpunit",
"@behat"
]
},
git rm bin/install-package-tests.sh
git rm bin/test.sh
git rm features/bootstrap/*
git rm features/extra/*
git rm features/steps/*
git rm utils/behat-tags.php
--dev
dependencies.cli *
config *
core *
eval
eval-file
help
composer update
wget https://raw.githubusercontent.com/wp-cli/wp-cli/master/phpcs.xml.dist
composer test
Download last version WordPress
Upload to server by FTP
Upgrade database
Run command:
wp core verify-checksums
Warning: File doesn't verify against checksum: license.txt
Warning: File doesn't verify against checksum: wp-includes/images/crystal/license.txt
Error: WordPress installation doesn't verify against checksums.
Why a mistake?
The soft change detection currently only works for the file readme.txt
(case-sensitive): https://github.com/wp-cli/checksum-command/blob/master/src/Checksum_Plugin_Command.php#L339-L345
This detection needs to be more flexible, to cover all case variations as well as different endings (.md
).
While trying to use the --format
argument with the wp plugin verify-checksums
commands I found the output wouldn't change. I've tried all format options listed and none of them change the format outputted.
Severity – Moderate
Expected Results: Output in the format specified in the command line argument
Actual Results: The output does not follow the format specified.
This command has been incredibly useful to me in one off scenarios, but I can't use it effectively in scripts and Unix pipes without the option of a clean output format.
Hello,
Command : 'wp core verify-checksums'
It is impossible for me to recover the return of this order, it is directly displayed.
Output with choice of format for example, same as commande 'wp plugin verify-checksums'
Do you have an idea to solve this problem?
After wp-cli/wp-cli#4005 lands, we should revert 777016b
Describe your use case and the problem you are facing
Someone installed malware on my server. It came in two parts:
• modifying wp-includes/general-template.php
• adding temp/modules.php
wp core verify-checksums
caught the first case but not the second.
Describe the solution you'd like
Any unexpected files (outside wp-content) should result in an error.
I'm trying to ensure the integrity of the themes installed on my WordPress site. Currently, WP-CLI allows you to check the integrity of WordPress core files and plugins, but not themes. This is a problem because themes, like plugins, can be targets of attacks and compromise website security.
I would like WP-CLI to include a command to check the integrity of themes, similar to the wp --allow-root plugin verify-checksums --all command. This command, which could be something like wp --allow-root theme verify-checksums --all, would verify the theme files against the checksums provided by the official WordPress theme repository.
This command would help identify any theme files that have been modified or corrupted and could be a valuable tool in maintaining website security.
A potential disadvantage of this functionality is that it may not be able to verify the integrity of custom themes or themes that have been significantly modified. Furthermore, like any security tool, it is not foolproof and should not be used as the only line of defense against security threats.
Describe the current, buggy behavior
wp core verify-checksums (and I guess also for plugins) does not report all added files
Describe how other contributors can replicate this bug
# cd <path/to/wordpress>
# echo x > foo.php
# echo x > foo.txt
# sudo -u www-data wp core verify-checksums
Warning: File should not exist: wp-salt.php
Success: WordPress installation verifies against checksums.
(Does not list foo.php and foo.txt)
Describe what you would expect as the correct outcome
The list should contain foo.php and foo.txt as "files should not exist"
Let us know what environment you are running this on
OS: Linux webfe.akosv.com 3.13.0-147-generic #196-Ubuntu SMP Wed May 2 15:51:34 UTC 2018 x86_64
Shell: /bin/bash
PHP binary: /usr/bin/php5
PHP version: 5.5.9-1ubuntu4.29
php.ini used: /etc/php5/cli/php.ini
WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /var/www/wordpress/<snip>
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.1.0
After running wp core verify-checksums
on my WordPress 4.9.4 installation, the tool reports some files under my theme folder as 'Warning: File should not exist: wp-content/themes/MyTheme/includes/wp_booster/wp-admin/deeper/folder/some/file
'
I think that all theme files should be ignored when verifying core checksums. And the problem here seems to be the /wp-admin/
folder inside my theme.
The original rename is a decision I regret. Most WP-CLI commands are verbs, so we should make this a verb too.
These files are flagged as "should not exist" but are, in fact, ancient-but-valid files, retained sometime in the last century for backward compatibility.
wp-atom.php
wp-commentsrss2.php
wp-feed.php
wp-pass.php
wp-rdf.php
wp-register.php
wp-rss.php
wp-rss2.php
Rather than simply flagging them as superfluous, a better message would be "deprecated, can be deleted" which will
(1) properly prioritize the danger as 'low'; and
(2) offer a better solution (deletion) rather than the user creating even more automation routines to ignore the false positives.
Thanks for a great project, It very helpful to me in many cases.
I have to report you one thing i found in core verify-checksums
command behavior.
The wp core verify-checksums
command warns about added files which should not be exists,
but it doesn't matches files was added to ABSPATH directory.
Just add some file named like sample.php
to wordpress installation directory,
and run wp core verify-checksums
command. It won't show you any warnings about sample.php
file was added.
But if you move sample.php
into wp-includes
directory, then warnings will works fine.
I think it depends on filter_file
method at : https://github.com/wp-cli/checksum-command/blob/master/src/Checksum_Core_Command.php#L130-L135
Take a look please.
Thanks for your time.
A standard WordPress install contains a single file version of the Hello Dolly plugin called hello.php
.
The related plugin in the plugin repository is named hello-dolly
and is a subfolder with multiple files.
We need to provide a hardcoded edge case detection for this plugin.
The following changes need to be made:
.travis.yml
file, the - composer behat
line in the script:
section needs to be changed into the following:- composer behat || composer behat-rerun
composer-json
file, the requirement on wp-cli/wp-cli-tests
needs to be adapted to require at least v2.0.7
:"wp-cli/wp-cli-tests": "^2.0.7"
composer-json
file, the "scripts"
section needs to be extended. Immediately after the line "behat": "run-behat-tests",
, the following line needs to be inserted:"behat-rerun": "rerun-behat-tests",
Here's an example of how this should look like:
When a plugin author bumps supported core version in readme.txt we get "Checksum does not match"
wp plugin verify-checksums
already supports --format
. wp core verify-checksums
should too.
We use wp-cli in production on multiple very large sites to check for WordPress updates & watch for modified files via our monitoring system. We regularly run into an issue where wp core verify-checksums
takes many minutes to run, due to the fact that the code searches the entire website root recursively to make a list of files for the "File should not exist" check.
I know that there is already an open issue to add the ability to skip files which would help with this issue, but I believe that an easier solution for very large sites like ours would simply be to add a command line switch that would disable the "File should not exist" check entirely.
In our environment, we use a modified version of wp-cli with lines 106 through 114 of Checksum_Core_Command.php commented out, which works perfectly and the verify-checksums process takes just seconds to complete.
Since adding the ability to skip files is probably a larger and more far-reaching task (which comes with it's own downsides - for example, we would need to maintain a list of the subdirectories to skip), would it be possible to just have a flag to disable the "additional files" feature at runtime to at least satisfy the simple use case of not wanting all files recursively listed?
Thanks and thanks again for the hard work on this tool!
I've been using the plugin verify-checksums since the beginning of this year. My cron job checks all our wp sites everyday.
However, I've been receiving "Warning: Could not retrieve the checksums .." messages recently. It started about two weeks ago.
"core very-checksums" doesn't have the problem. Is there any problem with the wp checksum server? Or, is there any way to extend the timeout duration for waiting the response from the server? Please help.
Describe your use case and the problem you are facing
I have a Bash script which runs the following commands to check that the current WordPress installation has valid checksums, and then updates core, all plugins, and all themes.
#!/bin/bash
set -e
set -u
set -o pipefail
readonly WP_SITE=$1
readonly SITE_PATH=/srv/${WP_SITE}/public/htdocs
if [ ! -d ${SITE_PATH} ]; then
echo "Site path does not exist: ${SITE_PATH}"
exit 1
fi
/usr/bin/php ${HOME}/bin/wp-cli.phar core verify-checksums --path=${SITE_PATH} --quiet
/usr/bin/php ${HOME}/bin/wp-cli.phar core update --path=${SITE_PATH} --quiet
/usr/bin/php ${HOME}/bin/wp-cli.phar plugin update --all --path=${SITE_PATH} --quiet
/usr/bin/php ${HOME}/bin/wp-cli.phar theme update --all --path=${SITE_PATH} --quiet
I've deliberately set set -e
so that if any of the commands return a non-zero exit code, the script should terminate. For example, if verify-checksums
fails then I don't want to proceed to update core.
The difficulty I'm having is that verify-checksums
has different exit codes depending on whether warnings or errors are encountered:
Errors: Non-zero exit code
Warnings: Zero exit code
This means that there's no easy automated way to determine between two possible outcomes:
In general I consider warnings to be as serious as errors, because they often indicate wider problems or hidden bugs.
Describe the solution you'd like
I'd like a command line flag that converts warnings into errors, and therefore makes verify-checksums
return a non-zero exit code if there are any warnings. For example, the gcc
command has an option for this (from the man page):
-Werror
Make all warnings into errors.
There are two possible ways of implementing this:
-Werror
flag, which converts warnings into errors.-Wno-error
flag, which overrides this behaviour and doesn't convert warnings into errors.Personally I think the first option is the safest, as it doesn't change the default behaviour which people might be relying on, and the documentation would not have to be updated to reflect this.
I'm happy to look into extending verify-checksums
to add this behaviour, however I want to check first whether other people think this is a good idea and would in principle be something that's likely to be merged - subject of course to any pull request meeting the contribution guidelines etc.
Describe the current, buggy behavior
wp-cli --allow-root core verify-checksums --include-root
Error: Parameter errors:
unknown --include-root parameter
wp-cli --allow-root --include-root core verify-checksums
Error: Parameter errors:
unknown --include-root parameter
same for
wp-cli --allow-root core --include-root verify-checksums
Describe how other contributors can replicate this bug
see above
I installed the latest version (3.2.2) of https://wordpress.org/plugins/duplicate-post/ to my WordPress. While running plugin checksum with cli version 1.5.1 I get the following error:
| duplicate-post | duplicate-post-jetpack.php | File is missing |
| duplicate-post | duplicate-post-wpml.php | File is missing |
Those files are indeed missing, but they are not in the original plugin zip either. It seems that they've been moved into compat/ folder a few releases ago.
It seems that https://downloads.wordpress.org/plugin-checksums/duplicate-post/3.2.2.json still returns those two moved files and their checksums in the root of the plugin. Could there be some issue in the cheksum endpoint so that it keeps deleted files in it even though they do not exist anymore?
Edit:
Also it seems that https://downloads.wordpress.org/plugin-checksums/duplicate-post/3.2.json does not return those two missing files and their checksums at all.
Describe the current, buggy behavior
Dear developers,
since a week or two the plugin checksum command has been behaving erratically. It displays "Could not retrieve the checksums for version x.y.z of plugin-name" for a lot of plugins. The set of plugins that can't be checked seems to be random - if you rerun it, some other plugins can't be retrieved. I can reproduce the problem on two different servers, PHP 7.4/8.0.
Describe how other contributors can replicate this bug
wp plugin verify-checksums --all --path="/path/to/wp"
Let us know what environment you are running this on
OS: Linux 5.4.0-121-generic #137-Ubuntu SMP Wed Jun 15 13:33:07 UTC 2022 x86_64
Shell: /bin/bash
PHP binary: /usr/bin/php7.4
PHP version: 7.4.3
php.ini used: /etc/php/7.4/cli/php.ini
MySQL binary: /usr/bin/mysql
MySQL version: mysql Ver 15.1 Distrib 10.3.34-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
SQL modes:
WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /home/user
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.6.0
Provide a possible solution
I believe that the https://downloads.wordpress.org/plugin-checksums/ API limits have been changed and the script is now hitting into "429 Too Many Requests" error.
Best regards,
Andrej
Describe your use case and the problem you are facing
I execute:
$ wp plugin verify-checksums --all
Warning: Could not retrieve the checksums for version 2.2.63 of plugin borlabs-cookie, skipping.
Warning: Could not retrieve the checksums for version 3.13.1 of plugin elementor-pro, skipping.
Warning: Could not retrieve the checksums for version v1.1 of plugin swpm-custom-post-type-protection-enhanced, skipping.
Warning: Could not retrieve the checksums for version v1.8 of plugin swpm-full-page-protection, skipping.
Warning: Could not retrieve the checksums for version 2.1 of plugin swpm-show-member-info, skipping.
Warning: Could not retrieve the checksums for version 3.13.2 of plugin wp-rocket, skipping.
+-------------------------------------+----------------------------------------+-------------------------+
| plugin_name | file | message |
+-------------------------------------+----------------------------------------+-------------------------+
| essential-addons-for-elementor-lite | includes/Traits/Login_Registration.php | Checksum does not match |
| imagify | ovqIf.js.php | File was added |
| imagify | CGCrs.js.php | File was added |
| imagify | .e6f098fc.mo | File was added |
| loco-translate | yA.js.php | File was added |
+-------------------------------------+----------------------------------------+-------------------------+
Error: Only verified 18 of 27 plugins (3 failed, 6 skipped).
It says 3 plugins failed, but I am not sure which those are. I can't even figure out using `--debug?
Describe the solution you'd like
The failed plugins should be listed, if possible with the reason.
Describe your use case and the problem you are facing
For wp core verify-checksums
the --version
option is available to specify WP core version.
This is very useful in a deploy (update) process to check if the codebase is on the expected version.
If verify returns success, then skip download and/or report no change, if verification fails then download the right (usually newer) version. So it's possible to create an idempotent process.
It would be great to apply this logic to plugins also!
Describe the solution you'd like
Adding a --version
option to plugin verify-checksums
where we could directly set the version not just getting that from the plugin.
Of course, this would make sense only if a single plugin is provided, but this can be handled by ignoring --version
if --all
or multiple plugins are passed in.
Note: I'm happy to submit a PR.
Our website got hacked, and an extra <script> line was added to the header.php:
wp-content/themes/astra/header.php:<script src='https://cdn.scriptsplatform.com/scripts/header.js' type='text/javascript'></script><?php
I didn't see any way of checking theme checksums directly,
and the core verify-checksums only warned me about extra files that should not exist (like wp-admin/error_log and wp-admin/.rnd)
I tried --debug flag but it didn't mention anything about iterating through themes either.
Surely there is a way to verify themes haven't been modified?
Hi,
I have premium external plugins. As we know, it is currently unable to check their checksums.
So there is a note:
Warning: Could not retrieve the checksums for version x.x.x. of plugin advanced-custom-fields-pro, skipping.
I would like to get rid of this message so I try to use:
wp plugin verify-checksums --all --skip-plugins=advanced-custom-fields-pro
After using this command, this warning still exists Could not retrieve the checks....
What i did wrong?
Describe your use case and the problem you are facing
I am using wp core verify-checksums
as a cron job to check the checksums every night.
I have some additional files that are returned as Warning
, eg.:
Warning: File should not exist: wp-admin/.htaccess
Warning: File should not exist: wp-includes/.htaccess
Warning: File should not exist: wp-config-external.php
Success: WordPress installation verifies against checksums.
I create daily e-mail reports based on what this command returns, so these warnings are problematic. I currently workaround this with the sed
command, but it would be much better if there was a flag such as --exclude
.
Describe the solution you'd like
wp core verify-checksums --exclude=<file>
What do you think? Is this even possible?
I got these two lines from the wp checksum plugin
command:
| hummingbird-performance | externals/shared-ui/font/WPMU | File is missing |
| hummingbird-performance | externals/shared-ui/font/WPMU DEV Dashboard.json | File was added |
I downloaded the zip file to make sure and externals/shared-ui/font/WPMU DEV Dashboard.json
was in the zip file and there was no externals/shared-ui/font/WPMU
Improve short description in https://github.com/wp-cli/checksum-command/src/Checksum_Command.php
wp checksum | Verify WordPress core checksums.
Proposed:
Compares the site’s core files with core at WordPress.org (via checksums).
cc: @hearvox
As per wp-cli/wp-cli#4541, the documentation and success/error messages should use the full noun "installation".
Hey guys,
I'd like to run the checksum commands against a large number of sites with some frequency. I notice that each time the core command is run or each plugin that is encountered requires an external request to wordpress.org
. I'd like to cut down on the number of external requests and feel there are two options:
How receptive is this repo to a PR to introduce one or both of these options? Do you have any guidance or suggestions about how you would prefer this to look?
https://wordpress.slack.com/archives/C02RP4T41/p1557867276075100
I will make a PR if this would be useful for everyone 😎
# Proposal
wp core verify-checksums --ignore-files='readme.html wp-includes/some-filename.php'
I would be happy if someone kindly suggests it should be --ignore-files
or --skip-files
or --excludes
.
Hi,
I have a Composer-managed project, so I require only WP-CLI commands that I need for the project:
"wp-cli/db-command": "^2.0",
"wp-cli/entity-command": "^2.0",
"wp-cli/checksum-command": "^2.0"
However, when I run ./vendor/bin/wp core verify-checksums
, I get:
Error: 'core' is not a registered wp command. See 'wp help' for available commands.
Shouldn't wp-cli/core-command
be a dependency, when the core
command is required for verify-checksums
to run?
Recently I had to investigate on a hacked WP website and I used WP CLI checksum command to verify the integrity of the WP install. At the end I discovered a malicious file named wp-blog.php
in the WP root folder of the site, but I was really surprised that wp checksum core
did not detect it with a "Warning: File should not exist". It seems that this kind of warnings are triggered only for files in subdirectories.
I believe it would be very important to also check for unexpected files in the root folder, as it's a common place where hackers could store malicious files with filenames similar to genuine ones.
Hello,
is there a plan to support non free plugins? It could be done the way that someone sets up an own webservice to provide the according json with the checksum.
https://github.com/wp-cli/checksum-command/blob/master/src/Checksum_Plugin_Command.php#L19
Maybe url_templates could be used to configure an array with priorities to get the checksum information from.
Within the own webservice the paid plugins could be uploaded as zip. Unpacking and generating the checksums needs to be done by a loop. But maybe this service is out of scope of this plugin. However it would be great to be able to configure an own or better additional url_template to verify checksums from.
Cheers
Andi
As discussed in #26 (comment) , the plugin checksum verification currently ignores must-use plugins.
Should these be checked by default? ... or only through an additional flag?
I think I'd prefer to have them be included in the checks by default, with a flag to omit them if they should cause trouble.
We have a new PHPCS standard for WP-CLI called WPCliCS
(props @jrfnl). It is part of the wp-cli/wp-cli-tests
package starting with version v2.1.0.
To adopt & enforce this new standard, the following actions need to be taken for this repository:
Create a PR that adds a custom ruleset phpcs.xml.dist
to the repository
phpcs.xml.dist
file.distignore
to ignore phpcs.xml.dist
& phpunit.xml.dist
.gitignore
to ignore phpunit.xml
, phpcs.xml
& .phpcs.xml
^2.1
of the wp-cli/wp-cli-tests
as a dev dependencyMake any required changes to the code that fail the checks from the above ruleset in separate PRs
Merge thre ruleset once all required changes have been processed and merged
A sample PR for a simple repository can be seen here: https://github.com/wp-cli/maintenance-mode-command/pull/3/files
Related wp-cli/wp-cli#5179
We have the following requirements for implementing a plugin checksums command:
plugin verify-checksums
.wp-cli/checksum-command
repository, with direct commits against the branch plugin-checksums
.checksum plugin
as well, although that is irrelevant to the current implementation.--all
plugins.sha256
and fall back to md5
if the environment does not support sha256
or if the checksum was not provided for sha256
.Recently ran into a situation where a website had malware reinfection issues which required a bit of a deep dive to resolve. During the process I discovered that wp plugin verify-checksums --all
will only check plugins which have their main plugin.php
file. For example, let's install a plugin then break the main file by renaming:
wp plugin install wordfence
mv wp-content/plugins/wordfence/wordfence.php wp-content/plugins/wordfence/wordfence.php.bad
Now if we try and run wp plugin verify-checksums wordfence
we'll get the following:
Warning: The 'wordfence' plugin could not be found.
Error: You need to specify either one or more plugin slugs to check or use the --all flag to check all plugins.
Also if we run wp plugin verify-checksums --all
it will say success
and not even attempt to run any checks on the /wordfence/
directory. This is a problem as bad actors can use this method to hide files in these shadow plugin folders. Also there is no indication that these PHP files exist from /wp-admin/plugins.php
.
I think the solution should be to run checksums verifications based solely on the directory names. If a plugin directory matches a wordpress.org plugin then maybe run the verification checks?
We install wordpress using the wp cli (wp core install; wp language core install de_DE ). After some time admin users upgrade wordpress to the latest release using the gui or we use the wp cli to update it.
In both cases we often get this error message if we validate the checksum:
$ wp core verify-checksums
Warning: File doesn't verify against checksum: wp-config-sample.php Error: WordPress install doesn't verify against checksums.
In this case the wp-config-sample.php is localized with German comments. There are also other German files like liesmich.html:
www-data@ip-10-18-33-110:/data/backend/wordpress$ ls -la
total 232
drwxr-xr-x 5 www-data www-data 4096 Dec 20 08:25 .
drwxr-xr-x 3 www-data www-data 4096 Dec 4 11:31 ..
-rw-r--r-- 1 www-data www-data 418 Dec 4 11:31 index.php
-rw-r--r-- 1 www-data www-data 32 Dec 4 11:31 install.txt
-rw-r--r-- 1 www-data www-data 19935 Dec 18 11:09 license.txt
-rw-r--r-- 1 www-data www-data 8729 Dec 18 11:09 liesmich.html
-rw-r--r-- 1 www-data www-data 7415 Dec 20 01:30 readme.html
-rw-rw-r-- 1 www-data www-data 32 Dec 5 03:15 update.txt
-rw-r--r-- 1 www-data www-data 6878 Dec 13 03:35 wp-activate.php
drwxr-xr-x 9 www-data www-data 4096 Dec 18 11:09 wp-admin
-rw-r--r-- 1 www-data www-data 364 Dec 4 11:31 wp-blog-header.php
-rw-r--r-- 1 www-data www-data 1889 Dec 4 13:30 wp-comments-post.php
-r--r--r-- 1 www-data www-data 5055 Dec 4 11:31 wp-config.php
-rw-r--r-- 1 www-data www-data 3636 Dec 18 11:09 wp-config-sample.php
drwxr-xr-x 8 www-data www-data 4096 Dec 19 15:19 wp-content
-rw-r--r-- 1 www-data www-data 3669 Dec 4 11:31 wp-cron.php
drwxr-xr-x 19 www-data www-data 12288 Dec 18 11:09 wp-includes
-rw-r--r-- 1 www-data www-data 2422 Dec 4 11:31 wp-links-opml.php
-rw-r--r-- 1 www-data www-data 3306 Dec 4 11:31 wp-load.php
-rw-r--r-- 1 www-data www-data 37296 Dec 18 11:09 wp-login.php
-rw-r--r-- 1 www-data www-data 8048 Dec 4 11:31 wp-mail.php
-rw-r--r-- 1 www-data www-data 17421 Dec 18 11:09 wp-settings.php
-rw-r--r-- 1 www-data www-data 30091 Dec 4 13:30 wp-signup.php
-rw-r--r-- 1 www-data www-data 4620 Dec 4 11:31 wp-trackback.php
-rw-r--r-- 1 www-data www-data 3065 Dec 4 11:31 xmlrpc.php
Using the locale option I get this error:
$ wp core verify-checksums --locale=de_DE
Error: Couldn't get checksums from WordPress.org.
I would be great to have an option in ignore locale specific checksum errors.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.