[DO NOT MERGE] Test

[lamb-j]

No description provided.

To fix the problem, the workflow should explicitly specify restricted GITHUB_TOKEN permissions instead of relying on repository defaults. Since this job only runs a shell command and does not need to interact with the GitHub API, the safest and least-privileged configuration is to set permissions: { contents: read } (or even permissions: {} if your policies allow that). Adding the permissions block at the workflow root will apply to all jobs that do not override it.

The single best way to fix this without changing existing behavior is to add a permissions block near the top of .github/workflows/ci_weekly.yml, just under the name: (or under on: if you prefer), setting contents: read. No imports or additional definitions are needed because this is a YAML configuration change only. The donothing job can remain unchanged and will inherit these minimal permissions.

Concretely:

• Edit .github/workflows/ci_weekly.yml.
• Insert a top-level permissions: section after line 1 (or between lines 2 and 3) with contents: read.
• Leave the jobs section and donothing job untouched so functionality stays the same.

In general, to fix this class of problems in GitHub Actions, you avoid interpolating ${{ ... }} expressions directly in a shell script. Instead, you assign the untrusted value to an environment variable in the env: block of the step, and then reference it using normal shell variable syntax (e.g. $ORG_NAME) inside the script. This prevents GitHub’s expression engine from injecting content directly into the script body and keeps all potentially unsafe characters confined to data variables, which the shell will handle as data rather than code.

For this specific workflow, we should move ${{ github.repository_owner }} (and for consistency, ${{ github.event.repository.name }} and ${{ inputs.JOB_NAME_TO_MATCH }}) into the step’s env: block, then update the script to use the corresponding shell variables. Concretely, in .github/workflows/teams_notifier.yml within the “Calculate URLs and Fetch Manifest” step, extend the env: section to define ORG_NAME, PROJECT_NAME, and JOB_NAME_TO_MATCH using GitHub expression syntax. Then, in the run: script, replace the lines that assign ORG_NAME and PROJECT_NAME using ${{ ... }} with references to the shell environment variables directly, and change the jq invocation to use the JOB_NAME_TO_MATCH shell variable instead of injecting ${{ inputs.JOB_NAME_TO_MATCH }}. This keeps current behavior (same values, same logic) while eliminating the direct expression interpolation inside the script.

General approach: avoid using the GitHub expression ${{ github.event.repository.name }} directly within the shell script body. Instead, assign that expression to an environment variable at the step level, and inside the script read it using normal shell variable expansion ($PROJECT_NAME). This follows the documented pattern: set untrusted input in env: and use it with native shell syntax.

Best concrete fix here:

• Modify the Calculate URLs and Fetch Manifest step to include ORG_NAME and PROJECT_NAME in the env: section:
  • ORG_NAME: ${{ github.repository_owner }}
  • PROJECT_NAME: ${{ github.event.repository.name }}
• In the run: script, remove the direct ${{ ... }} usage and rely on the environment variables already populated by GitHub:
  • Delete the lines that assign ORG_NAME and PROJECT_NAME via expressions.
  • The rest of the script (JOBS_URL="https://api.github.com/repos/$ORG_NAME/$PROJECT_NAME/actions/runs/$RUN_ID/jobs" ...) can remain unchanged, since $ORG_NAME and $PROJECT_NAME will now come from env.

This change is localized to .github/workflows/teams_notifier.yml, within the shown step. No new methods or external tools are needed; we just adjust the env: section and simplify the script.

---

To fix the problem, move the untrusted inputs.JOB_NAME_TO_MATCH expression out of the shell script and into an environment variable defined in the step’s env: section, then reference that variable using normal shell syntax ($VAR) inside the run: block. This prevents GitHub Actions from inlining the expression directly into the generated shell code and aligns with the recommended pattern for avoiding code injection.

Concretely, in the Calculate URLs and Fetch Manifest step, add an environment variable such as JOB_NAME_TO_MATCH: ${{ inputs.JOB_NAME_TO_MATCH }} under env:. Then, inside the run: script, replace ${{ inputs.JOB_NAME_TO_MATCH }} in the jq invocation with $JOB_NAME_TO_MATCH. No functional behavior changes: jq --arg JOB_NAME ... still receives the same string value, but the value is now passed through the environment rather than interpolated into the script text. No additional imports or external tooling are needed beyond what is already used.

To fix this, we should avoid using ${{ github.run_id }} directly in the shell script body and instead inject it into the step’s environment via env:. Inside the script, we then use normal shell variable expansion ($RUN_ID) when writing to $GITHUB_ENV. This matches the recommended “indirect” pattern and removes the code injection concern, without changing the effective behavior of the workflow.

Concretely, in the “Set environment variables” step (lines 59–65):

• Add an env: section that defines a temporary environment variable, e.g. RUN_ID_INPUT: ${{ github.run_id }}.
• In the run: block, change the line that currently writes RUN_ID=${{ github.run_id }} to instead write RUN_ID=$RUN_ID_INPUT, using shell syntax.
• The other echo lines remain unchanged.
• No additional imports or external dependencies are needed because this is purely YAML and shell changes inside the workflow.

General approach: avoid interpolating GitHub expression syntax directly into the shell script in the run: | block. Instead, assign any such values to environment variables via the env: mapping and then reference those variables using normal shell syntax ($VAR) inside the script. This follows GitHub’s documented pattern to prevent code injection.

Best concrete fix here: add environment variables for the needed job results in the Notify status step, and change the if condition to compare those shell variables rather than embedding ${{ needs.*.result }} inside the script. That is, in the env: section of the Notify status step, define e.g. WINDOWS_RESULT: ${{ needs.windows_build_and_test.result }} and LINUX_RESULT: ${{ needs.linux_build_and_test.result }}. Then, in the run: block, replace the condition on line 91 with one that uses $WINDOWS_RESULT and $LINUX_RESULT. No additional imports or external tools are required; all changes are confined to .github/workflows/teams_notifier.yml in the Notify status step.

Specifically:

• Edit the Notify status step’s env: block (around lines 83–87) to add two new entries:
  • WINDOWS_RESULT: ${{ needs.windows_build_and_test.result }}
  • LINUX_RESULT: ${{ needs.linux_build_and_test.result }}
• Edit the run: block so that the if statement on line 91 becomes:
  • if [ "$WINDOWS_RESULT" = "success" ] && [ "$LINUX_RESULT" = "success" ]; then

Functionality remains identical, but the workflow now follows the safe pattern and satisfies the CodeQL rule.

To fix the issue, we should stop using ${{ github.repository }}, ${{ github.ref_name }}, and ${{ github.run_id }} directly inside the shell script body. Instead, set them as environment variables in the env: block of the step, and then use standard shell variable expansion ($REPOSITORY, $REF_NAME, $GITHUB_RUN_ID) within run:. This follows the recommended pattern: use expressions only in env: and let the shell read them from the environment.

Concretely, in .github/workflows/teams_notifier.yml, in the “Notify status” step:

• Extend the env: section to include:
  • REPOSITORY: ${{ github.repository }}
  • REF_NAME: ${{ github.ref_name }}
  • GITHUB_RUN_ID: ${{ github.run_id }}
• In the run: script:
  • Replace all ${{ github.repository }} occurrences with $REPOSITORY.
  • Replace ${{ github.ref_name }} with $REF_NAME.
  • Replace ${{ github.run_id }} with $GITHUB_RUN_ID.
• Keep RUN_ID usage as is (it already comes from env.RUN_ID), or, if needed, reference it consistently as $RUN_ID.

This change does not alter the logical behavior: the same values are used, just passed via environment variables, removing the direct expression usage from the script and eliminating the code-injection warning.

In general, to fix this issue we must not interpolate ${{ github.ref_name }} directly inside the shell script body. Instead, we should assign it to an environment variable using GitHub Actions expression syntax, and then access it using standard shell expansion ($REF_NAME). This avoids mixing GitHub’s expression syntax with the shell’s parsing in run: blocks and aligns with recommended patterns for untrusted inputs.

Concretely, in .github/workflows/teams_notifier.yml, within the Notify status step, add an environment variable like REF_NAME: ${{ github.ref_name }} under the env: section. Then, replace both occurrences of ${{ github.ref_name }} in the JSON construction with $REF_NAME. The rest of the step remains unchanged. No additional imports or external tools are required because we are only modifying how the existing input is wired into the script.

In general, to fix this type of issue in GitHub Actions, avoid using ${{ ... }} directly inside the shell script body. Instead, map any potentially untrusted values into environment variables via env: and then reference them using the shell’s own variable expansion ($VAR). This way, the expression is resolved by the Actions runner outside the shell script, and the shell only ever sees plain environment variables.

For this specific workflow, the risky values are the GitHub context fields used inside the run: script: github.repository, github.ref_name, github.run_id, and the existing env.RUN_ID. We should: (1) add environment variables in the env: section of the “Notify status” step for each of these values; (2) update the script body so that it uses $REPOSITORY, $BRANCH, and $RUN_ID instead of inlined ${{ github.* }} expressions. This preserves all existing behavior (the same strings end up in the JSON) while following the recommended safe pattern.

Concretely, within .github/workflows/teams_notifier.yml in the “Notify status” step (around lines 81–120):

• Extend the env: block with:
  • REPOSITORY: ${{ github.repository }}
  • BRANCH: ${{ github.ref_name }}
  • (Optionally) ensure RUN_ID comes from ${{ github.run_id }} if it is not already set elsewhere; since we are constrained to this snippet, we will leave the existing RUN_ID: ${{ env.RUN_ID }} intact and only use $RUN_ID in the script.
• In the two NOTIFICATION_CONTENT=... assignments, replace all ${{ github.repository }} and ${{ github.ref_name }} (and ${{ github.run_id }}) with the corresponding shell variables: $REPOSITORY, $BRANCH, and $RUN_ID.

This removes the direct use of untrusted GitHub context expressions within the script body, avoids introducing any new behavior, and resolves the CodeQL “code injection” warning.

In general, to fix this class of problems in GitHub Actions, any data that might be considered untrusted (or that a scanner flags) should be passed from the workflow expression context into an environment variable, and then used inside run: via shell-native variable expansion ($VAR), not via ${{ ... }}. This prevents the shell from interpreting injected syntax because the interpolation happens before the shell and the value is treated as data.

For this specific case, we only need to adjust the usage of github.run_id in the run: script. The job already defines RUN_ID: ${{ env.RUN_ID }} in env: at line 86, and then uses $RUN_ID in the main branch of the if (line 110). In the else block at line 119, it still uses the expression ${{ github.run_id }} directly. The best fix is to use the same $RUN_ID variable there, so the run id always comes from the environment, accessed via shell syntax. Concretely:

• In .github/workflows/teams_notifier.yml, within the Notify status step, change the Build Link URL in the else branch (line 119) to reference $RUN_ID instead of ${{ github.run_id }}.
• No new imports or actions are needed; we are only changing the string interpolation method in that line.

In general, to fix this kind of issue in GitHub Actions, you should avoid placing expressions like ${{ secrets.* }} or ${{ github.* }} directly into run: script bodies where the shell will interpolate them as part of a command. Instead, assign the value to an environment variable in the step’s env: block, and then reference that value using native shell syntax ($VAR) within the script. This breaks the expression interpolation from the shell parsing step and aligns with GitHub’s secure usage guidance.

For this specific case, we should move ${{ secrets.AMD_STAGING_NIGHTLY_TEAMS_WEBHOOK_URL }} into an environment variable, e.g. TEAMS_WEBHOOK_URL, in the "Notify status" step’s env: section. Then, in the run: script, replace the direct use of ${{ secrets.AMD_STAGING_NIGHTLY_TEAMS_WEBHOOK_URL }} in the curl command with the shell variable $TEAMS_WEBHOOK_URL. Functionality remains identical: we still send the same JSON payload to the same URL, but the secret is no longer embedded as a GitHub expression inside the shell command.

Concretely:

• Edit .github/workflows/teams_notifier.yml in the "Notify status" step.
• Add a new env: entry: TEAMS_WEBHOOK_URL: ${{ secrets.AMD_STAGING_NIGHTLY_TEAMS_WEBHOOK_URL }}.
• Change the curl line from curl ... ${{ secrets.AMD_STAGING_NIGHTLY_TEAMS_WEBHOOK_URL }} to curl ... "$TEAMS_WEBHOOK_URL".
  No extra methods or external libraries are needed.

---