Sign with Azure Trusted Signing without signtool.exe (draft) - #1019

Draft, in response to your question on the docs PR about a native option for signing Windows PE/MSI on nix. Easier to judge the integration shape from working code than from a description, so here it is - happy to throw it away or rework it however you'd prefer.

What it does

--azureTrustedSignFile currently goes through signtool.exe plus the Trusted Signing Dlib, both native Windows binaries. So the option is registered only on Windows, and a cross-compiled Windows package can't use it.

But Trusted Signing is just an HTTPS service - a digest goes out, a signature comes back. Swapping the Dlib for the managed client makes the same metadata.json work on Linux and macOS, with the key still never present locally.

Windows is untouched: it keeps using the Dlib. Only the non-Windows path is new, so this adds a capability rather than changing one.

Verified end to end

Against a live Trusted Signing account on Ubuntu 24.04:

[INF] Code signing with Azure Trusted Signing (account '…', profile '…').
[INF] Code-signed 6/6 files
[INF] Setup bundle created 'MyApp-win-Setup.exe'.
[INF] Code-signed 1/1 files

And the output, checked independently:

releases/MyApp-win-Setup.exe
  format:    PE image
  signer:    CN=Zomp Inc., O=Zomp Inc., L=Toronto, S=Ontario, C=CA
  chain:     4 certificate(s) embedded
  signature: valid
  covers this file: yes
  timestamp: 2026-07-28 15:27:16Z

A real certificate, full chain, timestamped. MyApp.exe inside the portable zip verifies the same way.

What it costs you

Velopack.Packaging.Windows gains two package references: SignUniversal (PE/MSI Authenticode; pulls System.Security.Cryptography.Pkcs and OpenMcdf) and SignUniversal.Azure (pulls the Azure SDK). The Azure SDK is the real weight here, and it's your call whether that belongs in vpk. If it doesn't, the same seam works with a certificate held any other way - IRemoteSigner is a single SignHash method - so a PFX-only path would cost only the first package.

Those are mine, which is how I know they fit. They were Apache-2.0 when I opened this; they are MIT as of 1.0.34, so referencing them carries no LICENSE/NOTICE obligation for vpk.

Things I'd want your opinion on

• Timestamping. The Windows path uses http://timestamp.acs.microsoft.com. I defaulted the native path to DigiCert instead, because the Microsoft one returns a chain that doesn't resolve against a stock Linux trust store. Worth making configurable.
• Windows could use this too, which would drop the Dlib entirely and make behaviour identical everywhere. I deliberately didn't, to keep the change additive.
• No tests yet - signing needs live credentials, so I wanted your read on the approach before deciding how to fake that seam.
• Page hashes aren't implemented, so signatures don't carry them.