mirror of
https://github.com/Such-Software/hash-wallet.git
synced 2026-10-17 05:41:29 +02:00
jwinterm
8e45de5928
The Windows lane already runs on the machine that physically holds the Sectigo EV code-signing token, but the runner there is NT SERVICE\act_runner, which cannot use it: SafeNet holds the token login per user and an operator establishes that login interactively. So the build queues the launcher for the signing broker that Fleet installs (such-fleet roles/windows_code_signing) and waits for it to come back signed. CI never holds the private key -- it is non-exportable on FIPS 140-2 Level 2 hardware -- and never holds the token password. Sectigo allows three consecutive failed password attempts before the token needs vendor unlocking, and a job that never supplies a password cannot spend one. Only HashWallet.exe is signed. The bundled MSVC runtime DLLs are already Microsoft-signed and must not be re-signed, and the plugin DLLs are loaded by an already-trusted process; it is the launcher the user double-clicks that SmartScreen judges. The signature, its RFC 3161 timestamp and the expected signer are verified on the exe that actually goes into the zip, and any of the three failing fails the build. If the broker's circuit breaker is tripped the job says so and stops rather than shipping an unsigned binary. Procedure: docs platform/windows-hardware-token-signing.md.