> On Aug 25, 2017, at 13:22, Steve Dower <[email protected]> wrote: > (This is also the reasoning for using static variables internally rather than > interpreter state - it's much harder to infer the address of a static C > variable with pure Python code than a field in a struct.)
I'll add a little bit of detail. These aren't "security features"; they're "security transparency features." We acknowledge that we cannot block every malicious payload, but we should at least make it possible to audit interpreter state for post-mortem forensic purposes. We wouldn't want it to be too easy to turn off these auditing features, and I've done a good amount of research into corrupting the running state of a CPython interpreter. Keeping things in builtin modules and in memory not directly exposed to the interpreter creates a real barrier to these techniques, and makes it meaningfully harder for an attacker to just disable the features at the start of their payload. :h _______________________________________________ Security-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/security-sig
