Commit Graph
2 Commits
Author SHA1 Message Date
shadowdaoandClaude Opus 5.5 cc274f39a8 fix(ci): pass the sign command with --config and prove the uninstaller was signed
Secret Scan / scan (push) Successful in 8s
Build App (Preview) / compute-version (pull_request) Successful in 12s
Secret Scan / scan (pull_request) Successful in 5s
Build App (Preview) / create-release (pull_request) Successful in 1s
Build App (Preview) / build-macos (pull_request) Successful in 2m48s
Build App (Preview) / test (pull_request) Successful in 3m41s
Build App (Preview) / build-linux (pull_request) Successful in 7m8s
Build App (Preview) / build-windows (pull_request) Failing after 8m53s
Build App (Preview) / prune-previews (pull_request) Skipped
The first signing run built nothing signed, and "Verify signatures" failed
it as intended. The Tauri 2 CLI never reads TAURI_CONFIG. It only sets that
variable for tauri-build, so the sign command was dropped silently, just as
the inline beforeBuildCommand override had been for as long as the Windows
jobs have set it. The setup now writes a config file, and the build passes
it with `cargo tauri build --config`.

Review follow-ups:
- The NSIS uninstaller is written to %TEMP% and signed from 32-bit makensis.
  SYSTEM's %TEMP% sits under System32, which WOW64 redirects for makensis but
  not for the x64 signtool, so they would disagree about where the file is.
  %TEMP% and %TMP% now point into the workspace. makensis ignores the sign
  command's exit code for the uninstaller, so windows-sign.ps1 logs every
  file it signs, and the verify step requires a logged signature under that
  temp directory.
- The signing client is pinned by SHA-512, so the pin can be checked against
  nuget.org's published packageHash.
- tauri-cli on Windows is pinned to =2.11.0 --locked, the @tauri-apps/cli
  version the Linux and macOS jobs run from the lockfile, instead of "^2".

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-23 18:05:03 -07:00
shadowdaoandClaude Opus 5.5 44e9bd2916 ci: sign Windows builds with Azure Artifact Signing
Build App (Preview) / compute-version (pull_request) Successful in 5s
Secret Scan / scan (pull_request) Successful in 4s
Secret Scan / scan (push) Successful in 6s
Build App (Preview) / create-release (pull_request) Successful in 2s
Build App (Preview) / build-macos (pull_request) Successful in 3m19s
Build App (Preview) / test (pull_request) Successful in 4m59s
Build App (Preview) / build-linux (pull_request) Successful in 5m18s
Build App (Preview) / build-windows (pull_request) Failing after 5m32s
Build App (Preview) / prune-previews (pull_request) Skipped
Releases and PR previews now sign the app binary, the MSI, the NSIS
installer and its uninstaller. "Verify signatures" fails the job on any
unsigned or untimestamped .exe/.msi, so an unsigned installer can't ship
quietly.

- windows-signing-setup.ps1 fetches Microsoft.ArtifactSigning.Client 1.0.128
  and a job-local .NET 10.0.12 runtime, each pinned by hash. Nothing is
  installed on the build VM. It also writes the dlib metadata and exports
  TAURI_CONFIG with bundle.windows.signCommand.
- windows-sign.ps1 runs the installed signtool with /dlib, SHA-256 and the
  Microsoft timestamp server, with retries. Credentials come only from the
  AZURE_* environment. The metadata excludes every credential type except
  EnvironmentCredential, because InteractiveBrowserCredential would hang a
  job running as SYSTEM.
- The signing files go in the workspace, not %TEMP%, because the uninstaller
  is signed from 32-bit makensis and WOW64 redirects SYSTEM's %TEMP%.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-23 17:57:32 -07:00