NSC preprocess

[AnastaZIuk]

No description provided.

General approach: ensure that anything we spread or iterate over is a genuine, bounded array. For user-controlled data that may be passed as an array-like object, first validate/normalize it to a real array and, optionally, cap its length to a reasonable maximum. This prevents an attacker from supplying an object with a malicious .length value.

Concrete fix here: immediately before constructing clojureOptions in ClojureCompiler.runCompiler, normalize userOptions into a safe array and bound its length. We can do this by:

1. Coercing options to an array of strings, and
2. Deriving userOptions from that safe array instead of the possibly tainted original.

We do not need new imports; we can implement the normalization inline. A reasonable defensive limit can be chosen (e.g., 1000 options) to avoid absurdly large inputs without affecting legitimate usage.

Specific changes in lib/compilers/clojure.ts:

• After the code that determines sourceFileOptionIndex, compute a safeOptions array that:
  • Treats non-arrays as empty.
  • Converts all entries to strings.
  • Truncates the number of elements to a defined maximum (e.g., 1000).
• Use safeOptions.slice(0, sourceFileOptionIndex) (or the whole safeOptions if the index is -1) to derive userOptions.
• Leave all other logic intact.

No changes are required in lib/handlers/compile.ts, lib/base-compiler.ts, or lib/compilers/win32.ts to resolve this particular loop-bound/spread issue; the mitigation at the use site in ClojureCompiler is sufficient to break the tainted flow into an unsafe spread.

---

In general, to fix loop bound injection problems on arrays coming from untrusted input, you either (a) ensure the value is a genuine array with a reasonable maximum length, or (b) avoid directly iterating/spreading over something that may not be an array (e.g., coerce it into a safe representation first).

For this specific case, the minimal, behavior-preserving fix is to normalize userOptions in generateClojureMacroExpansion to a safe array before the spread, and to ensure its length is bounded. We can do this by:

• Ensuring userOptions is an actual array: if sourceFileOptionIndex is -1 (source file not found), we fall back to an empty array rather than options.slice(0, -1) and we explicitly cast/normalize slices to arrays.
• Clamping the maximum number of options we will process (e.g., 1,000 elements), so that an attacker cannot force our code to iterate or spread across an array with an enormous .length.
• This can be implemented entirely within lib/compilers/clojure.ts, near the existing code, without changing external behavior for normal, small inputs.

Concretely:

• In generateClojureMacroExpansion, after computing sourceFileOptionIndex, replace the direct options.slice(0, sourceFileOptionIndex) with logic that:
  • Treats sourceFileOptionIndex < 0 or !Array.isArray(options) as “no user options”.
  • Limits the slice to a maximum length (e.g., MAX_USER_OPTIONS = 1000).
• Use this sanitized userOptions when building clojureOptions.

No other files (compile.ts, base-compiler.ts, win32.ts) need changes for this particular alert; the taint chain there is already constrained by other internal processing, and the direct unbounded spread is only in ClojureCompiler.generateClojureMacroExpansion.

---

In general, to fix this class of issue you must ensure that any value whose .length ends up driving iteration is either: (a) guaranteed by type and construction to be a safe array, or (b) validated and normalized before use. Here, result.compilationOptions comes from tainted input and is later used with _.intersection, which treats it as array‑like. The safest fix is to defensively normalize options inside NimCompiler.postProcess so that it is always a bounded string[] regardless of what upstream provided.

Concretely, in lib/compilers/nim.ts within postProcess, we will:

1. Replace the direct assignment const options = result.compilationOptions; with a small normalization step:
   • If result.compilationOptions is already an array, use it.
   • If it is a string, wrap it as a single‑element array.
   • Otherwise, fall back to an empty array.
2. Optionally, enforce a reasonable maximum length for safety (e.g., clamp to some high upper bound), but to avoid altering expected behavior we will only normalize type, not truncate.
3. Use this normalized local options in the calls to _.intersection and getCacheFile, eliminating the use of the non‑null assertion options!.

This keeps existing functionality intact for valid inputs (arrays of options) while preventing a malicious request from supplying a non‑array with a malicious .length value.

Only lib/compilers/nim.ts needs changes.

[AnastaZIuk]

wtf copilot why you review my pr