Repository navigation
Prohibit invisible control characters in string literals and comments #89968
Description
Activity
Currently invisible control characters aside from whitespace (tabs, newlines, formfeeds, carriage returns) are prohibited outside of comments and string literals. As discussed in this thread:
we should ban C0 and C1 control characters (aside from \t\n\f\r) in string literals and comments too.
To be clear, the ban is on actual invisible control characters, not escape sequences.
- added3.11only security fixesonly security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-securityA security issueA security issue
on Nov 15, 2021 I am working on this.
Since this is an old issue and that removing these invisible control characters will break backwards compatibility; at first we will raise deprecation warnings.
As discussed in PEP 672 and this Discourse discussion, handling such characters is the responsibility of the renderer, not the language.
To expand Stan's comment: The link in the opening post, meant to justify this issue, is one message in a pydev thread by Petr Viktorin originally entitled "pre-PEP: Unicode Security Considerations for Python" and retitled as "Preventing Unicode-related gotchas".
https://mail.python.org/archives/list/python-dev@python.org/thread/6DBJJRQHA2SP5Q27MOMDSTCOXMW7ITNR/#DN24FK3A2DSO4HBGEDGJXERSAUYK6VK6
The original message referenced a unicode-based attack based on the difference between actual parsing and expected parsing based on appearance to viewers. It continued with the view Stan gave above, also expressed in UTS #55, which is referenced in the Discourse discussion. The subsequent Informational PEP was aimed at authors of checkers (lints), viewers, and Unicode users in general. It proposed no change in the language. (And such would now require a Discourse discussion and, I believe, an SC-approved PEP.)If the CPython PR test linter, part of CI, does not already fail on control chars (I don't know), a new failure condition could be proposed.
Reacted by Stan Ulbrych
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: