Message352899
| Author |
gregory.p.smith |
| Recipients |
ammar2, benjamin.peterson, gregory.p.smith, jaraco, larry, lukasz.langa, mcepl, ned.deily, tburke, webknjaz, xtreak |
| Date |
2019年09月20日.21:49:32 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1569016173.28.0.62964185164.issue38216@roundup.psfhosted.org> |
| In-reply-to |
| Content |
> 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. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2019年09月20日 21:49:33 | gregory.p.smith | set | recipients:
+ gregory.p.smith, jaraco, larry, benjamin.peterson, ned.deily, mcepl, lukasz.langa, webknjaz, ammar2, tburke, xtreak |
| 2019年09月20日 21:49:33 | gregory.p.smith | set | messageid: <1569016173.28.0.62964185164.issue38216@roundup.psfhosted.org> |
| 2019年09月20日 21:49:33 | gregory.p.smith | link | issue38216 messages |
| 2019年09月20日 21:49:32 | gregory.p.smith | create |
|