make --q-xxx options mutually-exclusive with --iava & --stdin & CVE (args)

[ryran]

Currently, you can do a --q-xxx search (with or without --extract-search) and at the same time pass some IAVAs or CVEs on the cmdline (or via stdin) ... they are handled completely separately.

This isn't intuitive and I don't see a use-case for the current behavior. You're either searching for CVEs or you have a list; you're not going to mix and match at the same time.

That said, I've made requests to have the API add a cve= parameter to the /cve? endpoint and also requested that it allows taking multiple args at once. Whenever that gets impemented, we can make it possible to use the --q-xxx options to narrow down specific CVEs from the cmdline by sev, date, etc, which would be pretty awesome.

[ryran]

Fixed in rc8

[ryran]

Perhaps we should reconsider this, even before the API gets updated to allow a cve= search param. Hmmm.

A colleague came to me with a use case: you have a big list of CVEs and you want to narrow down which ones affect a particular product and a particular package. You can use --product to get part of the way there, but then you'd just have to use grep. Alternatively you could use --q-product and --q-package but then you've got a superset of your list of CVEs.

We could add an --intersect-search option for clarity (or something else that conveys the idea of a venn diagram) -- this option would be mutually-exclusive with the --extract-cves option. Example:

rhsecapi --q-package=java-1.7.0-openjdk --q-product=linux.6 --intersect-search --stdin <somefile.csv

Until a new cve= param is added to the API, the implementation could be:

1. Perform search with single API call based on --q-xxx options and build list of CVEs returned
2. Build list of CVEs from input (stdin or cmdline args)
3. Build final list of CVEs to retrieve based solely on the CVEs that are in both lists
4. Retrieve that final list (single API call for each CVE)