ssnepenthe / soter-command Goto Github PK

from ssnepenthe/soter#3.

Allow user to ignore packages when using commands that check multiple against wpvulndb.com.

Plugin and theme commands accept a space-separated list of slugs.

To stick with the WP-CLI philosophy of "composability is always a good idea" it would be nice if bulk commands were able to output a list of vulnerable package slugs.

--format=ids already does something similar, but it is for vulnerability IDs and so is not useful in this particular case.

Maybe we could add a custom --format=slugs?

Alternatively - consider --format=porcelain or just--porcelain.

Of note - some of the core commands (like https://github.com/wp-cli/entity-command) allow for a --porcelain flag which just outputs the ID of the entity that is the subject of the command.

Instead of transients.

See WP_CLI::get_cache().

Currently it returns all vulns that have ever affected the package.

An alternative to consider (at least for plugins and themes) would be to grab the latest_version from the API response and check for vulns on that version.

From ssnepenthe/soter#12.

Not sure whether or not this should be changed.

v3 requires an authorization token for all requests.

This should be updated once ssnepenthe/soter-core#13 is closed.

Could be stored in the options table or maybe better as a file under ~/.wp-cli.

Primary goal would be to allow user to override defaults for command options:

Would need add, remove, set and unset commands to go with it.

Something like wp soter update-vulnerable - would be great for a system cron job to ensure any security issues are automatically addressed.

Then again, core already handles automatic security updates - maybe this is just wasted time?

An alternative might be to implement a list format or porcelain like in wp-cli/entity-command that just prints a list of slugs which could be piped to various update commands... The problem (at least as far as I can tell): there is no master command for updating everything so you would have to run once each for plugins, themes and core.

Similar to the hooks available in the soter plugin.

It would provide a simple way for plugins to perform custom actions (logging, mailing, etc.) based on the results of a check.

Or maybe the expectation should be that since we are running from the command line, results can already be piped elsewhere so there is no need for plugins to be able to extend...

For example - a custom plugin will result in a 404 from wpvulndb.com. It would be nice to be able to notify the user as a reminder to flag it as ignored in the future.

From ssnepenthe/soter#4.

Consider extracting one or more dedicated formatter classes.

Currently:

$ wp soter check-plugin contact-form-7 --format=yml --fields=title,created_at

---
-
  title: 'Contact Form 7 <= 3.7.1 - Security Bypass'
  created_at:
    date: 2014-08-01 10:59:06.000000
    timezone_type: 2
    timezone: Z
-
  title: 'Contact Form 7 <= 3.5.2 - File Upload Remote Code Execution'
  created_at:
    date: 2014-08-01 10:59:07.000000
    timezone_type: 2
    timezone: Z

$ wp soter check-plugin contact-form-7 --format=json --fields=title,created_at

[{"title":"Contact Form 7 <= 3.7.1 - Security Bypass","created_at":{"date":"2014-08-01 10:59:06.000000","timezone_type":2,"timezone":"Z"}},{"title":"Contact Form 7 <= 3.5.2 - File Upload Remote Code Execution","created_at":{"date":"2014-08-01 10:59:07.000000","timezone_type":2,"timezone":"Z"}}]

$ wp soter check-plugin contact-form-7 --format=csv --fields=title,created_at

title,created_at
"Contact Form 7 <= 3.7.1 - Security Bypass","{""date"":""2014-08-01 10:59:06.000000"",""timezone_type"":2,""timezone"":""Z""}"
"Contact Form 7 <= 3.5.2 - File Upload Remote Code Execution","{""date"":""2014-08-01 10:59:07.000000"",""timezone_type"":2,""timezone"":""Z""}"

->display_results() prints a success message and exits if there are no vulnerabilities.

Since soter_command_{$command}_results is triggered after results are displayed, it won't actually be triggered when there are no vulnerabilities.

Ex:

public function get_plugins( $ignored = [] ) {
    $plugins = WP_CLI::runcommand( 'plugin list --fields=name,version --format=json', [
        'parse' => 'json',
        'return' => true,
    ] );

    // Filter ignored.

    // Map to Soter_Core\Package instances.

    return $plugins;
}

Not sure there is much benefit here aside from staying within WP-CLI...