Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libraryPublicFunction is inaccurate #56

Open
0xEVom opened this issue Aug 9, 2024 · 0 comments
Open

libraryPublicFunction is inaccurate #56

0xEVom opened this issue Aug 9, 2024 · 0 comments

Comments

@0xEVom
Copy link

0xEVom commented Aug 9, 2024

Here's what the detector currently says:

In a library, using an external or public visibility means that we won't be going through the library with a DELEGATECALL but with a CALL. This changes the context and should be done carefully.

But, from the Solidity docs:

... the code of internal library functions that are called from a contract and all functions called from therein will at compile time be included in the calling contract, and a regular JUMP call will be used instead of a DELEGATECALL.

Calling a public library function with L.f() results in an external call (DELEGATECALL to be precise).

Hence the external or public visibility means the function will be executed using a DELEGATECALL instead of a JUMP, not a CALL instead of a DELEGATECALL.

I'm also not sure what exactly this detector is trying to flag - I don't see how having an external/public library function is immediately a security concern, or at least not worth a Medium severity finding. There may be other implications I'm not aware of but I can only see this being a potential footgun if the function takes storage pointers as parameters, which seems unlikely to happen inadvertently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant