[zk-token-sdk] Add overflow checks on release build

[samkim-crypto]

Problem

In optimized release builds, overflow checks are disabled by default, which can lead to suppressed overflows and unexpected application behavior.

Summary of Changes

Add overflow checks on release build.

Note: Addresses an audit finding by Halborn: HAL-02.

Fixes #

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (d6aba9d) 81.8% compared to head (5cd941a) 81.8%. Report is 847 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##           master   #33761     +/-   ##
=========================================
- Coverage    81.8%    81.8%   -0.1%     
=========================================
  Files         806      806             
  Lines      217911   217905      -6     
=========================================
- Hits       178306   178290     -16     
- Misses      39605    39615     +10     

[samkim-crypto]

Yeah I now remember actually going through this same process for token-2022 also for Halborn. I dug out an old PR https://github.com/solana-labs/solana-program-library/pull/3588#issuecomment-1246341239.

After looking over the repo, I think the only real place where unchecked math is used in zk-token-sdk are a couple places in range proof, so it seems to make sense to just remove unchecked math altogether there, close this PR, and mark Halborn finding as acceptable.

[joncinque]

so it seems to make sense to just remove unchecked math altogether there, close this PR, and mark Halborn finding as acceptable

That would be amazing! I was worried there was too much unchecked math when I just grep'ed +, but that could have been tests

[mergify[bot]]

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.

[mergify[bot]]

Backports to the stable 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.

[willhickey]

This repository is no longer in use. Please re-open this pull request in the agave repo: https://github.com/anza-xyz/agave