Address circomspect warnings

[0xjei]

Description

This PR addresses the circomspect warnings for the poseidon-cipher, poseidon-proof, utils(float, safe-comparators) packages.

There are still some warnings but we can safely ignore them:

• poseidon-cipher:
  • warning: The output signal decryptedLast defined by the template PoseidonDecryptIterations is not constrained in PoseidonDecryptWithoutCheck: yes, that's why is called PoseidonDecryptWITHOUTCHECK because there's no checks there.
  • warning: Inputs to LessThan need to be constrained to ensure that they are non-negative: added an assert to avoid potentially unsecure negative inputs to LessThan.
• float: warning: Using Num2Bits to convert field elements to bits may lead to aliasing issues.: added an assert to check that the input is always under the BN254 curve. May @sripwoud or @cedoor or @ctrlc03 can countercheck this?

Related Issue(s)

PR #7

Other information

none

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I have run yarn format and yarn compile without getting any errors
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[sripwoud]

utACK

I can't comment on the circom code, never written any...

About the remaining warnings: https://github.com/privacy-scaling-explorations/zk-kit.circom/security/code-scanning?query=pr%3A11+is%3Aopen
@0xjei I'd say go ahead and dismiss/close them

[0xjei]

utACK

I can't comment on the circom code, never written any...

About the remaining warnings: https://github.com/privacy-scaling-explorations/zk-kit.circom/security/code-scanning?query=pr%3A11+is%3Aopen @0xjei I'd say go ahead and dismiss/close them

tysm, do you happen to know how to disable them? didn't find anything useful on their docs

[sripwoud]

utACK
I can't comment on the circom code, never written any...
About the remaining warnings: https://github.com/privacy-scaling-explorations/zk-kit.circom/security/code-scanning?query=pr%3A11+is%3Aopen @0xjei I'd say go ahead and dismiss/close them

tysm, do you happen to know how to disable them? didn't find anything useful on their docs

you can disable them yes, see #7 (comment)
(use the -v flag to find rules ID, then you can allow them with the -a flag)
Not sure if we should do it, as this would allow a rule forever on all files. I don't think there is a way to define rules overrides on a file per file basis

[0xjei]

utACK
I can't comment on the circom code, never written any...
About the remaining warnings: https://github.com/privacy-scaling-explorations/zk-kit.circom/security/code-scanning?query=pr%3A11+is%3Aopen @0xjei I'd say go ahead and dismiss/close them

tysm, do you happen to know how to disable them? didn't find anything useful on their docs

you can disable them yes, see #7 (comment) (use the -v flag to find rules ID, then you can allow them with the -a flag) Not sure if we should do it, as this would allow a rule forever on all files. I don't think there is a way to define rules overrides on a file per file basis

I don't think there is a way to define rules overrides on a file per file basis
I was exactly checking for this. Tend to agree, I would rather avoid to soppress everything globally!

[sripwoud]

Let's merge this.

I don't think there is a way to define rules overrides on a file per file basis

Maybe I can try hacking this "someday" (not sure this is urgent):
circomspect spits out a sarif file, which is json that includes warning/errors with details about the files/lines affected.
So I guess we could automate editing this file (based on e.g a .circomspectignore or some kind of override config file) before uploading it to GH.

[0xjei]

Let's merge this.

I don't think there is a way to define rules overrides on a file per file basis

Maybe I can try hacking this "someday" (not sure this is urgent): circomspect spits out a sarif file, which is json that includes warning/errors with details about the files/lines affected. So I guess we could automate editing this file (based on e.g a .circomspectignore or some kind of override config file) before uploading it to GH.

awesome, I was reading the SARIF file standard stuff and this seems more than a possible workaround. You the best!