chore: v1 branch

[SwenSchaeferjohann]

No description provided.

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[coderabbitai]

Important

Review skipped

Auto reviews are limited based on label configuration.

🏷️ Required labels (at least one) (1)

• ai-review

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 11efecbd-9dbc-46fa-b3aa-862e58302f95

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch main

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

In general, to fix this issue you add an explicit permissions: block either at the workflow root (so it applies to all jobs) or at the individual job level, and set it to the minimum required (often contents: read if the job only needs to check out code and run tests). This constrains the GITHUB_TOKEN so it cannot perform unintended write operations.

For this specific workflow, the job only checks out the repository and runs tests and package-manager operations; none of the steps need to write to GitHub resources. The simplest least-privilege fix is therefore to add a top-level permissions: block just after the name: section, setting contents: read. This will apply to the system-programs job and any other jobs in this workflow (none are shown, but this is safe). No changes to steps, actions versions, or additional imports are needed.

Concretely:

• Edit .github/workflows/sdk-tests.yml.

• After the name: examples-tests line, insert:

  permissions:
    contents: read

This explicitly limits GITHUB_TOKEN to read-only repository contents while preserving existing functionality.

In general, to fix insecure randomness you replace Math.random() with a cryptographically secure pseudo-random generator (crypto.randomBytes in Node, crypto.getRandomValues in the browser), and then convert the random bytes to the range you need without introducing bias.

Here, the only insecure use is in selectStateTreeInfo in js/stateless.js/src/utils/get-state-tree-infos.ts, where const index = Math.floor(Math.random() * length); randomly selects an integer index in [0, length). The safest minimal-change fix is:

• Import Node’s crypto module.
• Implement a small helper that draws an unbiased random integer in [0, maxExclusive) using crypto.randomBytes (rejection sampling).
• Use that helper instead of Math.random() to compute index.

This keeps the external API and behavior of selectStateTreeInfo the same (still random among eligible trees, with the same length limiting), but uses a CSPRNG. No changes are required in js/compressed-token/src/actions/approve-and-mint-to.ts or js/compressed-token/src/program.ts, because they simply consume the TreeInfo produced by selectStateTreeInfo.

Concretely:

• Edit js/stateless.js/src/utils/get-state-tree-infos.ts:
  • Add import crypto from 'crypto'; (or import * as crypto from 'crypto'; depending on the surrounding style).
  • Add a getSecureRandomInt(maxExclusive: number): number helper above selectStateTreeInfo.
  • Replace const index = Math.floor(Math.random() * length); with const index = getSecureRandomInt(length);.

---

General fix: Replace Math.random() in selectStateTreeInfo with a cryptographically secure source of randomness, using either Node’s crypto.randomBytes or Web Crypto’s crypto.getRandomValues, and then map the secure random bytes to a uniform integer in [0, length).

Best fix here: Implement a small helper inside selectStateTreeInfo that derives a secure random integer modulo length using Web Crypto when available and Node’s crypto otherwise. This avoids changing the public API, keeps behavior (pseudo‑random selection) the same, and uses well‑known libraries only. We don’t need to touch js/compressed-token/src/program.ts; the taint arises entirely from how outputStateTreeInfo is chosen in selectStateTreeInfo. We only edit js/stateless.js/src/utils/get-state-tree-infos.ts, in the region around line 127 where Math.random() is called. We’ll add an import for crypto at the top and change the index calculation to:

• Generate a 32‑bit unsigned integer from secure random bytes.
• Reduce it modulo length to get an index in the correct range.

This maintains uniformity and removes the insecure RNG.

Concretely:

• In js/stateless.js/src/utils/get-state-tree-infos.ts, add import * as crypto from 'crypto';.
• Replace const index = Math.floor(Math.random() * length); with a new block that:
  • Uses window.crypto.getRandomValues in browsers (if available).
  • Falls back to crypto.randomBytes in Node to fill a 4‑byte buffer.
  • Interprets the 4 bytes as a 32‑bit unsigned integer and takes mod length.

No other files need changes.

---

In general, to fix insecure randomness in Node.js/TypeScript, replace Math.random() with a cryptographically secure source such as crypto.randomInt or crypto.randomBytes, taking care to avoid modulo bias when constraining the range.

In this codebase, the only insecure randomness is in selectStateTreeInfo in js/stateless.js/src/utils/get-state-tree-infos.ts where it computes const index = Math.floor(Math.random() * length);. The best, minimal‑impact fix is to compute index using crypto.randomInt(0, length) when running in Node.js. This keeps the distribution uniform over [0, length) with no bias and preserves all existing behavior except that the randomness becomes cryptographically strong. To do this, we need to add an import of Node’s built‑in crypto module and replace the Math.random() line with a crypto.randomInt call. No changes are required in compress.ts, program.ts, or pack-compressed-token-accounts.ts, since they only propagate the selected TreeInfo.

However, per your constraints I may only edit code inside the shown snippets of:

• js/compressed-token/src/utils/pack-compressed-token-accounts.ts
• js/stateless.js/src/utils/get-state-tree-infos.ts
• js/compressed-token/src/actions/compress.ts
• js/compressed-token/src/program.ts

The problematic Math.random() is in js/stateless.js/src/utils/get-state-tree-infos.ts, which is one of the allowed files and has been shown, so we will:

1. Add import { randomInt } from 'crypto'; (Node built‑in, no new dependency).
2. Replace const index = Math.floor(Math.random() * length); with const index = randomInt(length);.

No changes are needed in the compressed‑token files (compress.ts, program.ts, pack-compressed-token-accounts.ts) because they simply accept and forward the TreeInfo.

---

In general, to fix insecure randomness in Node/TypeScript code, replace Math.random() with a cryptographically secure RNG from the standard crypto module, and implement unbiased mapping from random bytes to the desired range (for indices, use rejection sampling to avoid modulo bias).

For this specific issue, the only insecure spot is selectStateTreeInfo in js/stateless.js/src/utils/get-state-tree-infos.ts at line 127. The best fix is:

• Import Node’s crypto module at the top of the file.
• Add a small helper function, e.g. getSecureRandomInt(max: number): number, that:
  • Uses crypto.randomBytes(4) to obtain a 32‑bit unsigned integer.
  • Uses rejection sampling so that the final integer is uniformly distributed in [0, max).
• Replace const index = Math.floor(Math.random() * length); with const index = getSecureRandomInt(length);.

This keeps behavior (pseudo‑randomly choosing a tree among the first length entries) while making the randomness cryptographically secure and avoiding bias. No changes are needed in create-account.ts or program.ts, since they just consume the TreeInfo returned by selectStateTreeInfo.

The problem should be fixed by enforcing upper bounds (MaxBatchSize and MaxTreeHeight) on the values of params.BatchSize and params.TreeHeight wherever they are used to control slice allocation. These maximums should be chosen according to operational needs and capacity, but even a modestly large hard limit is better than none from a security perspective.

The most robust fix is to add a check in CreateWitness (and preferably also in the handler and/or in ValidateShape() if it is defined) to ensure that params.BatchSize and params.TreeHeight are within a safe (predefined) maximum range. If not, return an error and do not perform any allocations. The check should occur before any allocations.

You only need to change code in prover/server/prover/v2/batch_address_append_circuit.go since that's where the dangerous allocation is performed.

Required changes:

• Add const MaxBatchSize = ... and const MaxTreeHeight = ... at the top of the file (just below the imports) or in appropriate scope.
• In CreateWitness(), after checking for zero, check that params.BatchSize and params.TreeHeight do not exceed these maximums.
• If either exceed the maximum, return an error.
• Optionally, you may want to ensure non-negative values, but these are already checked by if params.BatchSize == 0 etc.

---

To fix this issue, enforce a reasonable upper bound for BatchSize (and ideally also TreeHeight) before performing any slice allocations based on user input. The upper bound(s) should be set as per application requirements and resource constraints (const MaxBatchSize = ..., const MaxTreeHeight = ...). The best location for these checks is at the start of CreateWitness() in batch_address_append_circuit.go, where allocations occur, and possibly also in ProveBatchAddressAppend for belt-and-braces defense. If the inputs exceed these limits, return an error before any allocation. This limits memory use so an attacker cannot force OOM via large slice allocations.

Changes needed:

• In prover/server/prover/v2/batch_address_append_circuit.go, define constants for MaxBatchSize and MaxTreeHeight.
• In the CreateWitness method, add checks ensuring BatchSize and TreeHeight are within allowed limits before performing any allocations.
• Return an error if the limits are exceeded.
• Optionally, add the same checks at the start of InitBatchAddressTreeAppendCircuit and/or ProveBatchAddressAppend for defense-in-depth, but the primary fix is in CreateWitness().

---

The best way to fix the problem is to enforce maximum limits on both params.BatchSize and params.TreeHeight before any slices are allocated using these values. The limit values should be selected so that reasonable but resource-safe workloads are allowed, and enforced consistently anywhere untrusted input may be used to allocate memory. To implement, add sanity checks to the CreateWitness() method for BatchAddressAppendParameters (and possibly other locations where allocation occurs), rejecting values above a fixed constant such as MaxBatchSize and MaxTreeHeight, and returning an error if outside bounds. These constants should be defined at the top of the file or alongside similar configuration, so they can be changed centrally. Only code in prover/server/prover/v2/batch_address_append_circuit.go needs editing, specifically within the CreateWitness function.

To fix this vulnerability, we must impose a reasonable upper bound (maximum allowed value) on the BatchSize and TreeHeight parameters received from untrusted input before using them to allocate memory. This should be enforced in the CreateWitness method in prover/server/prover/v2/batch_address_append_circuit.go, where allocations are made, and ideally also in higher-level logic.

• Define (or use an existing) reasonable maximum constants for BatchSize and TreeHeight (e.g., MaxBatchSize, MaxTreeHeight).
• In CreateWitness, add checks:
  • If params.BatchSize < 0 (though it's unsigned, so not needed) or params.BatchSize > MaxBatchSize, return an error.
  • Similarly, check params.TreeHeight > MaxTreeHeight.
• Return an error to the caller if values are out of bounds, preventing allocation.
• The maximums should be chosen based on practical and business constraints, and declared as constants at the top of the file.

No new imports or external packages are required for this fix.

---

The best way to address this vulnerability is to validate params.BatchSize (and, for completeness, possibly also params.TreeHeight) in the key entry-point for user-controlled values. This means:

• Adding a constant upper bound (such as MaxBatchSize) and returning an error if the requested value exceeds this bound. (Example: 128, 256, or another value as appropriate—should be set in consultation with expected system capabilities and use cases.)
• The check should be performed as soon as possible after unmarshalling user input but before any slice allocations.
• For code clarity and maintainability, the check should be implemented in the CreateWitness method in prover/server/prover/v2/batch_address_append_circuit.go, and in the API handler method in prover/server/server/server.go if relevant.
• No changes to the logic should be made except to prevent allocation for bad requests; return a descriptive error in case of exceeding limits.

In summary:

• In prover/server/prover/v2/batch_address_append_circuit.go, add reasonable maximum allowed value checks to BatchSize (and optionally TreeHeight) in CreateWitness.
• Reject requests exceeding these bounds with a clear error.

---

To prevent excessively large memory allocations from user-controlled values, the best way is to enforce upper bounds for BatchSize and TreeHeight before using them to allocate slices. These bounds should be chosen based on system constraints and expected usage patterns (e.g., maximum batch size and tree height that the system can process comfortably).

Implement these checks inside (*BatchAddressAppendParameters).CreateWitness(), rejecting requests with parameters exceeding limits. To ensure all entry points are guarded, also validate before use in all functions that process user input parameters, such as in the server handler.
Required changes:

• Add constants (e.g., MaxBatchSize, MaxTreeHeight) at the top of the relevant file (near the CreateWitness method).
• In CreateWitness, check if params.BatchSize and params.TreeHeight are above the maximum; if so, return an error.
• Optionally, add similar checks in the handler or at the earliest point possible for fail-fast protection.

---

To remediate this issue, you should enforce maximum allowable values on both TreeHeight and BatchSize before any slice allocation that uses them. Choose sensible upper bounds according to expected use (e.g., based on business logic or system capacity). Implement checks at the start of functions where these values are accepted, returning an error if either exceeds the maximum. These checks should be placed at the top of the CreateWitness function in prover/server/prover/v2/batch_address_append_circuit.go, which is the critical path for these allocations. You may also wish to add a helper method or constants for these bounds if appropriate.

Changes needed:

• In prover/server/prover/v2/batch_address_append_circuit.go:
  • Define constants for maximum allowed TreeHeight and BatchSize (such as MaxTreeHeight and MaxBatchSize).
  • At the top of CreateWitness, add checks that error out if params.TreeHeight or params.BatchSize exceeds their respective maximums.

No changes to imports are needed; this is pure logic.

---

To fix the problem, explicitly define minimal GITHUB_TOKEN permissions for this workflow or for the specific job. Since the workflow only checks out code, builds, and runs tests, it normally only needs read access to repository contents. We can add a permissions block at the root of the workflow so it applies to all jobs (there is only one job in the snippet). This will ensure that even if the repository or org default is read-write, the workflow will only have contents: read.

Concretely, in .github/workflows/js.yml, add:

permissions:
  contents: read

between the name: js-tests-v1 section and the concurrency: block (lines 14–16 in the snippet). This does not change any existing behavior of steps, but constrains the token according to the principle of least privilege. No additional methods, definitions, or imports are needed.