8000 Parse noise dictionaries as literals rather than executable expressions by jdotc1 · Pull Request #616 · brainiak/brainiak · GitHub
[go: up one dir, main page]

Skip to content

Parse noise dictionaries as literals rather than executable expressions - #616

Open
jdotc1 wants to merge 2 commits into
brainiak:masterfrom
jdotc1:fix/parse-noise-parameters-as-literals
Open

jdotc1 wants to merge 2 commits into
brainiak:masterfrom
jdotc1:fix/parse-noise-parameters-as-literals

Conversation

@jdotc1
@jdotc1 jdotc1 commented Oct 14, 2026
Copy link
Copy Markdown

Summary

The real-time generator reads a caller-selected noise-parameter file and evaluates its contents with eval. A file treated as data can therefore execute Python with the process privileges. The bundled parameter dictionary does not require execution.

Replace eval with ast.literal_eval and document the literal-only restriction in the code.

Scope and compatibility

NOT drop-in for all saved files: expressions and NumPy-2 representations such as np.float64(...) are intentionally rejected. calc_noise() can produce NumPy scalar values; convert these to native scalar literals when serializing before using this patch. No general safe NumPy-expression parser is attempted. literal_eval also does not impose input-size/depth limits.

Validation

4 new focused tests passed, exercising the actual generate_data loading path with computational simulation boundaries mocked: literal files, literal bytes, NumPy constructor rejection, and rejection of an expression with a synthetic side-effect marker. The source checkout lacked its generated version module, so the runner supplied package-version metadata only. No full simulation or compiled BrainIAK build.

The supplied source-level evidence for the unchanged fix was reused. No full-project suite, model download, or clinical data was used.

Compatibility migration

This intentionally rejects executable expressions, including NumPy scalar constructor representations. The public function documentation shows how to convert scalar parameters with value.item() before serializing with repr(). A release-news fragment is included.

@mihaic
mihaic commented Oct 14, 2026
Copy link
Copy Markdown
Member

@jdotc1, thanks for the PR. It makes sense to me to eliminate eval (literal_eval can still cause a crash, but it is an improvement).

@CameronTEllis, do you think users currently rely on saved noise dicts with np.float64 or similar expressions that would be rejected?

@jdotc1
jdotc1 commented Oct 20, 2026
Copy link
Copy Markdown
Author

The current patch includes a migration example in the public function documentation and a release note. The example shows how to convert NumPy scalar values to native Python values before saving the dictionary. That helps create compatible files; existing files containing NumPy constructor expressions still need to be re-saved. I don't have evidence about how many users rely on those files, so I'll wait for Cameron's guidance on that compatibility decision.

This branch has not been deployed

No deployments
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.

2 participants

0