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?

We have the following requirements for implementing a plugin checksums command:

• After discussion in Slack #cli and in accordance with #14 we decided that the name for the command should be plugin verify-checksums.
• Development will be done in the wp-cli/checksum-command repository, with direct commits against the branch plugin-checksums.
• We might include an alias checksum plugin as well, although that is irrelevant to the current implementation.
• An endpoint has been prepared that the implementation can be coded against (See Meta Trac #3192 for related discussion). It was built to match the specification we provided.
• An example result of the endpoint can be fetched here: https://downloads.wordpress.org/plugins/test-plugin-3.1.1.2-20160302.checksums.json (The URL still needs to be adapted).
• An existing implementation (which goes beyond the scope of this current project) can be found at https://github.com/eriktorsner/wp-checksum. This can be used for inspiration, keeping in mind that it is much more complex than what we currently need.
• The command should be able to be run against individual plugins as well as --all plugins.
• A given file can return multiple hashes for a named version of a plugin. The array of hashes should be treated like a whitelist, and the file should pass if any sinlge one of the hashes is valid.
• The command should default to using the more secure sha256 and fall back to md5 if the environment does not support sha256 or if the checksum was not provided for sha256.
• Files can potentially have been added/deleted within a same named version of the plugin, so a file provided in the checksums but missing on the filesystem should not throw an error.
• Files in the filesystem that are not part of the checksums list should throw an error.

Feature Request

• Yes, I reviewed the contribution guidelines.

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.

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

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

  • Add phpcs.xml.dist file
  • Adapt .distignore to ignore phpcs.xml.dist & phpunit.xml.dist
  • Adapt .gitignore to ignore phpunit.xml, phpcs.xml & .phpcs.xml
  • Require version ^2.1 of the wp-cli/wp-cli-tests as a dev dependency

• Make 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

After wp-cli/wp-cli#4005 lands, we should revert 777016b

Feature Request

• Yes, I reviewed the contribution guidelines.

Use Case and Problem Faced

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.

Proposed solution

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.

Possible Disadvantages

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.

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?

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.

Feature Request

• [ ✅ ] Yes, I reviewed the contribution guidelines.

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:

1. Completed with 0 errors and 0 warnings.
2. Completed with 0 errors and 1+ warnings.

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:

1. Leave the default behaviour as-is, and have an optional -Werror flag, which converts warnings into errors.
2. Change the default behaviour to convert warnings into errors, and have an optional -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.

https://wordpress.slack.com/archives/C02RP4T41/p1557867276075100
I will make a PR if this would be useful for everyone 😎

Purpose

• (In my case) I wanted to ignore ./readme.html file cos we have always deleted the file
• And other cases like some files/dirs are moved by the security or management reason

An option

# 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.

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:

1. a flag that would allow pointing the request to an on network custom API which caches the checksum files or
2. adding the checksum files to the existing WP CLI cache directory

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?

@schlessera @gitlost

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!

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.

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

wp plugin verify-checksums already supports --format. wp core verify-checksums should too.

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.

Reproduction

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.

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?

The following changes need to be made:

1. In the .travis.yml file, the - composer behat line in the script: section needs to be changed into the following:

- composer behat || composer behat-rerun

2. In the 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"

3. In the 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:

Feature Request

• Yes, I reviewed the contribution guidelines.

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?

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?

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.

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.

Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

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.

• run wp core verify-checksums
• inspect output for exception error

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)

Feature Request

• Yes, I reviewed the contribution guidelines.

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.

Summary

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.

Steps to reproduce

1. Run command ‘wp plugin verify-checksums --all’
2. Run command ‘wp plugin verify-checksums --all --format=json’
3. Run command ‘wp plugin verify-checksums --all --format=csv’
4. Run command ‘wp plugin verify-checksums --all --format=count’
5. Run command ‘wp plugin verify-checksums --all --format=yaml’
6. Run command ‘wp plugin verify-checksums --all --format=table’
7. Observe the output of all six commands is identical.

Environment

• WP-CLI 1.5.1

Results and impacts

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.

As per wp-cli/wp-cli#4541, the documentation and success/error messages should use the full noun "installation".

Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

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.

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?

Feature Request

• Yes, I reviewed the contribution guidelines.

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.

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?

The following changes need to be made to move the command over to the v2 structure:

• Make sure the correct framework is required:

  composer require wp-cli/wp-cli:^2
  

• Require the testing framework as a dev dependency:

  composer require --dev wp-cli/wp-cli-tests:^0
  

• Use the .travis.yml file from wp-cli/wp-cli:

  wget https://raw.githubusercontent.com/wp-cli/wp-cli/master/.travis.yml
  

• Add the default script configuration to Composer file:

    "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"
        ]
    },
  

• Remove scaffolded binary files:

  git rm bin/install-package-tests.sh
  git rm bin/test.sh
  

• Remove scaffolded Behat setup:

  git rm features/bootstrap/*
  git rm features/extra/*
  git rm features/steps/*
  

• Remove scaffolded Behat tags util script:

  git rm utils/behat-tags.php
  

• Add command packages that are needed for Behat tests as --dev dependencies.
  The following commands are already available, anything else needs to be explicitly required:
  • cli *
  • config *
  • core *
  • eval
  • eval-file
  • help
• Update all dependencies:

  composer update
  

• Optional - Add PHPCS rule set to enable CS & compatibility sniffing:

  wget https://raw.githubusercontent.com/wp-cli/wp-cli/master/phpcs.xml.dist
  

• Run and adapt tests to make sure they all pass:

  composer test
  

When a plugin author bumps supported core version in readme.txt we get "Checksum does not match"

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.

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.

Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

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

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

Bug Report

• [x ] Yes, I reviewed the contribution guidelines.
• [x ] Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

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

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).

See wp-cli/wp-cli#4681

Should the files and folders ignored via .distignore be ignored in checksum verification?

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.

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.