Code signing policy

Policy and attribution

The ResumeForge Windows installer is signed through SignPath Foundation's free code signing program for open source projects. The certificate is issued to SignPath Foundation rather than to the maintainer's GitHub account; this is how the program is structured. Whether a given release is signed is stated under Current status.

Free code signing provided by SignPath.io, certificate by SignPath Foundation.

This page is the signing policy SignPath requires projects to publish. The process described below maps directly to the workflow in the repository and can be checked against the public code.

Which files are signed

One artifact is in scope: the Windows installer ResumeForge-Setup-<version>.exe (an NSIS installer). It carries an Authenticode signature with a SHA-256 digest; the RFC 3161 timestamp is applied by the signing policy on SignPath's side. The workflow passes no signing parameters, so the digest algorithm and the timestamp are determined by SignPath's artifact configuration / signing policy and are verified in the SignPath console rather than in this repository. The timestamp allows a published installer to verify as signed while the certificate was valid, even after the certificate expires or is revoked.

The remaining artifacts are not covered by this signing:

Every installer and dmg ships with a matching .sha256 file, corresponding to the attachment on the release page; the hash is computed over the exact published file.

Which build a signature comes from

Signing requests come from a single source: .github/workflows/release-assets.yml in the public repository magicapple123/ResumeForge. The process has three steps:

• a GitHub-hosted windows-latest runner checks out the source at the requested tag (or a rehearsal ref), builds the frontend and the desktop shell, and packages the NSIS installer;
• that installer is uploaded as an artifact of this workflow run;
• SignPath's GitHub Action submits a signing request for that artifact and signs it only after verifying that the artifact originates from this run (origin verification); the signed file is returned to the same run.

Build and signing both run in CI: no developer machine is involved, and there is no channel for uploading an installer by hand to be signed. To confirm that a release followed this process, open the workflow run behind it; the run page records the signing request link and request ID.

Team roles and the approval step

The project is maintained by a single maintainer (Cenguo Huang, GitHub @magicapple123). All three roles below are currently held by that maintainer; they are defined by responsibility and remain distinct.

The maintainer has multi-factor authentication enabled on both the GitHub and SignPath accounts. The signing API token is stored only in GitHub repository Secrets and injected at run time; it does not appear in logs or artifacts.

Privacy

Signing takes place entirely on the build side and does not involve end-user data. It does not change any commitment on the Privacy and data ownership page: resumes, jobs, profile, reminders and assistant conversations remain in the local data directory; the app has no account system and no analytics or telemetry; AI features connect to the network only when invoked.

The two systems involved receive only what they need: SignPath receives the binary to be signed and the workflow metadata for that build (repository, commit, run identifier) to verify provenance. It does not receive user data, which is neither part of the build artifact nor part of the upload. Signing adds nothing to the user's machine: the installer stays local and Windows performs signature verification.

Verifying the signature

Once signing is in effect, Windows shows the publisher as SignPath Foundation rather than magicapple123. The certificate is held by the foundation and issued to open source projects that pass its review, so a publisher name that differs from the project author is expected. The signature establishes that the file was built by this project's CI and signed by the foundation.

To verify it yourself, run the following in PowerShell (substitute the file you downloaded):

A Status of NotSigned means the file carries no signature; the usual reason is that the release predates signing. You can still verify integrity with SHA-256, but the file should not be treated as publisher-verified.

Current status

As of 2026-11-06, test-signing has passed end-to-end verification: CI completed the full path — build, artifact upload, signing request, SignPath origin verification, signing, and generating .sha256 from the signed file — and the signing request finished with status Completed. This is an actual execution record of the process described above.

Two records are available: the rehearsal workflow run (all jobs passed) and the corresponding signing request ec1837db-7b38-4053-8f70-ea8b34824e8e (under Signing Requests in the SignPath console). This signature uses the test-signing test certificate, subject CN=Test certificate for 'ResumeForge [OSS]'; its root is not in the Windows trust store, so verification returns UnknownError rather than Valid. This is expected at this stage: the test certificate verifies that the process works; its output is not intended for end users and is never published to a release.

The production certificate is still pending from SignPath Foundation, so installers currently available from Releases are unsigned. Until then, verify downloads with the .sha256 file and follow the standard Windows prompts when installing. This page and CHANGELOG.md will be updated when the status changes.