-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Show more CVE data when performing searches without --extract-cves #17
Labels
Comments
I think maybe I'll add an option that does something like (mockup):
|
Here's what I came up with:
And urls:
|
ryran
added a commit
that referenced
this issue
Nov 29, 2016
Fixed in rc8 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
So if I do a search like this:
The above data was generated by a single http request and altogether it took less than a second for
rhsecapi
to finish. As things stand now, if I want to print details about those CVEs, I need to use-s
/--extract-search
which will then kick off 102 additional http API requests. Thanks to multithreading, that doesn't need to take too long ... on my 4-core system with the default settings, I get:That said, it's still kind of wasteful when you realize that a lot of that data was already gathered (and discarded) in the very first http request. For example, here's the raw json (
--json
) returned for one of the CVEs -- i.e., this was returned with the very first request and then discarded after extracting only the CVE number:That's quite a lot of info we could use. Here's what we'd get if we did a full CVE lookup instead of a search:
So the question is really ... whether it makes sense to do anything with the search-result output even tho it's not the full picture. I mean the default IMHO should clearly be to ONLY print CVE numbers when doing searches, but we could give the option to print some extra minimal info ... but then from a usability standpoint, I'm not quite sure how to communicate that ... I feel like it could get confusing for users.
Hmmm. Have to ponder on this. And of course I welcome feedback.
The text was updated successfully, but these errors were encountered: