Switch NuGet publishing to trusted publishing

[thomhurst]

Summary

• request GitHub OIDC tokens for NuGet trusted publishing
• use NuGet/login@v1 with ${{ secrets.NUGET_USER }} to exchange for a short-lived NuGet API key
• pass steps.login.outputs.NUGET_API_KEY into the existing publish step or pipeline input

Validation

• parsed the modified workflow YAML files locally
• ran git diff --check

Follow-up

A matching trusted publishing policy must be configured on nuget.org for this repository and workflow file before the next publish run.

[coderabbitai]

Warning

Review limit reached

@thomhurst, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 24 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: b9db5ee0-1860-431e-8709-2fb6c2a1c3e3

📥 Commits

Reviewing files that changed from the base of the PR and between fca5ee9 and 30b2df6.

📒 Files selected for processing (1)

• .github/workflows/dotnet.yml

---

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Greptile Summary

The PR replaces the long-lived NuGet API-key secret with an OIDC trusted-publishing login and forwards the resulting short-lived key into the existing pipeline.

• Grants the workflow matrix repository-write and OIDC-token permissions.
• Runs NuGet/login on main-branch Ubuntu publishing executions.
• Passes the login output to the existing package-publishing pipeline.

Confidence Score: 4/5

The PR appears safe to merge functionally, with non-blocking security hardening needed around permission scope and immutable action pinning.

The login and publishing conditions align and the pipeline safely handles an absent API key, but unrelated matrix executions inherit publishing privileges and the new login action can change without a repository-reviewed commit update.

Files Needing Attention: .github/workflows/dotnet.yml

Security Review

The trusted-publishing flow is wired consistently, but elevated permissions currently apply to the entire matrix and the new privileged login action uses a mutable tag. Scope publishing permissions to a dedicated job and pin the login action to an immutable commit.

Important Files Changed

Filename	Overview
.github/workflows/dotnet.yml	Correctly wires trusted NuGet publishing into the existing pipeline, but broadens permissions across the full matrix and references the privileged login action through a mutable tag.

Sequence Diagram

sequenceDiagram
  actor Maintainer
  participant GHA as GitHub Actions
  participant NuGetLogin as NuGet/login
  participant NuGet as nuget.org
  participant Pipeline as TUnit.Pipeline
  Maintainer->>GHA: "Dispatch main workflow with publish-packages=true"
  GHA->>NuGetLogin: Run Ubuntu login with OIDC permission
  NuGetLogin->>GHA: Request GitHub OIDC token
  NuGetLogin->>NuGet: Exchange identity for temporary API key
  NuGet-->>NuGetLogin: NUGET_API_KEY
  NuGetLogin-->>GHA: Expose action output
  GHA->>Pipeline: Pass NuGet__ApiKey and ShouldPublish
  Pipeline->>NuGet: Publish generated packages

Loading

_{Reviews (1): Last reviewed commit: "Switch NuGet publishing to trusted publi..." | Re-trigger Greptile}

[greptile-apps]

Publishing permissions span full matrix

The job-level contents: write and id-token: write permissions apply to pull-request, non-publishing, Windows, and macOS executions even though OIDC login and release operations are restricted to the main/Ubuntu publishing path. Scoping these capabilities to a dedicated publishing job would reduce the impact of compromised actions or unintended pipeline behavior.

How this was verified: The permissions are assigned to the matrix job, while the OIDC-dependent login is gated to main, publishing enabled, and Ubuntu.

Knowledge Base Used: Build and CI

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Publishing action uses mutable tag

NuGet/login@v1 can resolve to different executable code without a repository-reviewed change, while this step receives the NuGet identity and can request an OIDC token. Pinning the action to a reviewed commit would make changes to this security-sensitive publishing dependency explicit.

How this was verified: The publishing step references the mutable v1 tag and runs with NUGET_USER plus job-level OIDC permission.

Knowledge Base Used: Build and CI

[claude]

Code review

Reviewed the switch to NuGet trusted publishing (OIDC via NuGet/login@v1). Note: this PR is already merged, so these are retrospective/follow-up notes rather than blockers.

Verified as sound:

• The NuGet login step's if condition (ref == main && publish-packages == 'true' && ubuntu-latest) doesn't match the broader publish-packages flag passed to Run Pipeline (which omits the ref == main check). I initially flagged this as a mismatch that could leave nuget-apikey empty on a non-main dispatch, but UploadToNuGetModule (tools/TUnit.Pipeline/Modules/UploadToNuGetModule.cs) already guards with [RunOnlyOnBranch("main")] and skips cleanly via WithSkipWhen when the API key is empty — so this is a non-issue, no dead-key publish attempt occurs.

Worth a follow-up (non-blocking):

1. Elevated permissions apply to the whole OS matrix, not just the leg that needs them. contents: write / id-token: write are declared at the job level (.github/workflows/dotnet.yml line ~29), but the matrix runs on ubuntu-latest, windows-latest, and macos-latest. The modules that actually use these permissions (UploadToNuGetModule, CreateReleaseModule, PushVersionTagModule) are all [RunOnLinuxOnly]. Since GitHub Actions permissions can't be scoped per matrix-leg, the Windows/macOS jobs now carry a write-scoped + OIDC-minting token they never use, unnecessarily widening the blast radius if a dependency in those legs is ever compromised. Splitting publish/release into a dedicated job that runs after the test matrix (ubuntu-only) would let the test matrix stay on minimal default permissions while only the publish job gets the elevated scope.
2. NuGet/login@v1 is pinned to a mutable tag. This action mints a live, trusted NuGet-publish credential, so it's a high-value supply-chain target — if the v1 tag is ever repointed, this workflow would silently run whatever it points to with that trust. Standard hardening practice (and likely what a scorecard/pinned-dependencies check would flag) is to pin third-party actions used in privileged contexts to a full commit SHA.

Both were also flagged by greptile-apps' automated review; I independently verified them against the pipeline source rather than taking that at face value.