Closed kelvinqian00 closed 7 months ago
Hi!
Thanks for the PR. I disagree on the change - if a nil
key is present, it should be honored, which here means failing fast and clearly.
So, users either set it to a valid value, or remove it, setting the NVD_API_TOKEN
env var.
I'd suggest undoing the design change and fixing the bug(s) only.
I enabled GH actions now.
Cheers - V
Hi @vemv,
Thanks for the clarification on your intent. Unfortunately I think your goal of failing fast on nil
values of :key
is problematic, since the scan automatically generates an nvd-clojure.edn
file with {:key nil}
. Thus, the user has a few choices:
nil
value with an API key; all well and good, but not straightforward in a context like automated CINVD_API_TOKEN
env var and manually delete the config file, which is also problematic in the above contextsNVD_API_TOKEN
env var and leave the config file alone, which currently fails "silently" (as highlighted in the issue) or, under your intent, fails fastThe point is, it is problematic in contexts where users cannot easily modify or remove the nvd-clojure.edn
config file.
Hi @kelvinqian00, sorry for the delay, I've had limited bandwith in the last few weeks.
I would not want to try forcing a specific direction - it's not a good use of our time.
I'll fix this directly in another branch asap.
(Bear in mind that there are workarounds that can be used as of today)
My sincere thanks for giving this a shot and trying to improve things!
Address the issue #173, in which the
NVD_API_TOKEN
variable does not work when the:nvd-api :key
value is present butnil
(which is the case with the default generated config file). I also verified that passing in the API key via the config file and as an env var both work by doing a localmake install
followed by a scan via clojure tools.Side note: For some reason when I run the integration tests locally they fail on the dogfooding config steps, even before I made any changes. It may be something funky with my local environment.