Re: PEP 551: Security transparency in the Python runtime

> On Aug 25, 2017, at 13:22, Steve Dower <steve.dower@python.org> 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