[issue39280] Don't allow datetime parsing to accept non-Ascii digits

Change by Ram Rachum : -- stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs-list

[issue39280] Don't allow datetime parsing to accept non-Ascii digits

Change by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39280] Don't allow datetime parsing to accept non-Ascii digits

STINNER Victor added the comment: > Hi guys, sidenote: please avoid "hi guys" which is not inclusive, see https://heyguys.cc/ Thanks ;-) -- ___ Python tracker ___

[issue39280] Don't allow datetime parsing to accept non-Ascii digits

Ram Rachum added the comment: Hi guys, Can we please have a decision on whether we want to move forward with this issue or not? I have a patch in the PR, and I'll be happy to continue working on it, or close this issue if that's the decision. Thanks, Ram. --

[issue39280] Don't allow datetime parsing to accept non-Ascii digits

Steven D'Aprano added the comment: > If all we're going to do is > switch [0-9] to \d (which won't work for the places where it's > actually [1-9], mind you) Ah, that's a good point. [...] > we're better off resolving the > inconsistency by requiring ASCII digits and considering non-ASCII

[issue39280] Don't allow datetime parsing to accept non-Ascii digits

Paul Ganssle added the comment: > Yes, but not within the same format. If someone were to choose the format > '2014-04-10T24:00:00', they would have a reasonable expectation that there is > only one unique string that corresponds with that datetime That's a particularly bad example, because

[issue39280] Don't allow datetime parsing to accept non-Ascii digits

Ram Rachum added the comment: Okay, since it seems like I'm the only one who wants this change, I'll let it go. Thanks for your input. -- ___ Python tracker ___

[issue39280] Don't allow datetime parsing to accept non-Ascii digits

Change by STINNER Victor : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39280] Don't allow datetime parsing to accept non-Ascii digits

Steven D'Aprano added the comment: > > ISO 8601 specifies dozens of ways to represent the same datetime > > Yes, but not within the same format. If someone were to choose the > format '2014-04-10T24:00:00', they would have a reasonable expectation > that there is only one unique string that

[issue39280] Don't allow datetime parsing to accept non-Ascii digits

Ram Rachum added the comment: > To me, this seems like a pretty thin justification for calling this a > security vulnerability. I know that lots of exploits were made because of bugs in Python's URL parsing, and security releases of Python were made because of that. It's possible that

[issue39280] Don't allow datetime parsing to accept non-Ascii digits

Steven D'Aprano added the comment: > If user code were to check for uniqueness of a datetime by comparing it as a > string, this is where an attacker could fool this logic, by using a non-Ascii > digit. To me, this seems like a pretty thin justification for calling this a security

[issue39280] Don't allow datetime parsing to accept non-Ascii digits

Paul Ganssle added the comment: I don't love the inconsistency, but can you elaborate on the actual *danger* posed by this? What security vulnerabilities involve parsing a datetime using a non-ascii digit? The reason that `fromisoformat` doesn't accept non-ASCII digits is actually because

[issue39280] Don't allow datetime parsing to accept non-Ascii digits

Change by Ram Rachum : -- keywords: +patch pull_requests: +17337 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17931 ___ Python tracker ___

[issue39280] Don't allow datetime parsing to accept non-Ascii digits

New submission from Ram Rachum : I've been doing some research into the use of `\d` in regular expressions in CPython, and any security vulnerabilities that might happen as a result of the fact that it accepts non-Ascii digits like ٢ and ５. In most places in the CPython codebase, the