Warn that overriding __builtins__ for eval is not a security mechanism#145773
Warn that overriding __builtins__ for eval is not a security mechanism#145773StanFromIreland wants to merge 2 commits intopython:mainfrom
__builtins__ for eval is not a security mechanism#145773Conversation
|
|
||
| This function executes arbitrary code. Calling it with | ||
| user-supplied input may lead to security vulnerabilities. | ||
| user-supplied input will lead to security vulnerabilities. |
There was a problem hiding this comment.
| user-supplied input will lead to security vulnerabilities. | |
| un-trusted user-supplied input can easily lead to security vulnerabilities. |
There was a problem hiding this comment.
We are generally trying to strengthen the warning (we held a little vote, people are in favour), but IMO this suggestion reverts that. Might I ask why exactly you want it to be so?
| names, but it is **not** a security mechanism, the executed code can | ||
| still access builtins. |
There was a problem hiding this comment.
| names, but it is **not** a security mechanism, the executed code can | |
| still access builtins. | |
| names, but is **not** a security mechanism: the executed code can | |
| still access all builtins. |
| names, but it is **not** a security mechanism, the executed code can | ||
| still access builtins. |
There was a problem hiding this comment.
| names, but it is **not** a security mechanism, the executed code can | |
| still access builtins. | |
| names, but this is **not** a security mechanism: the executed code can | |
| still access all builtins. |
|
|
||
| This function executes arbitrary code. Calling it with | ||
| user-supplied input may lead to security vulnerabilities. | ||
| user-supplied input will lead to security vulnerabilities. |
There was a problem hiding this comment.
| user-supplied input will lead to security vulnerabilities. | |
| un-trusted user-supplied input can easily lead to security vulnerabilities. |
|
I'm always torn when we change these kind of notes. I don't agree that this will lead to security vulnerabilities. It depends on your threat model. So the "may"/"can" formulation is for me the correct one. What I do find correct however is that untrusted input can lead to security vulnerabilities. I would honestly drop the "easily" part as again it depends on where the untrusted input comes from. For instance, the user can supply an arbitrary string, and that arbitrary string is processed with (highly non-trivial, but still polynomial-time evaluable) reversible transformations that eventually output a string that is then |
This misleads users as it gives the impression that the above warning can be ignored.
📚 Documentation preview 📚: https://cpython-previews--145773.org.readthedocs.build/