Host checks.json - Githubissues

jkrehm commented 9 years ago

This isn't an issue so much as a thought. Since checks.json is the only way to determine if you have a faulty version of PHP, and checks.json is embedded in versionscan, a system admin won't get much benefit from versionscan because it'll likely be out of date (unless a developer has thought to update the dependency and go through the red-tape required to move it to production).

What if instead checks.json were available in "the cloud" (some HTTPS host) so you'd get the latest info regardless of whether composer update was run.

I've tried to think of what that would look like - Amazon S3 would be a possibility, but isn't HTTPS - but haven't come up with a solution. I just know that I (or more particularly, my clients) won't get as much benefit from versionscan as I'd like to because of the bottleneck that is us developers.

Any thoughts?

enygma commented 9 years ago

I'm a bit confused what you mean by "won't get much benefit" from the tool. Wouldn't they always get the correct information related to the current version they're running. Sure, if the checks.json is out of date, it's not as effective, but I'm not sure hosting it remotely is a solution either. That adds another dependency to requesting an external resource..hmmm....

jkrehm commented 9 years ago

I say "won't get much benefit" because if our server admins or client server admins stay up-to-date with PHP, but us developers aren't able to update versionscan regularly, the results won't have current vulnerabilities displayed.

So I guess what I'm really proposing is some sort of API. That got me thinking, so I went to look for such a thing and found one at CVEDetails.com. They have a JSON API-lite available via GET requests. I used JavaScript to scrape their ID's related to each PHP version and created a gist. With that you can take the PHP version number and translate it to the CVEDetails.com ID to create a request like this.

If I created some kind of implementation with that, is it something you'd be interested in? I think the information should be exposed for application caching, too, so we don't hit their site needlessly (my company's app has versionscan integrated into it, so we don't run the bin file separately).

jkrehm commented 9 years ago

I should clarify my last comment. More than admins being on a newer version of PHP, if a vulnerability is found in a version of PHP, that vulnerability won't display to the user until a developer updates versionscan. If an online source were used, the vulnerability would display as soon as that source is updated (likely faster than the tool is updated, because it's only data with no risk of breaking things). It's separating the tool from the data source.

enygma commented 9 years ago

Ah, that makes a lot more sense. Maybe it could be good to include the current checks as a *.dist kind of file if the need is there to keep things all local (never know for internal systems) and drop this updated version out somewhere. I can host it on one of my instances, then the system could be set up to cache the result..maybe for a week or two. I don't want to worry about any kind of notify system when it's updated, unless there becomes a real need for it.

xsist10 commented 9 years ago

You can specify a target version, so even if you need to run this on a development machine, you can still target the version on your server:

bin/versionscan scan --php-version=4.3.2

We could make the version scanner attempt check for a more up-to-date version of the checks.json file but we'd need to:

Add versioning to checks.json to ensure that, if the format changes we don't break the client (or at least inform the user to update their client).
Allow the user to disable this if they don't want their server making remote requests (for various security or network reasons).

colinodell commented 8 years ago

I really like the idea of providing an API. In the mean time, you could add the file as a custom Composer package: https://getcomposer.org/doc/05-repositories.md#package-2 (I'm doing something similar in league/commonmark - see lines 25 and 35-37 here).

Alternatively you could pull the raw file directly from Github: https://raw.githubusercontent.com/psecio/versionscan/master/src/Psecio/Versionscan/checks.json, if that's suitable for your project.

jkrehm commented 8 years ago

I ended up creating my own class to query CVEDetails.com. I don't know that they're the most up-to-date source (seem to lag by a couple releases), but neither are my company's clients, so eventually they get messages.

I have a gist of the class here. As it's written, It depends on Guzzle, but that could be refactored out.

lightswitch05 commented 5 years ago

I like the idea of having it pulled directly from github. Using github pages, it could even access the last modified time and only update when changes had been made. Having it being pulled from github pages, along with some automatic updating of checks.json, would make this a pretty powerful tool

psecio / versionscan

Host checks.json #11