unicolet.org

A bug opened since May 2021, just a bit over 4 years ago, has finally been fixed:  https://github.com/openzfs/zfs/issues/12014#issuecomment-2889132540 The fix itself is trivial, even though I am sure that finding the cause surely was not. But what really caught my attention was the CodeQL integration test  that was written to prevent this issue from happening again. I find CodeQL and similar tools (such as Opengrep/Semgrep) can be incredibly powerful in integration pipelines to prevent subtle, difficult to reproduce issues from happening again probably saving a lot of time in debugging and to write expensive integration tests. I'd be curious to understand if CodeQL fares better in this context than Opengrep because it is aware of the code flow, as opposed to "just" matching patterns (I think Opengrep understands the code structure, to some extent but I'm not 100% sure). I do find CodeQL intimidating and more complex than Opengrep though: with the latter I was able to ...

Since I could not find a quickstart to run opengrep with the full set of rules from their fork I thought I'd document what I found out. Setup Download the opengrep binary from github and make it executable with chmod +x . Clone the rules repo: git clone git@github.com:opengrep/opengrep-rules.git and clean it up to make it usable to opengrep: cd opengrep-rules rm -rf ".git",".github",".pre-commit-config.yaml", "elixir", "apex" find . -type f -not -iname "*.yaml" -delete rm -rf .github rm -rf .pre-commit-config.yaml Ensure opengrep can load the rules with: opengrep_manylinux_x86 validate . The same can be done for custom rules maintained in a separate repository. AFAIU Multiple repositories can be specified by repeating -f option as needed, see below. We are now ready to scan a repo, from the repo root directory run: opengrep_manylinux_x86 scan \   -f <path_to>/opengrep-rules \   --error \   --exclude-rule=VAL some ti...