[Flang] Loop Interchange

[Meinersbur]

No description provided.

To fix the code injection risk, we must change how the $BENCHMARKS data (which is environment variable-bound from user input) is consumed in the workflow steps that run shell commands. The best practice is to avoid direct usage of ${{ steps.vars.outputs.benchmarks }} in the shell lines, instead setting an environment variable (as is already done with other values) and using native shell variable syntax with proper quoting: "$BENCHMARKS".

Concretely, in all run: commands where ${{ steps.vars.outputs.benchmarks }} appears, refactor the step to set benchmarks: ${{ steps.vars.outputs.benchmarks }} in the env: section, and then reference it inside the run: | block using "$benchmarks" (the value is inherited as a lower-case shell variable). Make sure to quote the variable correctly inside shell commands to prevent injection via whitespace or metacharacters.

Edit the block (line 71 and line 77) accordingly.

No additional method definitions or helper scripts are needed. There is no need to install any new dependencies.

---

To fix the code injection vulnerability, we need to ensure the untrusted input (${{ steps.vars.outputs.benchmarks }}) is not interpolated directly into the shell in the run: block. Instead, assign it to an environment variable in the workflow step (env:), and then refer to it in the shell using normal shell variable syntax ($BENCHMARKS). The change should be made in the step starting at line 75 (Run candidate), specifically on line 77. For defense-in-depth, consider quoting appropriately around the variable if it is used as a command argument to prevent further injection.

This requires:

• Moving the ${{ steps.vars.outputs.benchmarks }} interpolation from command arguments into an environment variable (env: BENCHMARKS: ${{ steps.vars.outputs.benchmarks }}).
• Changing the shell command to use $BENCHMARKS as the argument (quoting it if possible).
• No additional package imports or modifications necessary outside of these lines.

---