Daily VS Code extension installs bypass signature verification

[adamint]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

The daily VS Code extension build is signed, but the supported daily install path bypasses VS Code's signature verification.

get-aspire-cli.sh and get-aspire-cli.ps1 download aspire-vscode.vsix.zip, extract the VSIX, and run:

code --install-extension <path-to-vsix> --force

VS Code treats that as a local VSIX install. Signature verification only runs for Marketplace gallery installs, where VS Code separately downloads the VsixSignature archive.

I confirmed this against the live daily build on August 18, 2026:

• https://aka.ms/dotnet/9/aspire/daily/aspire-vscode.vsix.zip resolved to Aspire build 13.6.0-preview.1.26417.11, extension 1.17.0.
• The daily archive contained only aspire-vscode-1.17.0.vsix.
• The matching public .manifest and .signature.p7s exist, and vsce verify-signature succeeds.
• Installing that exact daily VSIX with VS Code Insiders 1.134.0-insider succeeded with metadata source "vsix", but the trace contained no signature download or verification.
• Installing microsoft-aspire.aspire-vscode@1.17.0 from Marketplace in the same isolated VS Code build downloaded Microsoft.VisualStudio.Services.VsixSignature and logged:

Extension signature verification result for microsoft-aspire.aspire-vscode: Success.

So the signing pipeline is working. The daily distribution path is not using it.

Expected Behavior

The supported daily installation flow should install a uniquely versioned Marketplace pre-release so VS Code performs its native package, publisher, timestamp, and repository signature verification before installation.

Steps To Reproduce

1. Download the live daily extension:

   curl -fsSL https://aka.ms/dotnet/9/aspire/daily/aspire-vscode.vsix.zip -o aspire-vscode.vsix.zip
   unzip aspire-vscode.vsix.zip

2. Install the extracted VSIX with VS Code trace logging:

   code-insiders --verbose --install-extension aspire-vscode-*.vsix --force

3. Observe that the extension installs from a local file and no signature verification runs.

4. Compare with the Marketplace path:

   code-insiders --verbose --install-extension microsoft-aspire.aspire-vscode --force

5. Observe the VsixSignature download and successful signature verification.

Aspire doctor output

Not applicable; this is extension acquisition and publishing infrastructure.

Anything else?

A packaging-only fix is not sufficient. Adding the detached .manifest and .signature.p7s beside the downloaded VSIX does not make code --install-extension <file> consume them.

The likely fix is to publish daily builds as uniquely versioned Marketplace pre-releases and have the daily installer install microsoft-aspire.aspire-vscode with --pre-release. The existing signed source-build artifact and secure Marketplace publishing job can be reused.

[adamint]

This path is still present on current main (93b14b405). Both acquisition scripts download aspire-vscode.vsix.zip, extract a local .vsix, and invoke code --install-extension <local path> --force; they do not use a Marketplace identifier/pre-release install path.

After ./restore.sh and building the test project, the focused dry-run test passes, but only verifies installation ordering:

dotnet test --project tests/Aspire.Acquisition.Tests/Aspire.Acquisition.Tests.csproj --no-build --no-restore --no-launch-profile -- --filter-method "*.DryRunWithExtension_PlansExtensionBeforeBundleSetup" --filter-not-trait "quarantined=true" --filter-not-trait "outerloop=true"

I couldn't compare live VS Code signature behavior because the code CLI isn't available in this environment, but the reported acquisition path itself still reproduces.