chore(deps): hold monty at 0.0.19 — 0.0.21 silently disables the Python sandbox memory ceiling

[chaliy]

What changed

Blocks the monty / monty-types 0.0.19 → 0.0.21 upgrade instead of taking it, and records why.

• .github/dependabot.yml: ignore monty and monty-types so the broken bump is not regenerated every week.
• crates/bashkit/Cargo.toml: document the hold at the dependency (the 0.0.19 requirement is already an exact pin — Cargo treats each 0.0.z as its own compatibility range).
• knowledge/runtimes/python-builtin.md: new Upgrade blocker section covering the regression, the API migration the bump needs, and the supply-chain win that unlocks when it is safe.

No product code changes.

Supersedes #2296 and #2297 — both should be closed.

Why

Dependabot split one upstream release across two PRs, each bumping half of a version-locked pair, so both fail every check. Fixing that split surfaced the real problem.

Monty 0.0.21 changes how max_memory is enforced:

	0.0.19	0.0.21
Enforcement	LimitedTracker::on_grow accounts VM heap growth in-process	probe_memory() reads the LIVE_MEMORY / BASELINE_MEMORY statics
Who populates it	the tracker itself	only monty-alloc, as the process-wide global allocator
Embedder needs	nothing	to own the host's global allocator

Neither monty nor monty-types depends on monty-alloc. With it absent the statics keep their initial values, so probe_memory() is 0.saturating_sub(usize::MAX) == 0 and check_allocation — backing both max_memory and check_large_result — can never trip. The ceiling is not weakened, it is silently unenforced: no error, no warning.

Bashkit cannot supply the missing allocator. It is an embeddable library, so the global allocator belongs to the downstream binary, and bashkit-python is a CPython extension module where the allocator is CPython's. monty-alloc is built for Monty's own out-of-process worker model, which bashkit does not use.

Before / After

Verified locally by applying the full bump (both crates together, plus the ResourceTracker / ResourceLimits migration needed to compile) and running the Python resource-limit suites.

With monty 0.0.21 — a sandboxed script allocates without bound:

test python_security_tests::whitebox_resource_limits::successive_allocations_accumulate ... FAILED
test python_security_tests::whitebox_resource_limits::nested_list_bomb ... FAILED
test python_security_tests::whitebox_resource_limits::tight_memory_blocks_many_small_objects ... FAILED
test threat_model_tests::python_security_regressions::threat_python_pow_exhaustion ... FAILED

test result: FAILED. 9 passed; 4 failed; 1457 filtered out

assertion `left != right` failed: Creating 1M list items should hit limits
  left: 0
 right: 0

On this branch (monty 0.0.19):

test result: ok. 13 passed; 0 failed; 0 ignored; 1457 filtered out

The duration, recursion, string-bomb and print-collect-cap tests pass in both runs, which localises the regression to allocator-backed memory rather than resource limits generally.

Risk

• Low. Comments, dependabot config, and knowledge only — no code or resolved dependency versions change, so Cargo.lock is untouched.
• The cost of holding is staying on 0.0.19: no upstream Python-feature work, and the [patch.crates-io] git pin of jiter stays until the hold lifts. Both are recorded in the knowledge doc, including the two API changes (ResourceTracker becoming a concrete struct, ResourceLimits::new() → Default) and the fact that monty 0.0.21's move to the published jiter 0.16.0 would remove the last git dependency from the release graph — a real supply-chain win, but not a reason to take a silent sandbox regression early.

Checklist

• Tests added or updated — no new test needed; four existing threat-model regression tests already fail on the bump and are the standing guard. They are named in the knowledge doc so the next person to attempt the upgrade knows what must stay green.
• Backward compatibility considered — no public API or resolved dependency version changes.

---

Generated by Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bashkit	c1768f3	Commit Preview URL Branch Preview URL	Aug 15 2026, 09:20 AM