ssnepenthe / soter-core Goto Github PK

Verify nothing breaks

Vulnerability 8958: The vulnerability was reported against the bbPress plugin but the fix came from WP core.

Since there is no "fixed in" version on the bbPress API response, this vulnerability will always be returned by the ->vulnerabilities_by_version() method.

WP package manager test is the only one that relies on WP_Mock

The pluck method uses wp_list_pluck

v3 requires an authorization token for all requests.

Not sure if support for v2 should be removed completely or support for both should be maintained...

Instead of injecting the package slug, consider using the full package instance so we get type and version.

Ref. ssnepenthe/soter#21.

If do_action() is called with an array containing a single object, that object is passed directly to callbacks instead of the array.

This leads to a situation where a listener can never be certain of the type of $vulnerabilities and must add extra checks.

So - it might be nice to have a collection object that can be used to wrap the array of vulnerabilities.

Is it even worth pretending to support PHP 5.3 at this point?

WP_Mock@dev-dev is required as a dev dependency - As of the latest commit to soter-core this put us at ~0.2.x which required PHP5.6+. Currently, it would pull ~0.3.x which requires PHP7+.

All that to say that it is unlikely this package will ever be properly tested below PHP5.6 going forward, and maybe not even below 7.0.

Alternatively - consider introducing a tool such as https://github.com/wimg/PHPCompatibility to avoid simple issues such as this in the future.

They are really only needed where you might want to create an alternate implementation for use outside of WordPress.

Keepers (and their likely implementations):

• Package manager interface (wp, composer)
• Http interface (wp, curl/requests lib?)
• Cache interface (transients, file, etc)

Instead of calling do_action() directly, add a generic event system that can be used outside of WordPress.

Something external like event and event dispatcher interfaces?

Or maybe just methods on the checker instance like add_post_check_callback() and do_post_check_callbacks()?

The WP_Http_Client class throws an exception in the event of a WP_Error response.

The Api_Client class catches this and converts it to an error Api_Response instance.

The Api_Response class provides a method for checking whether or not there is an error.

However - The Checker class calls $response->get_vulnerabilities_by_version() without checking for errors. In the event of an error, an empty array is returned.

So basically if the HTTP request fails, the checker is unaware and assumes that no vulnerabilities were detected.