Fix Aspire CLI npm signing scope

[Adam Ratzman (adamint)]

Description

Fixes the internal signed build failure introduced by the Aspire CLI npm package release integration. The failed build staged microsoft-aspire-cli-win-*.tgz into the AspireCliNpmPackage signing scope, but the nested aspire.exe only had an unscoped signing rule. Arcade resolves nested file certificates within the ItemsToSign collision scope, so it failed with Could not determine certificate name for signable file(s): File: aspire.exe.

This keeps the npm tarball signing behavior scoped to Aspire CLI npm packages: .tgz still gets the detached LinuxSign500180PGP signature, aspire.js still uses MicrosoftDotNet500, and the already-signed native aspire.exe/aspire payloads are explicitly CertificateName="None" inside that same scope.

Internal validation build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2988598

Relevant tasks from build 2988598 completed successfully:

• 🟣Build on Windows, the task that failed on main
• 🟣Validate npm package signatures
• 🟣Sign VS Code extension
• 🟣Verify VS Code extension signature
• All 🟣Verify CLI npm package (...) tasks for Windows, Linux, and macOS RIDs

Fixes # (issue)

Security considerations

This change touches signing metadata only. The native executable payloads in the npm RID packages are copied from the already-signed native CLI archives; the main Windows build should produce detached signatures for the npm tarballs rather than re-sign those nested native payloads. The tarballs remain covered by detached PGP signatures.

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 17770

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 17770"

[Copilot]

Pull request overview

This PR fixes Aspire CLI npm package signing metadata so scoped signing rules cover nested native payloads while preserving detached signatures for npm tarballs.

Changes:

• Adds scoped CertificateName="None" signing rules for nested aspire.exe and aspire payloads in CLI npm tarballs.
• Adds an infrastructure test that verifies all Aspire CLI npm signing scope rules are present exactly once.

Show a summary per file

File	Description
eng/Signing.props	Adds scoped signing exclusions for nested native CLI executables in npm package tarballs.
tests/Infrastructure.Tests/Pipelines/NpmCliPackageTests.cs	Adds XML-based assertions for Aspire CLI npm signing scope rules.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 0

[Adam Ratzman (adamint)]

Double checked this against the actual failed signing path.

The original failure in build 2988560 was Arcade resolving nested aspire.exe inside microsoft-aspire-cli-win-*.tgz under the AspireCliNpmPackage collision scope and finding no scoped cert rule. Build 2988598 ran this fix on fix-npm-cli-signing; the Windows 🟣Build task that failed on main completed successfully, and so did 🟣Validate npm package signatures, all 🟣Verify CLI npm package (...) tasks, and VS Code signing/verification.

Local Infrastructure.Tests also passed: 263 passed / 0 failed.