While working on PR #80 checks initially failed clj-holmes checks (not clj-holmes/watson clj-holmes/clj-holmes!).
It turns out clj-holmes is a bit overzealous on what it considers a clojure spec.
It was convinced the map that describes our cli arguments was a spec, it saw :require true and assumed that we meant to type :required true.
Minimal example that triggers the clj-holmes finding:
This would be very helpful if this we actually a clojure spec, but it is not.
We tried to reduce clj-holmes to only look at security related issues, and this worked locally via
clj-holmes scan -p . --rule-tags security
Alas there is to facility pass rule-tags to the clj-holmes github action we are using.
The Hack
There might be ways to suppress clj-holmes false positives but I didn't see a way after reading the docs. For now I've appeased clj-holmes by using :require :yes instead of :require true.
Options
Option 1: Do nothing
Leave the hack in.
Option 2: Wait for a fix from clj-holmes
Ideally, this would be a fix for the false positive.
Less ideally, a way to specify rule tags on the clj-holmes github action.
Option 3: Use clj-holmes without the github action
This would allow us to do 2.2 ourselves.
Option 4: Disable clj-holmes
I like that a security-related project is being scanned by a security tool, so I'd rather not.
Proposal
Let's wait a bit and see what happens with clj-holmes.
I'd rather option 2.1, but 2.2 or 3 would be ok as well.
Background
While working on PR #80 checks initially failed clj-holmes checks (not clj-holmes/watson clj-holmes/clj-holmes!).
It turns out clj-holmes is a bit overzealous on what it considers a clojure spec. It was convinced the map that describes our cli arguments was a spec, it saw
:require true
and assumed that we meant to type:required true
.Minimal example that triggers the clj-holmes finding:
The finding looks like this:
This would be very helpful if this we actually a clojure spec, but it is not.
We tried to reduce clj-holmes to only look at security related issues, and this worked locally via
Alas there is to facility pass rule-tags to the clj-holmes github action we are using.
The Hack
There might be ways to suppress clj-holmes false positives but I didn't see a way after reading the docs. For now I've appeased clj-holmes by using
:require :yes
instead of:require true
.Options
Option 1: Do nothing
Leave the hack in.
Option 2: Wait for a fix from clj-holmes
Option 3: Use clj-holmes without the github action
This would allow us to do 2.2 ourselves.
Option 4: Disable clj-holmes
I like that a security-related project is being scanned by a security tool, so I'd rather not.
Proposal
Let's wait a bit and see what happens with clj-holmes. I'd rather option 2.1, but 2.2 or 3 would be ok as well.