小莫andfanlusky
ad78409e3c
* ci(release): run the SignPath path on GitHub-hosted runners SignPath's open-source plan accepts a signing request only when every job leading up to it ran on a GitHub-hosted runner, and tsf, server and package all ran on the self-hosted release machine. With WINDOWS_SIGNING_PROVIDER=signpath they now run on windows-2025, restoring vcpkg binaries and (for the Server) sccache the way ci.yml does; the certificate path keeps the self-hosted runner unchanged. The org secret holding the SignPath API token is SIGNPATH_TOKEN, so the workflow and detect-release-signing.ps1 read that name instead of SIGNPATH_API_TOKEN. AGENTS.md lists what SignPath needs configured, and the code signing policy records the accepted application and the hosted-runner rule. * fix(ci): let the SignPath action read the run's artifacts * fix(installer): drop authenticode-sign attributes SignPath Foundation rejects * fix(ci): fail the hosted SignPath release before signatures are spent - Probe ISCC with WizardStyle=modern dynamic and run that probe at the start of the hosted package job, so an image ISCC older than 6.6 fails before the payload signing request instead of after it. - Verify the TSF vcpkg root before installing into it or saving its archives under the -complete key. - Check the Server job's C:\vcpkg override against the vcpkg the hosted image puts on PATH. - Code signing policy: drop the stale "once approved" wording and state that the hosted-runner rule applies to SignPath-signed releases. * docs: list only the configured SignPath approver --------- Co-authored-by: fanlusky <1730976608@qq.com>
5.3 KiB
Code signing policy
Free code signing provided by SignPath.io, certificate by SignPath Foundation.
Current status. The SignPath Foundation open source program has accepted this project (SignPath project msime-windows), and no release has been signed through SignPath yet. Releases up to and including v0.9.3 were built on a maintainer's machine and signed there with the project's Certum Open Source Developer certificate (CN=Open Source Developer LU FAN) through SimplySign, using installer/package-simplysign.ps1. From now on, releases signed with the SignPath Foundation certificate will be built and signed only by the CI process described below, never on a local machine.
What gets signed
Only the project's own binaries, built from source in this repository:
- the Server (
MetasequoiaImeServer.exe) and the helper executables shipped with it; - the TSF text service DLLs (
MetasequoiaImeTsf.dll, x64 and Win32); - the installer
MetasequoiaIME_Setup_v<version>.exe.
Third-party binaries, such as the libraries vcpkg builds for the Server, are shipped as their upstream built them and are never submitted for signing. The exact list is in scripts/ci/signpath-files.ps1, and the matching SignPath artifact configurations are in installer/signpath/.
Source repository
https://github.com/metasequoiaime/MSIME-Windows, licensed under GPL-3.0. The default branch is develop; main is the release branch.
Team roles
| Role | Members | What the role may do |
|---|---|---|
| Committers and reviewers | fanlusky, houko, jsfaint, linyanm, Neptrue-Lin | Push branches and merge pull requests into develop |
| Release managers | fanlusky, houko | Promote develop to main, which is what releases a signed build |
| Approvers | houko | Approve signing requests in SignPath |
Approvers are the people configured as approvers of the release-signing policy in SignPath. Release managers are the members of the @metasequoiaime/maintainers team, which owns the release-critical paths in .github/CODEOWNERS: the workflows, installer/, scripts/, product-lock.json and version.txt. The organization account metasequoiaime-dev is used only by the release automation and is not a person; it holds no role above. How roles are granted is described in the organization's GOVERNANCE.md.
Contributors without write access can still propose changes through pull requests. Their changes are reviewed and merged by a committer before they can reach a release.
Build and release process
This is the process every SignPath-signed release goes through.
- Every change lands in
developthrough a pull request. Direct pushes and force pushes todevelopandmainare blocked by a branch ruleset, and the pull request must pass the required CI checks (Windows x64 and Win32 builds, Server, GUI framework, settings page, product inputs, package contents, workflow validation and dependency review). Repository admins can bypass the ruleset only when merging a pull request, not by pushing directly. CodeQL scans the default branch daily. - An approver promotes
developtomain. Feature branches cannot targetmaindirectly. - The release workflow runs in GitHub Actions: release-please opens and tests the release pull request, merges it, creates a draft release, then builds every component from source at that commit. When the release is signed through SignPath (the repository variable
WINDOWS_SIGNING_PROVIDERissignpath), every job that leads up to a signing request runs on a GitHub-hosted runner; none runs on a machine the project controls. Only a release signed with the project's own certificate is built on the project's self-hosted release runner, and such a release does not carry the SignPath Foundation certificate. - The workflow refuses to build a commit that is not in the history of
main, submits the payload binaries and then the installer to SignPath as two signing requests, each of which an approver must approve, attaches a build provenance attestation to the installer, and publishes the release with the installer's SHA256.
Dictionaries are not built in CI. They are downloaded from the release pinned in product-lock.json and verified against the SHA256 recorded there. See product-release.md for the full release design.
Privacy policy
Some features of the program send data over the network, and cloud candidates are on by default. What each feature sends, its default, and how to turn it off are documented in PRIVACY.md.
Reporting a problem
To report a signed binary that you believe was not built by this process, or any other security issue, see the organization's security policy.