>which creates a new REPL with some very important changes
I don't like shrug! I don't want any shrug!
... Of course, if you can arrange for the target system to decode and execute the embedded code, it's already compromised...
>eval doesn't like statements and everyone already knows to suspect exec code.
If people don't equally well suspect `eval` then education attempts have seriously failed.
Incidentally: one way every Pythonista can help improve OSS is to search on GitHub for insecure-but-intentional - as well as inappropriate-but-legitimate -uses of `eval` to submit PRs. For example, it often gets used to convert hex digits to raw byte values (https://github.com/search?q=%22eval%28%5C%220x%22+lang%3APyt...), rather than simply passing a `base` argument to `int`.
> If people don't equally well suspect `eval` then education attempts have seriously failed.
Haha yes, that statement was mostly made in jest. I would hope most people would be just as suspicious of an eval one liner with a singular emoji. Does make it slightly less suspicious than an equivalent eval which doesn't have 50 invisible bytes.
Good shout on fixing issues with eval in OSS--I think I might do that!
I don't like shrug! I don't want any shrug!
... Of course, if you can arrange for the target system to decode and execute the embedded code, it's already compromised...
>eval doesn't like statements and everyone already knows to suspect exec code.
If people don't equally well suspect `eval` then education attempts have seriously failed.
Incidentally: one way every Pythonista can help improve OSS is to search on GitHub for insecure-but-intentional - as well as inappropriate-but-legitimate -uses of `eval` to submit PRs. For example, it often gets used to convert hex digits to raw byte values (https://github.com/search?q=%22eval%28%5C%220x%22+lang%3APyt...), rather than simply passing a `base` argument to `int`.