UbiquiStick slither checks

[0x4007]

Right now we have slither disabled for this folder.

What should be done:

1. Remove src/ubiquistick from filter_paths in the slither config file
2. Fix slither errors in the src/ubiquistick folder

Ideally it should be included in slither checks but I figured out it requires a lot of changes. Fixing slither issue would take lots of time rather than re-implementing them properly. so I made it excluded. In the near future, we should include again.

Originally posted by @0xcodercrane in #417 (comment)

[hashedMae]

Is this to remove the exclusion or to actually fix the issues that Slither raises?

[0xcodercrane]

Is this to remove the exclusion or to actually fix the issues that Slither raises?

This issue is to fix the issues that Slither raises.

[0x4007]

Also I believe that Slither has been disabled so we should probably update this issue and make sure that the entire thing works?

I have some doubts with implementing Slither at the moment if we are still doing some large code changes (e.g. Diamond) is it a better idea to wait or does it make sense to iterate towards full code coverage?

[hashedMae]

Final checks should definitely happen when contracts move to a staging phase, but best practice is to write secure code from the jump. If we get to staging and the vulnerabilities run too deep, there's potential for refactoring that could delay production by weeks or months. Right now there's far too many places where we're not following the Checks Effects Interactions pattern and instead relying on non-reentrant modifiers

…

------- Original Message -------

On Tuesday, February 14th, 2023 at 6:33 PM, アレクサンダー.eth ***@***.***> wrote: Also I believe that Slither has been disabled so we should probably update this issue and make sure that the entire thing works? I have some doubts with implementing Slither at the moment if we are still doing some large code changes (e.g. Diamond) is it a better idea to wait or does it make sense to iterate towards full code coverage? — Reply to this email directly, [view it on GitHub](#472 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AUINN7SNS3WML6BHKS4LDILWXQ57ZANCNFSM6AAAAAATY7FCSE). You are receiving this because you commented.Message ID: ***@***.***>

[Steveantor]

You have to take false positives into consideration as well

[ghost]

@pavlovcik @rndquu this seems similar to #536 can i work on this?

[rndquu]

@pavlovcik @rndquu this seems similar to #536 can i work on this?

sure

[ghost]

@pavlovcik @rndquu this seems similar to #536 can i work on this?

sure

#687 #681 has 1 review still pending can i unassign them or i gotta wait?

[ghost]

/start

[ubiquibot]

Skipping /start since the issue is closed

[rndquu]

@pavlovcik can we assign @AnakinSkywalkeer ? There are 2 pending PRs (one and two) but they are waiting for @zgorizzo69 's review

[ghost]

@pavlovcik can we assign @AnakinSkywalkeer ? There are 2 pending PRs (one and two) but they are waiting for @zgorizzo69 's review

i solved some errors but other requires me to ask questions about should i open the PR ?

[ubiquibot]

@AnakinSkywalkeer The time limit for this bounty is on Wed, 28 Jun 2023 20:57:31 GMT

[rndquu]

@pavlovcik can we assign @AnakinSkywalkeer ? There are 2 pending PRs (one and two) but they are waiting for @zgorizzo69 's review

i solved some errors but other requires me to ask questions about should i open the PR ?

pls open a PR

[0x4007]

I was too late to get to this in time but this should be a one day issue, not a one week issue. I still have to re-check all of these old issues' labels.

[rndquu]

@AnakinSkywalkeer notice that we've updated the time label from <1 week to <1 day, the time limit is intact though

[ghost]

@AnakinSkywalkeer notice that we've updated the time label from <1 week to <1 day, the time limit is intact though

oh okay

[ubiquibot]

[ CLAIM 200 WXDAI ]

0x2bBc6a83...b75E3708c