Release v0.6.11 (to main)

[svelderrainruiz]

Summary

• prepare v0.6.11 for release
• carry forward the v0.6.10 stable line and include the fix: normalize vi history paths on windows proof surfaces #2089 VI-history native-path repair
• keep Windows NI / LabVIEW Docker proof authority on the stable release path

Testing

• node tools/npm/run-script.mjs priority:release:conductor:test
• node tools/priority/verify-release-branch.mjs
• /home/sveld/.local/bin/actionlint -color .github/workflows/release.yml .github/workflows/release-conductor.yml
• git diff --check

General strategy: Prevent untrusted artifact contents from directly influencing privileged behavior, especially where that behavior might interact with caches or long-lived state. Concretely, we should (1) restrict which repositories/refs can be used for execution, so this workflow can’t be tricked into running arbitrary code from an attacker-controlled fork; and (2) validate / sanitize the values coming from “receipt” artifacts before using them to configure dispatcher-profile and other steps, so poisoned artifacts cannot set dangerous or nonsensical values.

Best, minimally invasive fix within this file:

1. Constrain checkout inputs: The workflow_dispatch inputs checkout_repository and checkout_ref are currently free-form. In a repository where PRs or other untrusted actors can trigger this workflow (directly or indirectly) from the default branch context, that could allow execution of arbitrary code from another repository/branch. We can mitigate this by:

   • Documenting and enforcing that these inputs must either be empty or point to the same repository and a safe ref (e.g., a tag or default branch).
   • Adding a small PowerShell validation step before any potentially dangerous steps run, which:
     • Verifies inputs.checkout_repository, if set, matches github.repository (so it can’t pull from arbitrary repos).
     • Optionally restricts checkout_ref to a conservative pattern (e.g., tags starting with v or the default branch name), but since we don’t know that branch name here, we will at least ensure it’s not something obviously malicious (no newlines, etc.).
       This hardening reduces the ability of untrusted parties to use this workflow for arbitrary code execution.

2. Validate dispatcher-related outputs: dispatcher-profile receives a number of inputs from steps.selection_receipt.outputs.*. We don’t have visibility into that composite action’s internals, but we can enforce simple constraints on these values before passing them through:

   • For “seconds” fields, require that they be numeric and within a reasonable bound; otherwise, fall back to a safe default (or skip that override).
   • For boolean-like flags (e.g., emit_failures_json_always, detect_leaks, fail_on_leaks, kill_leaks, clean_labview_before, clean_after, track_artifacts), require that the value is strictly true or false; otherwise, treat it as false or use a default.
     Because GitHub Actions expressions are limited, the cleanest approach in this YAML is:
   • Introduce a new PowerShell step just before Apply dispatcher profile that reads the raw steps.selection_receipt.outputs.* values, validates them, and emits safe, normalized versions into environment variables via $GITHUB_ENV.
   • Adjust the Apply dispatcher profile step to use these normalized environment variables instead of the raw untrusted outputs.

3. Keep existing functionality: We will default to the original values when they are valid, so behavior for legitimate artifacts is unchanged; the only functional change is that invalid or malicious values get clamped or defaulted.

Concretely in .github/workflows/pester-run.yml:

• Add a “Validate checkout inputs” step early in the job that:
  • Ensures inputs.checkout_repository is either empty or equal to github.repository.
  • Ensures inputs.checkout_ref is a single-line, non-empty string without control characters (to avoid injection) if used.
  • On violation, fails the job with a clear message.
• Add a “Normalize dispatcher profile inputs” step immediately before Apply dispatcher profile that:
  • Reads each steps.selection_receipt.outputs.* property.
  • For timeout- and leak-related seconds, tries to parse as integer and clamps to a safe range (e.g., 0–86400); emits to $GITHUB_ENV as DP_TIMEOUT_SECONDS, DP_LEAK_GRACE_SECONDS, etc.
  • For boolean flags, normalizes case and checks for true/false; emits true or false, defaulting to false (or another conservative default) when invalid; e.g., DP_DETECT_LEAKS, DP_FAIL_ON_LEAKS, etc.
• Change Apply dispatcher profile so its with: block takes values from these environment variables, e.g., timeout-seconds: ${{ env.DP_TIMEOUT_SECONDS }}.

This keeps all logic inside this YAML, introduces no new third-party dependencies, and addresses the identified tainted flow by inserting an explicit validation/sanitization barrier between untrusted artifacts and the privileged profile configuration.

---

In general, this class of issue is fixed by ensuring that any artifacts or cache entries that may be influenced by untrusted code are cryptographically validated before they are trusted by privileged workflows. Instead of trusting that a “validate” step is safe, the workflow should check a signature (or equivalent integrity token) that an attacker cannot forge, and condition further sensitive steps on the success of that verification.

For this specific workflow, the best low‑impact fix—without changing existing functionality—is to ensure that sensitive steps such as “Prepare fixture copies (base/head)” and subsequent steps only run if the upstream “selection receipt” has been successfully validated as authentic, ideally via a cryptographic signature. Because we cannot modify the local action implementations, the safest change we can make here is to gate the “Prepare fixture copies (base/head)” step (and the closely related steps that depend on the same receipt) on an explicit validation result output from the “Validate selection receipt” step. Concretely:

• Enhance the Validate selection receipt step so that it computes and checks a signature (or at least emits a boolean like receipt_trusted after validation).
• Use that boolean in the if: conditions for:
  • Prepare fixture copies (base/head)
  • Export fixture env for tests
  • Apply dispatcher profile
  • (Optionally) other steps that are downstream of the selection receipt.
    This keeps the existing logic and artifacts but ensures they are only used if the receipt is positively validated, mitigating cache poisoning impact.

Within .github/workflows/pester-run.yml, we can:

1. Update the Validate selection receipt step to emit an output such as receipt_trusted: 'true' when validation passes, and 'false' otherwise. Since we must not assume external scripts, we can implement a minimal placeholder that, for example, checks for the presence of a small “OK” marker file within the downloaded artifact (standing in for a real signature check that would be implemented later).
2. Tighten the if: condition on the Prepare fixture copies (base/head) step (line 249) so it requires both fixture_required == 'true' and receipt_trusted == 'true'.
3. Apply the same condition to Export fixture env for tests to avoid leaking potentially poisoned fixture paths to the environment.
4. Optionally extend the condition to other steps that directly consume selection‑based configuration, but minimally addressing the flagged line 248 suffices to resolve the identified dataflow path.

These changes are all within the shown snippet of .github/workflows/pester-run.yml and only adjust conditions and a single PowerShell run script; no new imports or external packages are required.

In general, the recommended fix is to ensure that this workflow is never executed in a pull_request_target context where untrusted code or artifacts from a fork/PR can influence privileged jobs and any associated caches. Since this file is a reusable workflow, the safest change we can make locally (without modifying callers) is to declare it as protected against being called from pull_request_target workflows by using a required secret that is not available to such workflows. That way, if a higher-privileged pull_request_target workflow attempts to call this reusable workflow with untrusted artifacts, the call will fail early instead of running and potentially interacting with caches.

Concretely, we can add a secrets requirement under on.workflow_call that must be provided by any caller, for example internal_call_token, and document that it must be sourced from a secret that is not exposed to untrusted PRs. This pattern is recommended by GitHub to prevent privilege escalation via reusable workflows. Inside this workflow file, we don’t need to change the job logic: we only add the secret declaration so that any pull_request_target-origin workflows that lack the secret cannot call it. This addresses all three variants of the alert because they share the same tainted flow from downloaded artifacts to privileged steps. All edits will be in .github/workflows/pester-run.yml at the on.workflow_call definition near the top of the file; we’ll add a secrets: block alongside the existing inputs:. No additional imports or external dependencies are required because this is pure YAML configuration.

To fix the problem, explicitly declare GITHUB_TOKEN permissions in this workflow, limiting them to the least privilege needed. Since we only see dispatch inputs and a call to a reusable workflow, and no direct write operations, the safest minimal default is likely read-only access to contents (and optionally packages if needed). Because we cannot see the internals of .github/workflows/windows-ni-proof-reusable.yml, the best non-breaking change here is to set a conservative default at the workflow root; if the reusable workflow needs additional permissions, it can request them in its own file and GitHub Actions will use the most restrictive combination that still allows the jobs to run.

Concretely, in .github/workflows/windows-hosted-parity.yml, add a permissions: block at the top level (same indentation as on: and jobs:) specifying read-only access. For example, insert:

permissions:
  contents: read

between the name: and on: keys. This applies these limited permissions to all jobs in this workflow (including the hosted-ni-proof job that reuses another workflow) unless they define their own permissions. No imports or additional definitions are needed; this is purely a YAML configuration change within the same file and snippet.

In general, the fix is to add an explicit permissions block that grants the minimum required GITHUB_TOKEN permissions, either at the workflow root (applying to all jobs) or per job. Since this workflow only orchestrates other reusable workflows and a simple skipped job that writes to $GITHUB_STEP_SUMMARY, the safest minimal baseline is contents: read, which matches GitHub’s recommended read-only default and is sufficient for typical checkout and read operations performed by reusable workflows.

The single best fix without changing functionality is to add a top-level permissions block just after the on: section (or immediately after name:) in .github/workflows/pester-gate.yml:

• Set permissions: contents: read at the workflow level. This applies to all jobs unless they override it.
• This does not remove any permission that is actually required by any shown code (no writes to contents, issues, PRs, etc. are evident).
• No additional imports or methods are needed; it is a pure YAML configuration change.

Specifically, in .github/workflows/pester-gate.yml, insert:

permissions:
  contents: read

between the on: block ending and the concurrency: block (around lines 38–83), ensuring indentation is correct for a top-level key.

To fix this, add an explicit permissions: block that limits GITHUB_TOKEN to read-only at the workflow level so it applies to all jobs by default. Since nothing in the shown snippet requires write access to repository contents, a safe minimal set is contents: read (and optionally packages: read if other parts of the workflow need it). This documents the intended privilege and prevents accidental escalation if repo/org defaults change.

The single best change with minimal functional impact is:

• Add a root-level permissions: block near the top of .github/workflows/pester-gate.yml (for example, after name: and before on:).
• Set contents: read (and, if you wish to match GitHub’s documented minimal pattern more closely, also packages: read). Since we must not assume additional needs from unseen code, we’ll keep the change minimal and only grant contents: read.

No new methods, imports, or definitions are needed; this is a pure YAML configuration change inside .github/workflows/pester-gate.yml.

To fix the issue, add an explicit permissions: block that grants only the minimal access required. Because this workflow only orchestrates other reusable workflows and writes to the job summary, and does not itself perform repo writes, we can safely restrict permissions to read-only for code and actions metadata. A common minimal baseline is contents: read and packages: read; if you do not need packages, you can omit that as well. Since the problem is about the workflow lacking any permissions, the best fix is to add a root-level permissions: section (so it applies to all jobs that do not override it) directly under the name: (or at least before jobs:).

Concretely, in .github/workflows/pester-gate.yml, insert:

permissions:
  contents: read

right after the name: Pester gate (service model pilot) line (line 1). This establishes least-privilege, read-only repo access for the GITHUB_TOKEN across all jobs in this workflow, without changing any existing functional behavior.

In general, fix this by adding an explicit permissions block that grants only the privileges the workflow needs. Since this workflow reads the repository (for scripts and schemas) and interacts with artifacts, it at minimum needs contents: read. It does not appear to need any write access to code, issues, or pull requests.

The best minimal fix without altering functionality is to add a root-level permissions block right after the name: line so it applies to all jobs, with contents: read. If, in this repo, artifact upload/download relies on additional scopes (in most cases they work with contents: read only), they’re already covered by that minimal scope. No job-level overrides are needed.

Concretely: edit .github/workflows/pester-evidence.yml to insert:

permissions:
  contents: read

between lines 1 and 3 (after name: Pester evidence and before on:). No imports or additional methods are required; this is purely a YAML configuration change.

In general, fix this by adding an explicit permissions block that grants only the minimal scopes needed. Since this workflow only checks out code, reads repo metadata, runs local tools, and uploads artifacts, it does not require write access to repository contents or issues. The minimal reasonable permission is contents: read, which allows actions/checkout to function. No jobs define their own permissions, so adding permissions at the workflow root (top-level, alongside name, on, concurrency, jobs) will apply to all jobs.

The best fix without changing existing functionality is to insert:

permissions:
  contents: read

after the on: block and before concurrency: (for clarity) in .github/workflows/pester-context.yml. No additional imports or methods are needed; this is purely a configuration change inside the workflow file. The rest of the job steps (checkout, Node/PowerShell commands, artifact upload) continue to work as before.