Foundry - Slither / Unknown file console.sol

[gakonst]

I am trying to add Slither to the Forge template here, and getting an unexpected error:

ERROR:CryticCompile:Unknown file: /home/runner/work/forge-template/forge-template/lib/forge-std/src/console.sol

It seems to be related to this?

I also wonder why forge-template appears twice in the path?

(Separately, the Slither action does not seem to error when it hits an Error, and it makes you think that it fails at the followup step, here the SARIF upload)

[gakonst]

@montyly gm - understand you're busy, wonder if you (or anyone else?) had any time to investigate this?

[montyly]

Hi @gakonst sorry for the delay

It might be something weird going on with slither-action's container, as running slither on the forge's template locally works. I tried using the upcoming native support for foundry within slither-action (https://github.com/crytic/slither-action/pulls), and it works montyly/forge-template#1

      - name: Run Slither
        uses: crytic/slither-action@dev-install-foundry
        id: slither
        continue-on-error: true
        with:
          sarif: results.sarif

@elopez : any idea why the directory name would be duplicate within slither-action? Merging crytic/slither-action#8 will fix the issue, but it would be better to understand why we have this behavior

[elopez]

no idea off the top of my head on why it might be duplicate. The only difference I see on that PR vs the Slither integration is the forge build invocation; Slither / crytic-compile uses a longer one internally. See the example here if you want to try it: crytic/slither-action#5 (comment)

Other than that it should work, unless Foundry generates symlinks or something of that sort (the paths inside the container differ from the host, which might break them). I'm thinking out loud here at this point, but maybe there's some files that only get matched through the absolute path and not a relative one and that could also cause issues?

regarding "the Slither action does not seem to error when it hits an Error" -- it does, but you have continue-on-error: true specified, which tells GitHub to ignore the error and proceed with the execution. You can remove that and it will stop executing if an error happens -- but now execution will also halt if you have any findings (slither exits with non-zero in that case), which makes the SARIF integration a bit pointless. We could improve that a bit -- maybe slither could stop exit(#findings) if the SARIF integration is on, which would remove the need to do that. But that's a discussion for a different GH issue 😅

[elopez]

On a second look, the double path looks innocuous - GitHub just uses that when checking out the repository

But Slither doesn't like it if the repository is moved after compilation -- you can reproduce locally this way @montyly

git clone https://github.com/foundry-rs/forge-template.git foo
slither foo # should work fine if your env is correctly set up
mv foo bar
slither bar --ignore-compile # will complain that files are not found

We may be able to do some tricks inside the container to alleviate this - maybe a symlink from the host path to the container path is enough.

[montyly]

Nice catch @elopez. So generally speaking I think the issue here is that if we run the compilation separately, and then move the directory, the filename lookup will be lost. This is because the compilation artifacts might contain absolute paths that do not exist anymore.

We could add remapping within crytic-compile, but it's going to be tedious. A symlink in the container should indeed fix the issue

[gakonst]

symlink sgtm!

[elopez]

I opened a PR to implement the symlink crytic/slither-action#10, and it appears to work fine (change on top of your PR, CI run)