On 03. 11. 21 12:37, Chris Angelico wrote:
On Wed, Nov 3, 2021 at 10:22 PM Steven D'Aprano <st...@pearwood.info> wrote:
On Wed, Nov 03, 2021 at 11:21:53AM +1100, Chris Angelico wrote:
TBH, I'm not entirely sure how valid it is to talk about *security*
considerations when we're dealing with Python source code and variable
confusions, but that's a term that is well understood.
It's not like Unicode is the only way to write obfuscated code,
malicious or otherwise.
But to the extent that it is a security concern, it's not one that
linters can really cope with. I'm not sure how a linter would stop
someone from publishing code on PyPI that causes confusion by its
character encoding, for instance.
Do we require that PyPI prevents people from publishing code that causes
confusion by its poorly written code and obfuscated and confusing
identifiers?
The linter is to *flag the issue* during, say, code review or before
running the code, like other code quality issues.
If you're just running random code you downloaded from the internet
using pip, then Unicode confusables are the least of your worries.
I'm not really sure why people get so uptight about Unicode confusables,
while being blasé about the opportunities to smuggle malicious code into
pure ASCII code.
Right, which is why I was NOT talking about confusables. I don't
consider them to be a particularly Unicode-related threat, although
the larger range of available characters does make it more plausible
than in ASCII.
But I do see a problem with code where most editors misrepresent the
code, where abuse of a purely ASCII character encoding for purely
ASCII code can cause all kinds of tooling issues. THAT is a more
viable attack vector, since code reviewers will be likely to assume
that their syntax highlighting is correct.
And yes, I'm aware that Python can't be expected to cope with poor
tools, but when *many* well-known tools have the same problem, one
must wonder who should be solving the issue.
This is a very good point. Let's not point fingers, but figure out how
to make users' lives easier together :)
This was the first time I was "in" on an embargoed "issue", and let me
tell you, I was surprised by the amount of time spent on polishing the
messaging. Now, you can't reasonably twist all this into a "Python is
insecure" or "Company X products are insecure" headline, which is good,
but with that out of the way we can focus on *what* could be improved
over *where* the improvement could be and who should do it.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/FNUZCNDF7K2LLHRYRDYY3ZZYISRCI4XJ/
Code of Conduct: http://python.org/psf/codeofconduct/
