Skip to content

fix(python): exempt strict-mode nonce from numeric coercion (#520) - #541

Merged
Seth Juarez (sethjuarez) merged 3 commits into
mainfrom
sethjuarez/python-harness-correctness
Sep 10, 2026
Merged

Seth Juarez (sethjuarez) merged 3 commits into
mainfrom
sethjuarez/python-harness-correctness

Conversation

@sethjuarez

Copy link
Copy Markdown
Member

Fixes #520.

The bug

In strict parsing mode, a valid render nonce is rejected when the random hex nonce is all decimal digits with a leading zero (e.g. 0123456789012345). pre_render() generates the nonce via secrets.token_hex(8) and stamps it as a quoted [nonce="..."] attribute. _parse_attrs() then int-coerced every all-digit value — dropping the leading zero — so _build_message()'s str(msg_nonce) != nonce comparison raised a false:

Nonce mismatch — possible prompt injection detected (strict mode is enabled)

~1 in 1,200 generated nonces hits this, causing intermittent strict-mode failures (~0.5% per 100-prompt batch). Confirmed reproduced against published prompty==2.0.0.

The fix

Exempt the nonce key from numeric coercion in _parse_attrs (keep it a string); all other attributes are still coerced. This matches the existing Java and Swift fixes — Python was the laggard.

Is this vector-governed?

No. The strict-mode sanitization nonce is random (secrets.token_hex), so it can't be a deterministic shared @vector. Siblings pin it with runtime-local regression tests (NonceCoercionTests.swift, ParseVectorsTest.allDigitNonceWithLeadingZeroStillValidates). This PR adds the matching Python TestNonceCoercion class:

  • nonce preserved as a string through _parse_attrs (8 crafted coercion modes)
  • strict parse accepts numeric-looking nonces (the e2e symptom)
  • mismatched nonce still rejected (injection detection intact)
  • non-nonce attributes still coerced (index=1, ratio=0.5, active=true)
  • 20,000-nonce generated sweep always validates

Validation

  • ruff check / ruff format --check clean
  • Full suite: 1475 passed, 60 deselected (integration)

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com

…r CLI

The microsoft org blocks the Actions GITHUB_TOKEN from opening pull requests,
and an org member cannot install a GitHub App on the org, so release-please
cannot run in CI here. Releases are instead cut by running the release-please
CLI under a maintainer's own identity (which the org permits) to open the
Release PR; the existing tag-triggered OIDC publisher handles PyPI once the
maintainer tags the merge.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Replace the deleted release-please.yml CI description with the actual
maintainer-run CLI process. Explain why there's no CI workflow (org blocks
the Actions GITHUB_TOKEN from opening PRs and its tags don't trigger publish),
and document the exact manifest-pr/manifest-release commands with the required
--config-file/--manifest-file flags that produce the correct python/2.0.0 tag.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
The strict-mode sanitization nonce is random hex from secrets.token_hex.
_parse_attrs coerced every all-digit attribute value to int/float, which
dropped a leading zero (e.g. "0123..." -> 123...) so _build_message's
comparison rejected the parser's own untampered output with a false
"Nonce mismatch — possible prompt injection detected" error. ~1 in 1,200
generated nonces hit this, causing intermittent strict-mode failures.

Exempt the nonce key from coercion in _parse_attrs (keep it a string),
matching the existing Java and Swift fixes; all other attributes are still
coerced. This behavior is not vector-governed (the nonce is non-deterministic),
so it is pinned by runtime-local regression tests mirroring the sibling runtimes.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Quoted all-digit nonce with a leading zero causes false strict-mode mismatch

1 participant