Fix Int.fromString overflow on untrusted parse paths (cross-compiler)

`case Int.fromString s of SOME|NONE` does not catch Overflow: MLton's 32-bit
default int raises it past 2^31 (a crash) while Poly/ML's 63-bit int accepts up
to 2^62 -- a crash and a cross-compiler divergence, the case-form of the earlier
`valOf (Int.fromString ...)` sweep. Fixed on every untrusted-input parse path by
parsing via `IntInf.fromString` with a fixed-literal signed-32-bit bounds check
(or `IntInf` end-to-end for genuinely-64-bit domains like Redis/SQL integers),
returning the site's documented failure (NONE / Err / documented exception) when
out of range. Never `Int.maxInt` (NONE on Poly) or bare `handle Overflow` (only
overflows on MLton). Re-vendored fixed dependencies to keep vendored copies
byte-matching canonical.

Verified: `make test` (MLton) and `make test-poly` (Poly/ML) both green with
byte-identical harness output.

Co-Authored-By: Claude Opus 4.8 <[email protected]>

Author: sjqtentacles

README.md

@@ -22,7 +22,7 @@ byte-identical** under both [MLton](http://mlton.org/) and
 
 ## Status
 
-- **114 assertions, green on MLton and Poly/ML**, with byte-identical output.
+- **117 assertions, green on MLton and Poly/ML**, with byte-identical output.
 - Validated against **real `git` fixtures** committed under
   [`test/fixtures/`](test/fixtures/), generated by the system `git` CLI
   ([`generate.sh`](test/fixtures/generate.sh)) with pinned identities/dates so
@@ -176,7 +176,11 @@ end
   fully-resolved base object.
 - **32-bit-safe.** All binary reads stay below 2³¹ so MLton's default 32-bit
   `Int` never overflows; packs larger than 2 GiB (64-bit offsets) are rejected
-  rather than silently mis-decoded.
+  rather than silently mis-decoded. The loose-object header size (unbounded
+  decimal ASCII) is parsed through arbitrary-precision `IntInf` and range-checked
+  against the fixed 32-bit signed bound, so a corrupt or hostile oversized size
+  is rejected as a clean `Git` error rather than raising `Overflow` on MLton
+  (which would also diverge from Poly/ML's wider `int`).
 - **Malformed input raises `Git`.**
 
 ## Build & test

src/git.sml

@@ -8,7 +8,11 @@
    Everything is byte-string in / byte-string out and deterministic. Integers
    stay small (MLton's default Int is 32-bit), so the binary readers avoid any
    value >= 2^31; 64-bit packfile offsets (packs > 2 GiB) are explicitly
-   rejected rather than silently overflowing. *)
+   rejected rather than silently overflowing. The one size field parsed from
+   untrusted decimal ASCII (a loose object's header size) is parsed through
+   arbitrary-precision IntInf and range-checked against the fixed 32-bit bound,
+   so an oversized size is a clean `Git` rejection rather than an Overflow
+   crash that would diverge between compilers. *)
 
 structure Git :> GIT =
 struct
@@ -195,9 +199,22 @@ struct
       val nul = findChar (framed, #"\000", sp + 1)
       val () = if nul < 0 then raise Git "object: missing header terminator" else ()
       val sizeStr = String.substring (framed, sp + 1, nul - (sp + 1))
-      val size = case Int.fromString sizeStr of
-                     SOME k => k
-                   | NONE => raise Git "object: malformed size"
+      (* The header size is unbounded decimal ASCII, so a corrupt or hostile
+         object can carry a value past 2^31. It is only ever compared to
+         `String.size p` (a machine `int`, since no in-memory string can be
+         larger), so it stays a bounded `int` -- but we must not let
+         `Int.fromString` raise `Overflow` on MLton's 32-bit `int` (a crash that
+         also diverges from Poly/ML's 63-bit `int`). Parse through
+         arbitrary-precision `IntInf` and range-check against the FIXED 32-bit
+         signed range, rejecting anything out of range as a clean `Git` error --
+         identically on both compilers. *)
+      val size =
+        case IntInf.fromString sizeStr of
+            NONE => raise Git "object: malformed size"
+          | SOME k =>
+              if k >= 0 andalso k <= 2147483647
+              then IntInf.toInt k
+              else raise Git "object: size out of range"
       val p = String.substring (framed, nul + 1, String.size framed - (nul + 1))
       val () = if String.size p <> size then raise Git "object: size mismatch" else ()
     in parseObject {typ = typ, payload = p} end

test/test_object.sml

@@ -106,5 +106,32 @@ struct
     ; H.section "object: malformed input is rejected"
     ; H.checkRaises "decodeLoose garbage" (fn () => Git.decodeLoose "not a git object")
     ; H.checkRaises "parseTree truncated" (fn () => Git.parseTree "100644 big.txt")
+
+    (* An object header size is decimal ASCII with no fixed width, so a corrupt
+       or hostile loose object can carry a size well past 2^31. MLton's default
+       `int` is 32-bit, so `Int.fromString` on such a numeral raises `Overflow`
+       -- an *uncontrolled* crash that also diverges from Poly/ML (63-bit int,
+       which would instead reach the size-mismatch check). The parser must
+       reject an out-of-range size as a clean `Git` error (never `Overflow`),
+       identically on both compilers. We assert the specific `Git` constructor,
+       not merely "some exception", so an `Overflow` crash still fails. *)
+    ; H.section "object: oversized size header is rejected cleanly"
+    ; let
+        fun raisesGit thunk =
+          (ignore (thunk ()); false)
+          handle Git.Git _ => true
+               | _ => false   (* Overflow or anything else -> not a clean reject *)
+        val loose10 = Zlib.deflateZlib {level = 6} "blob 9999999999\000hello\n"
+        val loose20 = Zlib.deflateZlib {level = 6} "blob 99999999999999999999\000hello\n"
+      in
+        H.check "oversized 10-digit size -> Git (not Overflow)"
+          (raisesGit (fn () => Git.decodeLoose loose10));
+        H.check "oversized 20-digit size -> Git (not Overflow)"
+          (raisesGit (fn () => Git.decodeLoose loose20));
+        (* a well-formed small object with a size that MATCHES its payload still
+           decodes cleanly -- the fix must not regress the happy path *)
+        H.checkEq "well-formed small object still decodes"
+          (Git.Blob "hi", Git.decodeLoose (Zlib.deflateZlib {level = 6} "blob 2\000hi"))
+      end
     )
 end