Closed lread closed 3 months ago
Hmm... I'll look into suppressing that clj-holmes false positive. Not familiar with clj-holmes yet.
Try renaming spec-scan-args
to something that doesn't have spec
in its name?
Good guess, but no dice, it still reports the same finding! I'll keep poking around.
Hmmm... it is making some pretty bold assumptions about specs, this triggers the finding as well:
(def foo {:bingo
{:require true}})
Tried copying it to other namespaces just in case ns-name was involved in decision. Does not seem to be!
It's from the clj-holmes-rules
repo and there are only two rule tags: correctness
(with just this one bad rule) and security
-- so you should be able to specify -T security
to the invocation and it will only run the security rules.
Specifically: add tags: 'security'
to the with:
clause for the clj-holmes action should do it.
Oh. Pushed a week hack while you were writing that. Ok, will try.
Good grief! 😞 I've logged bugs against clj-holmes-rules (for the bad correctness rule) and against clj-holmes-action (for not accepting tags:
).
Looks like it will have to be your workaround for now.
Oh bother! Hack it is! I'll raise a separate issue here about clj-holmes so we actually remember to undo the little hack.
When running via -X or -T:
When running via -M:
General:
Closes #77