Gregory P. Smith <g...@krypto.org> added the comment:
> I think this is a false dichotomy; in > https://bugs.python.org/issue36274#msg351834 Jason proposed a few > alternatives that allow for a secure and obvious default API while adding a > new, explicitly unsafe API. I'm not against that concept, but it is only appropriate for >= 3.9 as that'd be adding a feature. This issue is marked a release blocker to decide what to do for 3.5-3.7 (and maybe 3.8 if deemed a serious breaking change). > I'd like to add yet another option that may be useful specifically for > maintenance releases: forbid only the problematic characters -- namely LF > (and potentially CR and SP). This seems like a much more surgical fix for > maintenance releases, allowing the null byte for CherryPy or the raw UTF-8 > bytes for Swift, while still mitigating the CVE. PRs with explicit tests for what is and isn't allowed welcome. Thankfully for the UTF-8 case, its multi-byte codepoint bytes will never contain LF, CR or SP. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38216> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
