gsadmin/pulse
1
0
Fork 0
mirror of https://github.com/rcourtman/Pulse.git synced 2026-09-11 14:00:29 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(signing): record test-signing proof

Browse Source
This commit is contained in:
rcourtman
2026-08-06 16:15:28 +01:00
parent a6c7bbb913
commit bbd6910f49
4 changed files with 82 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/CODE_SIGNING_POLICY.md
+8 -2
View File
@@ -22,7 +22,12 @@ 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.
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. GitHub Actions uploads the three unsigned Windows agent executables as
@@ -50,7 +55,8 @@ Normal stable publication and stable dry runs select `signpath` directly.
be submitted to the SignPath Foundation project.
- Third-party or private binaries must never be signed with the community
project certificate.
- Every signing request requires approval by an authorised project approver.
- 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.
docs/release-control/v6/internal/records/signpath-windows-authenticode-integration-packet-2026-07-21.md
+36 -2
View File
@@ -29,8 +29,7 @@ Production signing is not ready. `Release certificate 2026` remains
Foundation's certificate authority issues and installs the certificate. The
remaining proof sequence is:
1. Submit a non-publishing request through `test-signing` to validate the CI
credentials, origin, artifact configuration, approval, and download path.
1. The isolated, non-publishing `test-signing` integration proof is complete.
2. Wait for the production release certificate to become active.
3. Run the exact-SHA, non-publishing `release-signing` proof described below.
@@ -38,6 +37,41 @@ Test-signed files use an untrusted certificate. Do not publish them, include
them in a production candidate, or mark production Windows signing ready on the
basis of a test request.
## Test-Signing Integration Proof (2026-08-06)
The canonical non-production integration proof is GitHub Actions run
[`31114440080`](https://github.com/rcourtman/Pulse/actions/runs/31114440080),
executed from `main` at
`0dd9c92cb84548c4f602f9e647150d2ce6de4f14` for version `6.2.0-rc.8`.
The manually dispatched workflow hard-coded `test-signing`, submitted only the
three contract executables through artifact configuration `initial`, verified
the exact returned file set and Authenticode signatures, and retained no signed
output. Repository policy retains the JSON proof artifact for seven days and
the unsigned input artifact for one day. The test-signed executables were
neither uploaded as a GitHub artifact nor published or assembled into a release
candidate. This record preserves the accepted evidence fields after the
ephemeral artifacts expire.
SignPath request
[`88badc79-817f-4a8d-80e9-5ccdbe6d69a1`](https://app.signpath.io/Web/1ecb3261-e389-49c2-a071-e03ff177cc5d/SigningRequests/88badc79-817f-4a8d-80e9-5ccdbe6d69a1)
used the self-signed test certificate
`CN=Test certificate for 'Pulse [OSS]'`, thumbprint
`D24B66B8F6C5F59362DE85C0965F1E4303ADE344`. The accepted signed-file hashes
are:
- `pulse-agent-windows-386.exe`:
`b69ab0ed070e64e459edfe9150f2ad1b9a23bdb22b601bbf7ce480d2ed1dd6eb`
- `pulse-agent-windows-amd64.exe`:
`75d08c411ccd3a98fa406674836e67e824a12a0dac7437fe1fa7ad552791ed6c`
- `pulse-agent-windows-arm64.exe`:
`03ac32e86bc5456ccc23cfd85f3c7df2c23eafe84c74ac77f1e2fb0caa230d8d`
The four diagnostic runs `31110733308`, `31111803643`, `31112661094`, and
`31113777871` were cancelled or failed without publication while isolating the
Windows user-certificate-store hangs. The replacement uses bounded,
non-interactive `certutil` operations against the documented ephemeral machine
stores and bounds every SignTool verification to 90 seconds.
## SignPath Project Contract
The approved project must continue to satisfy this contract:
frontend-modern/public/docs/CODE_SIGNING_POLICY.md
+30 -9
View File
@@ -9,14 +9,25 @@ community signing project.
## Signing service
Pulse is applying to the SignPath Foundation open-source programme. Once the
application is approved, Windows community release artifacts will use free code
signing provided by [SignPath.io](https://signpath.io/), with the certificate
issued by the [SignPath Foundation](https://signpath.org/).
Pulse was accepted into the SignPath Foundation open-source programme on
2026-08-06. 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 approval and production integration are complete, 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.
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`](https://github.com/rcourtman/Pulse/blob/main/.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. GitHub Actions uploads the three unsigned Windows agent executables as
@@ -25,20 +36,30 @@ completion, downloads the signed result, and verifies every file before
candidate assembly. 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
protected `main` branch.
`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 signing request requires approval by an authorised project approver.
- 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.
frontend-modern/public/docs/INSTALL.md
+8 -7
View File
@@ -13,13 +13,14 @@ Pulse offers flexible installation options from Docker to enterprise-ready Kuber
## Windows code-signing status
Pulse is applying to the SignPath Foundation open-source programme. Once
approved, Windows community release artifacts will use free code signing
provided by [SignPath.io](https://signpath.io/), with the certificate issued by
the [SignPath Foundation](https://signpath.org/). Until that integration is
complete, release notes identify Windows artifacts that are not
Authenticode-signed; published checksums and detached Pulse signatures remain
mandatory.
Pulse was accepted into the SignPath Foundation open-source programme on
2026-08-06, and the public repository is connected to its SignPath project. The
production release certificate is still awaiting issuance (`CSR PENDING`), so
Windows community release artifacts remain unsigned until the certificate is
active and the non-publishing production proof run has passed. Release notes
identify Windows artifacts that are not Authenticode-signed; published
checksums and detached Pulse signatures remain mandatory. Test-signed artifacts
use an untrusted certificate and are never published as production releases.
See the [Code Signing Policy](CODE_SIGNING_POLICY.md) for build provenance,
approval roles, signing scope, and reporting requirements. Release downloads