Skip to content

[8.0] Don't apply saferEval default length cap to workflow XML values#8629

Open
sfayer wants to merge 2 commits into
DIRACGrid:rel-v8r0from
sfayer:bp_wfevalv8
Open

[8.0] Don't apply saferEval default length cap to workflow XML values#8629
sfayer wants to merge 2 commits into
DIRACGrid:rel-v8r0from
sfayer:bp_wfevalv8

Conversation

@sfayer

@sfayer sfayer commented Jun 18, 2026

Copy link
Copy Markdown
Member

v8 backport of #8628.

BEGINRELEASENOTES
*Workflow
FIX: increased saferEval limit to 1 MiB for Workflow XML handling
ENDRELEASENOTES

@fstagni fstagni closed this Jun 18, 2026
@fstagni fstagni reopened this Jun 18, 2026
fstagni
fstagni previously approved these changes Jun 18, 2026
@fstagni

fstagni commented Jun 18, 2026

Copy link
Copy Markdown
Contributor

Please consider adding also #8635

ryuwd added 2 commits June 19, 2026 15:52
Commit bf6858d replaced eval() with saferEval() in WorkflowReader to avoid
evaluating arbitrary code. saferEval enforces a 2048-byte cap, but non-string
workflow parameters (lists/dicts serialised as repr()) are KB-scale and
routinely exceed it, so parsing legitimate workflows failed with
"Object string is too long (>2048 bytes)".

Pass a generous finite cap (1 MiB) at this call site instead of the 2048
default. literal_eval still prevents code execution regardless of content;
the ceiling remains as defence-in-depth against pathological/malicious input,
bounding literal_eval's object-allocation blow-up. Legitimate workflow values
never approach it. SaferEval's default is left unchanged for its other callers.
Commit bf6858d replaced eval() with saferEval() in Workflow/Utility.substitute
to avoid evaluating arbitrary code. saferEval enforces a 2048-byte cap, but
non-string workflow parameters (lists/dicts) are KB-scale and routinely exceed
it, so substituting variables into a large parameter failed with
"Object string is too long (>2048 bytes)".

Pass a generous finite cap (1 MiB) at this call site instead of the 2048
default, matching the fix in WorkflowReader. literal_eval still prevents code
execution regardless of content; the ceiling remains as defence-in-depth
against pathological/malicious input. SaferEval's default is unchanged for its
other callers.
@sfayer sfayer changed the title [8.0[ Don't apply saferEval default length cap to workflow XML values [8.0] Don't apply saferEval default length cap to workflow XML values Jun 19, 2026
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.

3 participants