Steve Dower <[email protected]> added the comment:
There's a working POC out there for modifying tuple elements that relies on the
fact that id() returns real memory addresses, so I don't see it as a harmless
thing. Also, Rust is only worrying about code that's put into its compiler,
whereas Python has to worry about any code that might be injected into a
running process, which is vastly easier than in Rust. The situations don't
really compare.
It's also part of defense-in-depth. If there's no good reason to make it
trivial for people to locate TLS-specific data structures in memory, why make
it trivial? It's probably still possible (turns out everything is...), but it's
worth raising the complexity and lowering the reliability by making someone
jump through crazy hoops to get it.
> The second issue seems like the big blocker. Your example does
> `ctypes.CDLL("libssl.so.1.1")`, but there's no guarantee that this will find
> the same libssl that the `ssl` module is linked against.
On Windows, it's spelled "libssl-1_1", but it *is* guaranteed to load the right
one. However, I'd rather encode this information somewhere inside _ssl than
making it a guarantee (as presumably OpenSSL 3.0 will change this name
structure).
Also, this is not the same as ssl._ssl.__file__. So yeah, this aspect is not
very portable, which is why I'd rather it just be exposed as a "call OpenSSL
function on this context by name".
> I don't want to import ctypes from the ssl module code.
Import it in the function when it's called, then. Reimports are so close to
free they're basically irrelevant, and if your tight inner loop includes TLS
then it's not actually a tight inner loop, so looking in sys.modules isn't
going to hurt anyone.
I would definitely push back on importing it eagerly in ssl.py :)
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue43902>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
