Skip to content

gh-160187: Reject ISO-2022 designations into the wrong G set - #160188

Open
gpshead wants to merge 1 commit into
python:mainfrom
gpshead:iso2022-wrong-g-set
Open

gpshead wants to merge 1 commit into
python:mainfrom
gpshead:iso2022-wrong-g-set

Conversation

@gpshead

@gpshead gpshead commented Oct 22, 2026 •

Copy link
Copy Markdown
Member

iso2022processesc() now requires the designation table entry's plane to match the G set the escape designates to, and accepts ASCII only for G0. Conforming encoders (including ours) never emit the escapes this rejects, but strict decoding of such malformed data now raises UnicodeDecodeError where it used to return wrong text, so this is for main only.

The RuntimeError alone could be fixed in maintenance branches by having iso2022processg2() return an ordinary decode error instead of MBERR_INTERNAL.

Fixes #160187

ANT-2026-TH3IZKXQ

@gpshead gpshead self-assigned this Oct 22, 2026
@gpshead
gpshead marked this pull request as ready for review October 22, 2026 04:34
@gpshead
gpshead requested a review from corona10 as a code owner October 22, 2026 04:34
@gpshead gpshead added the sprint label Oct 22, 2026
@github-project-automation github-project-automation Bot moved this to Todo in Sprint Oct 22, 2026
@gpshead gpshead added the needs backport to 3.15 bugs and security fixes label Oct 22, 2026
The ISO-2022 decoders checked only that a designated charset belonged to
the encoding, not that it went to the code element the encoding assigns
it to.
@gpshead
gpshead force-pushed the iso2022-wrong-g-set branch from 65399ab to 7c83abe Compare October 22, 2026 04:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

ISO-2022 decoders accept charset designations into the wrong G set

1 participant