Consider running slither against the repository

[thedavidmeister]

Slither has a github action https://github.com/marketplace/actions/slither-action

It's easy to setup on a repo, and while it does flag some false positives, each can be triaged with inline comments.

It would have flagged e.g. that bumping to Solidity 0.8.19 forces everyone downstream to use a version newer than is recommended by Slither (0.8.18 currently), perhaps there's other things that slither might find.

[PaulRBerg]

Thanks for your suggestion!

I'm actually using that GitHub Action in PRBProxy - I'm a big fan of this approach of running Slither in CI since I've seen Matt Solomon apply it.

But unfortunately, Slither is not compatible with user-defined operators (which were added in PRBMath V4):

• Fix crash on prb-math crytic/slither#1989
• Add support for user defined operators solc 0.8.19 crytic/slither#1681

[thedavidmeister]

@PaulRBerg hmmm, tangentially related but i wonder if UDOs add jumps to the compiled bytecode.

While wrap and unwrap are zero cost abstractions, i didn't think that functions associated with the UDVT were because they aren't inlined by the compiler afaik.

[thedavidmeister]

but yes, in general if you use slither there's a delay between new versions of solidity being released and slither fully supporting them

in my experience it takes a few months

also note that slither is explicitly saying that using 0.8.19 is a security risk, so using a feature from 0.8.19 would mean you've already silenced/ignored that detector

this is because slither has a somewhat arbitrary concept of "lindy" where the maintainers will ding versions of solidity that are "too new". the thinking is that there could easily be new security bugs that haven't been discovered yet. i don't think there's any logic to when the versions are bumped, other than the slither maintainers feel like "enough" time has passed.