Repository navigation
Deployment Notes
The signed Windows workflow builds an x64 qkd-stub.exe and the
dashboard qkd-stub-gui.exe after the Windows test suite passes.
Both are signed and checksummed. Manual runs on main save the executables and SHA-256 checksums as
Actions artifacts for 30 days. Tags matching the Cargo package version create
draft GitHub Releases; maintainers review and publish them for permanent download.
Signature, timestamp and institute publisher checks must pass for both executables before upload.
Azure OIDC access and the GitHub release environment must be configured first.
See Windows signing and releases
for setup and Windows quickstart
for running the downloaded executable. Its built-in configure, CSR/certificate,
PSK/SAE, and demo commands require no external setup tools. Credentials are
generated locally, never packaged. The C runtime is statically linked.
Tagged releases also include qkd-stub-x86_64-linux.tar.gz, a static musl build
that runs on any x86-64 Linux distribution. It contains the command-line tool only;
the dashboard is built with --features gui and released for Windows. It has no Authenticode-style signature;
verify it with the SHA-256 file and gh attestation verify (build provenance).
See Linux releases.
Start with qkd-stub configure, or qkd-stub demo init for a complete local
two-endpoint test. Use qkd-stub check and qkd-stub serve after provisioning.
The default configuration is qkd-stub-data/config.toml; --config FILE selects
another. File paths inside it are relative to that configuration. See
Standalone provisioning for the CSR/CA workflow,
PSK import, trust management, SAE commands, and executable-only verification.
Securely copy the same PSK to both machines. Configure identical SAE numeric code assignments. Each server can use its own TLS certificate and local client CA; neither TLS private keys nor CA private keys need to be shared. Each application trusts its local server CA and presents its own mapped client certificate.
Both servers can listen on 127.0.0.1:8443 on their respective machines. For
applications elsewhere in the LAN, bind the server to an appropriate interface
and include its actual DNS name/IP when generating the server certificate.
The server always requires a PSK, mTLS, and SAE authorization; there is no
unrestricted mode, --no-psk option or public derivation mode. The former
flag-only invocation (--listen, --tls-cert, --no-sae-binding, ...) has been
removed. A PSK alone does not restrict API access: SAE authorization is what
limits who can retrieve keys.
Configuration is read at startup. serve runs the same checks as check:
missing/unreadable files, invalid certificates, an unmapped local SAE or a PSK of
the wrong length fail startup. There is no generated default PSK or silent
fallback.