Binary authenticity and code signing

Speedwave verifies release artifacts through two distinct cryptographic verification layers: OS-level code signing for fresh installations and internal cryptographic verification for automated updates. See Security architecture for broader context.

OS-level code signing

On macOS, all binary executables bundled within Speedwave.app (including embedded Lima virtualization tools, Node.js runtimes, Swift helper shims, and the Rust CLI) are signed using Speednet’s official Apple Developer ID Application certificate. Executables enable Apple’s Hardened Runtime and include secure Apple timestamps. Packaged releases are submitted to Apple Notary Service, with stapled notarization tickets enabling Gatekeeper validation offline.

On Windows, starting with version 0.19, the installers (.exe and .msi), the application, its uninstaller and the speedwave CLI are signed with Speednet’s certificate through Microsoft’s Azure Artifact Signing service. Every signature carries a trusted timestamp, so it stays valid after the short-lived signing certificate expires. The private key stays in Microsoft’s service, and the release pipeline reaches it through a federated identity bound to the release environment, which only the protected main branch can use, so no signing secret is stored in the build system. Third-party binaries that arrive already signed by their vendor, such as node.exe, keep the vendor’s signature.

This mechanism enforces three security guarantees:

1. Modifying binary packages in transit invalidates the operating system signature check (Gatekeeper on macOS, Authenticode on Windows).
2. The operating system names Speednet as the publisher only for artifacts Speednet signed.
3. On macOS, Hardened Runtime protections prevent dynamic code injection into active processes.

Cryptographic update verification

For existing installations, Speedwave’s internal updater validates downloaded release archives against an Ed25519 public key embedded directly within the application binary. The corresponding private key resides strictly within isolated CI environments and is never stored on developer workstations. Even if release distribution mirrors were compromised, the updater rejects any package lacking a valid signature from the authorized CI key.

Defense-in-depth signing model

First-time installations are protected by OS-level code signing. Automated updates pass through both layers: internal Ed25519 signature verification during download, followed by the operating system’s signature check when the new version starts. This dual-layer architecture ensures release integrity across the entire software distribution lifecycle.

For update reconciliation details, consult Updates and recovery architecture.