Skip to content

Conversation

@EpicWink
Copy link
Contributor

@EpicWink EpicWink commented Feb 9, 2026

Reducing security risk of running arbitrary code.

Resolves #1056

@Gallaecio
Copy link
Member

There is no such a risk here, since the input is safe. And while I am all for removing the use of eval, ast.literal_eval does not seem like much of an improvement. I think the goal of #1056 should be to avoid Python code evaluation in the first place.

@EpicWink
Copy link
Contributor Author

Input is likely safe, but it's still a file which can be changed by any other program without the user noticing. ast.literal_eval has the benefit of only loading basic (literal) values, with the only "security concern" being DoS.

Perhaps instead you could load values as YAML: True and False are valid YAML values for True and False.

@Gallaecio
Copy link
Member

Yes, or lower-case them and use JSON (since there is no built-in YAML support). Of True if value == "True" else False.

I have not looked into the source of the values or into whether or not other values besides those 2 are possible.

@EpicWink
Copy link
Contributor Author

In my own projects, I use:

is_true = string_value.lower() not in {"", "0", "n", "no", "off", "false"}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

get rid of eval

2 participants