chore: Update light-poseidon to 0.2.0

[vadorovsky]

That new release contains an important change which prevents a potential DDoS.

• fix: Validate byte inputs before changing endianness Lightprotocol/light-poseidon#32

Invoking from_bytes_be function light-poseidon 0.1.1 inverts all the inputs before performing a check whether their length exceeds the modulus of the prime field. Therefore, it was prone to an attack, where a mailicious user could submit long byte slices just to DDoS the validator, being stuck on inverting large byte sequences.

The update and mentioned change fixes the same issue as #33363 aims to address.

The new release contains also few other less important changes like:

• fix: Ensure that input doesn't exceed the modulus, this time for real Lightprotocol/light-poseidon#37
• test: Check hashes from byte slice inputs with lower length Lightprotocol/light-poseidon#38
• test: Add a test ensuring the consistency between hashing F and byte slices Lightprotocol/light-poseidon#39

[vadorovsky]

@samkim-crypto

[vovacodes]

Can we merge this plz. We see the compile errors fixed in this PR because our Cargo.lock already resolves light-poseidon to 0.1.3

error[E0004]: non-exhaustive patterns: `PoseidonError::BytesToPrimeFieldElement { .. }` and `PoseidonError::BytesToBigInt` not covered
   --> /Users/xxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/solana-program-1.17.4/src/poseidon.rs:212:23
    |
212 |                 match error {
    |                       ^^^^^ patterns `PoseidonError::BytesToPrimeFieldElement { .. }` and `PoseidonError::BytesToBigInt` not covered
    |
note: `PoseidonError` defined here
   --> /Users/xxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/light-poseidon-0.1.3/src/lib.rs:160:5
    |
145 | pub enum PoseidonError {
    | ----------------------
...
160 |     BytesToPrimeFieldElement { bytes: Vec<u8> },
    |     ^^^^^^^^^^^^^^^^^^^^^^^^ not covered
...
168 |     BytesToBigInt,
    |     ^^^^^^^^^^^^^ not covered
    = note: the matched value is of type `PoseidonError`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern, a match arm with multiple or-patterns as shown, or multiple match arms
    |
231 ~                     } => PoseidonSyscallError::InvalidWidthCircom,
232 ~                     PoseidonError::BytesToPrimeFieldElement { .. } | PoseidonError::BytesToBigInt => todo!(),
    |

@vadorovsky btw guys could you please make sure to not ship breaking changes in a patch release. Adding new enum types is a breaking change. I understand that there was no bad intent, but if your lib becomes a dependency of the crate that a lot of people use every day, this kind of considerations have to be taken extremely seriously. Not trying to be rude here, just feedback

[vadorovsky]

@vovacodes Apologies for that! I yanked the 0.1.3 version and I'm going to ship the breaking changes as 0.2.0, since we are breaking the API and adding new errors.

[codecov]

Codecov Report

Merging #33923 (dbb00a9) into master (28e08ac) will increase coverage by 0.0%.
Report is 3 commits behind head on master.
The diff coverage is 0.0%.

@@           Coverage Diff           @@
##           master   #33923   +/-   ##
=======================================
  Coverage    81.9%    81.9%           
=======================================
  Files         811      811           
  Lines      219427   219433    +6     
=======================================
+ Hits       179769   179803   +34     
+ Misses      39658    39630   -28     

[samkim-crypto]

Looks good to me!

[mergify]

Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis.