[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On Tue, Nov 16, 2021 at 12:13 PM Steven D'Aprano wrote: > > On Mon, Nov 15, 2021 at 10:43:12PM +1100, Chris Angelico wrote: > > > The problems here are not Python's, they are code reviewers', and that > > means they're really attacks against the code review tools. > > I think that's a bit strong.

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On Mon, Nov 15, 2021 at 10:43:12PM +1100, Chris Angelico wrote: > The problems here are not Python's, they are code reviewers', and that > means they're really attacks against the code review tools. I think that's a bit strong. Boucher and Anderson's paper describes multiple kinds of

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On Mon, Nov 15, 2021 at 03:20:26PM +0400, Abdur-Rahmaan Janhangeer wrote: > Well, it's not so obvious. From Ross Anderson and Nicholas Boucher > src: https://trojansource.codes/trojan-source.pdf Thanks for the link. But it discusses a whole range of Unicode attacks, and the specific attack you

[Python-Dev] Re: Remove asyncore, asynchat and smtpd modules

On Tue, Nov 16, 2021 at 1:15 AM Brett Cannon wrote: > But have they been raising exceptions for two releases? As I wrote previously, the DeprecationWarning warning is only emitted at runtime since Python 3.10. Since my PR got 5 approvals, I just merged it:

[Python-Dev] Re: Remove asyncore, asynchat and smtpd modules

On Fri, Nov 12, 2021 at 4:16 AM Victor Stinner wrote: > > > It was decided to start deprecating the asyncore, asynchat and smtpd > > > modules in Python 3.6 released in 2016, 5 years ago. Python 3.10 emits > > > DeprecationWarning. > > > > Wait, only Python 3.10? > > According to the policy, the

[Python-Dev] Re: Do we need to remove everything that's deprecated?

On Sun, Nov 14, 2021 at 3:01 PM Victor Stinner wrote: > On Sun, Nov 14, 2021 at 6:34 PM Eric V. Smith wrote: > > On second thought, I guess the existing policy already does this. Maybe > > we should make it more than 2 versions for deprecations? I've written > > libraries where I support 4 or 5

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On Mon, Nov 15, 2021 at 12:28:01PM -0500, Terry Reedy wrote: > On 11/15/2021 5:45 AM, Steven D'Aprano wrote: > > >In another thread, Serhiy already suggested we ban invisible control > >characters (other than whitespace) in comments and strings. > > He said in string *literals*. One would put

[Python-Dev] [RELEASE] Python 3.9.9 hotfix release is now available

Get it here: https://www.python.org/downloads/release/python-399/ Python 3.9.9 is the eighth maintenance release of the legacy 3.9 series. Python 3.10 is now the latest feature release series of Python 3. Get the latest release of 3.10.x

[Python-Dev] Re: The Steering Council elections.

On Mon, Nov 15, 2021 at 10:49 AM Thomas Wouters wrote: > > Just a reminder that the nomination period for the next SC ends *today* > (AoE), so if you're intending to nominate (yourself or someone else), > please get those posts in. (No need for a long post before the deadline, it > can be

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

> GitHub specifically flags it as a possible exploit in a couple of cases, but also syntax highlights the return keyword appropriately. My guess is that Github did patch it afterwards as the paper does list Github as vulnerable > Uhhm. "weird unicode stuffs"? Please clarify. Wriggly texts

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On 11/15/2021 5:45 AM, Steven D'Aprano wrote: In another thread, Serhiy already suggested we ban invisible control characters (other than whitespace) in comments and strings. He said in string *literals*. One would put them in stromgs by using visible escape sequences. >>> '\033' is

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

Abdur-Rahmaan Janhangeer writes: > As a programmer, i don't want a language which bans unicode stuffs. But that's what Unicode says should be done (see below). > If there's something that should be fixed, it's the unicode standard, Unicode is not going to get "fixed". Most features are

[Python-Dev] Re: The Steering Council elections.

Just a reminder that the nomination period for the next SC ends *today* (AoE), so if you're intending to nominate (yourself or someone else), please get those posts in. (No need for a long post before the deadline, it can be expanded later.) We currently have the 4 incumbents, and nobody else, so

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On 15.11.2021 12:36, Steven D'Aprano wrote: > On Sun, Nov 14, 2021 at 10:12:39PM -0800, Christopher Barker wrote: > >> I am, however, surprised and disappointed by the NKFC normalization. >> >> For example, in writing math we often use different scripts to mean >> different things (e.g. TeX's

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On Mon, Nov 15, 2021 at 10:22 PM Abdur-Rahmaan Janhangeer wrote: > > Greetings, > > > > Now what happens? where do you go from there to a vunerability or > backdoor? I think it might be a bit obvious that there is something > funny going on if I see: > > if (user.admin == "root" and

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On Sun, Nov 14, 2021 at 10:12:39PM -0800, Christopher Barker wrote: > I am, however, surprised and disappointed by the NKFC normalization. > > For example, in writing math we often use different scripts to mean > different things (e.g. TeX's Blackboard Bold). So if I were to use > some of the

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

Greetings, > Now what happens? where do you go from there to a vunerability or backdoor? I think it might be a bit obvious that there is something funny going on if I see: if (user.admin == "root" and check_password_securely() or user.admin == "root" # Second string

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On Mon, Nov 15, 2021 at 12:33:54PM +0400, Abdur-Rahmaan Janhangeer wrote: > Yet another issue is adding vulnerabilities in plain sight. > Human code reviewers will see this: > > if user.admin == "something": > > Static analysers will see > > if user.admin == "something": Okay, you have a

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On 15. 11. 21 9:25, Stephen J. Turnbull wrote: Christopher Barker writes: > Would a proposal to switch the normalization to NFC only have any hope of > being accepted? Hope, yes. Counting you, it's been proposed twice. :-) I don't know whether it would get through. We know this won't

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On Sat, Nov 13, 2021 at 5:04 PM wrote: > > > def 횑퓮햑풍표(): > > try: > > 픥e헅핝횘︴ = "Hello" > > 함픬r퓵ᵈ﹎ = "World" > > ᵖ햗퐢혯퓽(f"{헵ｅ퓵픩º_}, {햜ₒ풓lⅆ︴}!") > > except 퓣핪ᵖｅ햤헿ᵣ햔횛 as ⅇ헑c: > > 풑rℹₙₜ("failed: {}".핗헼ʳᵐªｔ(ᵉ퐱퓬)) > > > > if _︴ⁿ퓪푚핖__ == "__main__": > >

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

Well, Yet another issue is adding vulnerabilities in plain sight. Human code reviewers will see this: if user.admin == "something": Static analysers will see if user.admin == "something": but will not flag it as it's up to the user to verify the logic of things and as such soft authors can

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

Christopher Barker writes: > Would a proposal to switch the normalization to NFC only have any hope of > being accepted? Hope, yes. Counting you, it's been proposed twice. :-) I don't know whether it would get through. We know this won't affect the stdlib, since that's restricted to ASCII.