fix: grant checks:write to audit job and patch RUSTSEC-2026-0097 (rand 0.8.5 → 0.8.6)

[Copilot]

The CI Security Audit job was failing for two independent reasons: rustsec/audit-check@v2.0.0 requires checks: write to post check-run results (was getting a 403), and cargo audit was flagging rand 0.8.5 as unsound via RUSTSEC-2026-0097.

Workflow permissions

Added checks: write scoped to the audit job only, keeping the global default minimal:

audit:
  permissions:
    contents: read
    checks: write  # required by rustsec/audit-check to create check runs

Dependency fix

rand 0.8.5 is unsound under RUSTSEC-2026-0097 (aliased mutable reference in ThreadRng when a custom logger calls rand::rng() during reseed). Patched in ≥ 0.8.6.

rand enters the graph transitively: ratatui → termwiz/csscolorparser → phf → phf_generator → rand.

Updated Cargo.lock via cargo update -p rand — no Cargo.toml changes needed, semver-compatible within the existing constraint.

Original prompt

Investigate and fix the CI/CD failure in repository oneirosoft/dagger with the smallest possible targeted change set.

Context:

• The latest failing CI run on main is run 24963060628 for commit 17c83af2315a636e5f804a9e289b6af4de7ed7cb.
• Workflow file: .github/workflows/ci.yml.
• The verify job appears to build and test normally.
• The failure is in the audit / Security Audit job.
• Current workflow permissions are only:
  • contents: read
• The audit action uses rustsec/audit-check@v2.0.0 and the failing log includes:
  • No vulnerabilities were found
  • Found 1 unsound
  • Resource not accessible by integration - https://docs.github.com/rest/checks/runs#create-a-check-run

Goals:

1. Reproduce or inspect the failure carefully.
2. Determine the true root cause(s), including whether the failure is only workflow permissions or also a dependency advisory that causes the audit job to fail.
3. Make the minimum surgical code/config changes necessary so that CI passes.
4. Use a separate branch.
5. Run/confirm CI so the pipeline passes.
6. Open a pull request with a concise, descriptive title and summary.

Constraints:

• Keep changes minimal and narrowly scoped to the CI failure.
• Do not refactor unrelated code.
• If a RustSec advisory must be addressed, prefer the least invasive dependency update or lockfile-only change that resolves it.
• If the issue can be solved by workflow permissions alone, verify whether the audit still fails because of the Found 1 unsound result before concluding.
• Ensure the final PR explains both the original failure mode and the fix.

Validation expectations:

• CI workflow should pass on the PR branch.
• Any local validation that is practical should be run.
• The PR should contain only the necessary changes to make the pipeline green.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: You are an expert code analyst and software engineer. Can you look at why CI/CD is failing for the project. Then, after careful inspection, provide an explanation and a plan to address the failure.

Assistant: I’ll inspect the repository’s GitHub Actions runs and logs, then trace the failing workflow steps to identify the root cause and propose a fix plan.

Assistant: I found the failure.

What’s failing

The latest failing CI run is the push-to-main run for commit 17c83af2315a636e5f804a9e289b6af4de7ed7cb:

• Run: CI #125
• Workflow file: .github/workflows/ci.yml

Root cause

The failure is in the Security Audit job, not the build/test job.

From the job log for commit 17c83af2315a636e5f804a9e289b6af4de7ed7cb:

• No vulnerabilities were found
• Found 1 unsound
• Resource not accessible by integration - https://docs.github.com/rest/checks/runs#create-a-check-run

This means:

1. cargo-audit itself is running.
2. It is detecting one RustSec “unsound” advisory in the dependency graph.
3. The step then fails because rustsec/audit-check@v2.0.0 tries to create a GitHub Check Run, but the workflow only grants:
   • contents: read

In .github/workflows/ci.yml, the top-level permissions are:

• line 13–15: permissions: contents: read

But creating a check run requires checks: write.

Why this is a little misleading

There are actually two issues, but only one is the immediate workflow/config failure:

1. Workflow permissions misconfiguration

The action is attempting to publish results as a check run and lacks permission. That causes the explicit GitHub Actions error:

• Resource not accessible by integration

2. Dependency audit is also reporting a real advisory

The log also says:

• Found 1 unsound

So even if you fix permissions, the audit job may still remain red until the flagged dependency is upgraded, ignored with justification, or otherwise addressed.

Evidence in repo

Workflow:

• .github/workflows/ci.yml

Relevant lines:

• verify job runs fmt/check/test
• audit job uses rustsec/audit-check@v2.0.0
• workflow permissions only include contents: read

Plan to address it

Immediate fix: correct workflow permissions

Update the workflow permissions to allow check creation. For example:

permissions:
  contents: read
  checks: write

If you want to scope it more tightly, you can leave top-level permissions minimal and set checks: write only on the audit job.

Next fix: identify the unsound dependency

The audit output shown in the log is truncated before the advisory package name, so the next step is to reproduce locally or rerun wit...

This pull request was created from Copilot chat.