Bugprone unsafe format string

[dkrupp]

Add a new bugprone-unsafe-format-string clang-tidy checker, which warns for scanf and sprintf like functions invocations with a format string literal with unbounded %s specifier that can cause buffer overflow.

The best approach is to ensure that untrusted code is not checked out in contexts where repository secrets may be available or privileged actions may be performed. This can be done by splitting the workflow into two parts:

1. An initial workflow triggered by a non-privileged event (pull_request) that checks out and builds untrusted code, then uploads the test results or artifacts.
2. A second, privileged workflow triggered by workflow_run on successful completion of the first workflow, which downloads and verifies the artifacts and performs safe post-processing or reporting.

The recommended fix is to refactor .github/workflows/hlsl-test-all.yaml so that it:

• Is not directly triggered by a privileged event (workflow_call from untrusted contexts).
• If workflow_call must be preserved, ensure that only trusted workflows can trigger it and that the input values are validated.
• Otherwise, use a two-workflow architecture: one for untrusted code checkout/build on pull_request, and a separate one for privileged operations on workflow_run.

Since we are only to change code in the snippet, not the overall architecture outside the given file, the best available (and minimal) mitigation is to validate the input values for refs before using them for checkout, or, at the very least, restrict allowable refs to known safe branches (e.g., not arbitrary user-controlled values). Specifically, before performing the actions/checkout with the user-input ref, ensure that it matches a whitelist (main, release/*, etc.), and otherwise fail the workflow.

This can be done by adding a step that checks (using shell or GitHub Actions expressions) that the ref matches a safe pattern, and only proceeds if so, otherwise the workflow exits with failure.

In YAML, this is done by introducing a step prior to the checkout like:

- name: Validate LLVM branch
  run: |
    if [[ "${{ inputs.LLVM-branch }}" != "main" && ! "${{ inputs.LLVM-branch }}" =~ ^release/ ]]; then
      echo "Unsafe LLVM branch ref: ${{ inputs.LLVM-branch }}"
      exit 1
    fi

The subsequent checkout step should use this validated input.

The best way to fix the problem is to split the workflow into two parts:

1. Untrusted job: Runs on pull_request, checks out and builds/test the PR code, but has minimal permissions and no access to secrets. It uploads only the generated results (such as ABI dumps or logs) as workflow artifacts.
2. Privileged job: Is triggered after a successful completion of the untrusted pull_request workflow via workflow_run (monitoring the untrusted workflow). It runs with elevated permissions and/or secrets if needed. It downloads artifacts from the previous run, verifies them, and performs privileged actions (e.g., uploading, commenting, reporting).

For this workflow, specifically:

• Remove the direct pull_request trigger on the privileged workflow.
• Configure one workflow .github/workflows/llvm-abi-tests.yml to run on pull_request and generate artifacts, without any access to secrets.
• Create a second workflow .github/workflows/llvm-abi-process.yml (naming example) which runs on workflow_run upon completion of the first, and processes the results as needed.
• Make sure the artifact files are validated in the second workflow.

For this fix, we will remove any privileged contextual access from jobs that checkout and run PR code. This means strictly:

• Remove or strictly limit permissions in .github/workflows/llvm-abi-tests.yml.
• Ensure any job acting on untrusted code (checking out ${{ github.sha }} or ${{ github.repository }} at PR HEAD) cannot access secrets, is isolated, and only produces artifacts.
• If privileged steps are needed, they should be in a separate workflow run after artifact mediation.

This requires breaking the invariant on the lines flagged (i.e., avoid checkout and running PR code in privileged context), restricting secrets, and possibly annotating the workflow for future maintainers.

---

To fix this, the workflow should explicitly restrict which git references can be checked out in the privileged context. Specifically:

• Validate that the ref is one of a trusted set (for example, an official release tag, branch, or commit hash from the main repository).
• Only allow checkouts from the upstream repository, not forks.
• The best approach is to sanitize (validate or restrict) user input coming from workflow inputs/variables.
• Implement a check after the variable is set which validates it is an allowed release tag, matching an official pattern (e.g., llvmorg-[0-9]+\.[0-9]+\.[0-9]+.*), and error/fail if not.
• This check should be done either in the "Collect Variables" step or as a dedicated "Validate Ref" step before the checkout.
• The checkout step should then only proceed if the ref is validated.

Needed:

• In the job build-release-package, before the checkout step, add a validation step.
• In the bash script, check if ${{ needs.prepare.outputs.ref }} matches the allowed pattern. Fail otherwise.

---