mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-10-14 05:30:55 +00:00
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.
97 lines
4.8 KiB
Markdown
97 lines
4.8 KiB
Markdown
# Code Signing Policy
|
|
|
|
Pulse publishes release artifacts from the public
|
|
[`rcourtman/Pulse`](https://github.com/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](https://signpath.io/), certificate
|
|
> by [SignPath Foundation](https://signpath.org/).
|
|
|
|
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`](../.github/workflows/signpath-test-signing.yml)
|
|
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.exe`
|
|
- `pulse-agent-windows-arm64.exe`
|
|
- `pulse-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
|
|
`main` branch.
|
|
- 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`](https://github.com/rcourtman/Pulse).
|
|
- **Approvers:** the repository owner,
|
|
[`rcourtman`](https://github.com/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](PRIVACY.md). Installer behavior, service creation, privileges,
|
|
and uninstallation are documented in the [Installation Guide](INSTALL.md) and
|
|
[Agent Security](AGENT_SECURITY.md).
|
|
|
|
Security concerns involving a signed artifact should be reported using the
|
|
private process in the repository's [Security Policy](../SECURITY.md).
|