search

rm-hull / nvd-clojure

National Vulnerability Database dependency checker for Clojure projects
MIT License
275 stars 36 forks source link

Continuation of discussion from issue #142... #145

Closed pmonks closed 2 years ago

pmonks commented 2 years ago

For some reason I'm unable to comment on issue #142 any longer, and I don't know how else to respond to the questions I was asked. I'd strongly encourage this comment to be added there, and this issue deleted by those with permission to do so.

Why? Generally a CI pipeline can do whatever you tell it to. Or you can work around a bash script invoked from your project root dir, which performs a cd within it.

This logic isn't in a shell script - it's in Clojure, and that logic needs access to the project's deps.edn file in order to calculate the classpath to pass to nvd-clojure. The example you've provided (and which I saw in the docs too) is great, but not applicable when NVD is not being run from a shell script.

From what I know, Tools can be cached, just like e.g. Maven artifacts are cached (via their .m2 dir).

CI environments (or at least the one I'm using) don't persist filesystem state across invocations, so there is no notion of a cache here. And again, that's not relevant as this logic is written in Clojure, not shell script (though I suppose there might be a public tools.deps API for installing and running a Tool from Clojure code? I haven't looked.).

Ultimately you can build an "uberjar" of nvd-clojure / its dependencies and run it through vanilla java. From our side, we won't do that, as distributing what essentially is a blob isn't quite apt for a security offering.

I could. Or I could temporarily rename the deps.edn file before invoking nvd-clojure. Or I could use clojure.java.shell/sh to fork a separate Clojure instance for nvd-clojure in a different directory, rather than trying to run it "inline" with my own logic. Or any number of other workarounds that I'm currently evaluating.

Ultimately if the Clojure CLI tools provided a way to completely ignore any deps.edn files in the current directory, and only used -Sdeps instead, this would be a non-issue. Clearly this is not an nvd-clojure issue.

vemv commented 2 years ago

This logic isn't in a shell script - it's in Clojure

Clojure can run commands from a different pwd via clojure.java.shell/sh (as you point out below)

CI environments (or at least the one I'm using) don't persist filesystem state across invocations, so there is no notion of a cache here.

Seems highly unlikely to me. .m2 caching is essential, else you'd be downloading Maven dependencies over and over, which is slow and might even get rate-limited.

The same mechanism should be usable for caching directories other than .m2.

Ultimately if the Clojure CLI tools provided a way to completely ignore any deps.edn files in the current directory,

While as of today probably there isn't a direct way, the doc hints You can accomplish something similar with user-level aliases, or with the :replace-deps option. Another approach is leaving deps.edn "empty" by default, and all deps within aliases (e.g. :production + :dev, etc). I think some Polylith users do this for reasons unrelated to nvd-clojure.

FYI I has marked #142 as resolved since the docs are clear and I also tried to be clear in what (other) options are there. I hope the extra input helps as well but I wouldn't want to find myself arguing about how to run this program - its CI is green, it's OSS.

Cheers - V

pmonks commented 2 years ago

FYI I has marked https://github.com/rm-hull/nvd-clojure/issues/142 as resolved since the docs are clear and I also tried to be clear in what (other) options are there. I hope the extra input helps as well but I wouldn't want to find myself arguing about how to run this program - its CI is green, it's OSS.

I completely understand - as I've said several times now this is a Clojure CLI issue, not an nvd-clojure issue. Just confused as to why you'd ask questions then lock the issue so they can't be answered. That's not especially "OSS" (unless, of course, collaboration isn't part of your definition of that term).