3826316eec
Production SignPath signing requests require manual approval in the SignPath UI, so the previous single-job flow (submit with wait-for-completion inside a 40-minute window) let approval latency fail the Windows build, and any re-run rebuilt the binaries and submitted a second request needing a second approval. The Windows lane is now two jobs: sign-windows-agent builds the unsigned executables, submits the SignPath request without waiting, and uploads a 7-day signing-request record; collect-windows-signing absorbs approval latency by polling the recorded request, downloads the signed artifact by request id, and keeps the existing verification and evidence steps. If approval outlasts the 115-minute polling window, the collection job fails with re-run guidance and "Re-run failed jobs" collects the same recorded request - no rebuild, no resubmission. The legacy PFX break-glass backend rides the same two-job shape via an artifact hand-off. Workflow output wiring, artifact names, and evidence content are unchanged for downstream consumers. The shape test now pins the async invariants (no wait-for-completion: true in the candidate workflow), and the code signing policy plus the deployment-installability contract describe the two-phase flow.
4.8 KiB
Code Signing Policy
Pulse publishes release artifacts from the public
rcourtman/Pulse repository. This policy
applies only to the open-source community artifacts built from that repository.
Private Pulse Pro, Relay, Enterprise, and service infrastructure are outside the
scope of the SignPath Foundation application and must not be submitted to the
community signing project.
Signing service
Pulse was accepted into the SignPath Foundation open-source programme on 2026-08-06.
Free code signing provided by SignPath.io, certificate by SignPath Foundation.
The SignPath organization Pulse [OSS] and project Pulse are
connected only to the public repository through SignPath's GitHub App and
trusted build system. The production release certificate is still awaiting
issuance (CSR PENDING), so the release-signing policy is not yet available
for production releases.
Until the production certificate is active and the exact-commit,
non-publishing proof run has passed, release notes must say when a Windows
artifact is not Authenticode-signed. Detached checksums and Pulse release
signatures remain mandatory and are not a substitute for Authenticode. The
test-signing policy may be used to validate the integration, but its test
certificate is untrusted and its output must never be published as a
production release. The manual
SignPath Test Signing Proof
workflow is the only test-signing entrypoint: it is restricted to main,
hard-codes the test policy, verifies the exact returned file set, and uploads
only a non-production JSON evidence record after verification. It never uploads
the test-signed binaries as a GitHub artifact or assembles a release candidate.
The canonical CI integration uses SignPath's GitHub trusted-build-system action, split into two phases because production signing requests require manual approval in the SignPath UI. The Windows build job uploads the three unsigned agent executables as one immutable workflow artifact, submits it to SignPath without waiting, and records the signing request id. A separate collection job absorbs the approval latency: it waits for the recorded request to complete, downloads the signed result by request id, and verifies every file before candidate assembly. If approval outlasts the collection job's polling window, that job fails with re-run guidance, and re-running it collects the same recorded request — no rebuild, no second submission, no second approval. A non-secret evidence artifact records the SignPath request URL, source SHA, signer identity, and signed-file SHA-256 values.
The artifact configuration accepts exactly these ZIP-root files and no others:
pulse-agent-windows-amd64.exepulse-agent-windows-arm64.exepulse-agent-windows-386.exe
The repository-secret PFX path is an explicitly selected break-glass fallback.
Normal stable publication and stable dry runs select signpath directly.
Build and release controls
- Release artifacts are built by GitHub Actions from an exact commit on the
mainbranch. - The release workflow records artifact digests and promotes the same immutable candidate without rebuilding it.
- Only binaries built from the public repository's source and build scripts may be submitted to the SignPath Foundation project.
- Third-party or private binaries must never be signed with the community project certificate.
- Every production signing request requires approval by an authorised project approver.
- Test-signed output must never enter a release candidate or publication path.
- Production signing must fail closed while the release certificate or signing policy is invalid.
- Release checksums and detached signatures are published alongside artifacts and verified independently after publication.
Project roles
- Committers and reviewers: repository collaborators listed by GitHub for
rcourtman/Pulse. - Approvers: the repository owner,
rcourtman, and any future maintainer granted the SignPath Approver role by the repository owner.
All project members with repository or signing access must use multi-factor authentication. Signing access must be removed promptly when a maintainer no longer needs it.
User privacy and system changes
Pulse's data handling and opt-out controls are documented in the Privacy Policy. Installer behavior, service creation, privileges, and uninstallation are documented in the Installation Guide and Agent Security.
Security concerns involving a signed artifact should be reported using the private process in the repository's Security Policy.