Open pcaversaccio opened 5 months ago
The first is a result of propagating taints through named returns i.e. this would have been detected prior if the code used explicit returns. https://github.com/crytic/slither/pull/1880
We are working on https://github.com/crytic/slither/issues/175
For inter-procedural taints, we definitely need a better way to show where the source originates
got similar issue that slither .
started complaining uses timestamp for comparisons
on many non-timestamp variable comparisons.
I've realized that when the timestamp
comparison occurs within a single function and that function is called throughout the codebase, slither may generate false-positive detections to all the variables. Perhaps it's more effective to simply highlight the line where the timestamp comparison occurs and be able to just disable-next-line
on that line.
Describe the false alarm that Slither raise and how you know it's inaccurate:
Clone
CreateX
before commit https://github.com/pcaversaccio/createx/commit/b60005c97cc7365a36b7fe74c75b4bcd32d3f165 and runslither .
with the latest Slither version0.10.2
:These false positives have not been present in the previous versions. So, I guess this is a new regression.
Examples:
Maybe Slither wants to point to the following (non-issues in my context) (link):
_generateSalt()
usesblock.timestamp
under the hood. So maybe the description is simply off:The same for the other warning which has no dangerous equality except if you want to refer to
newContract.code.length == 0
for the codesize check maybe, but in that case the detector message must be improved IMO:Frequency
Very Frequently
Code example to reproduce the issue:
See
CreateX
.Version:
0.10.2
Relevant log output:
No response