msime-windows/docs/code-signing-policy.md

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.

Test signing review

The Release workflow has a manual test_signing dispatch mode. It builds the selected commit on GitHub-hosted runners, validates the SignPath test-signing policy and certificate, submits the payload and installer through the same reviewed artifact configurations as a release, and stores the signed installer only as a workflow artifact. It does not create or publish a GitHub Release. The run summary records both SignPath request URLs for review.

The test certificate is imported only into the ephemeral runner for signature verification; it is never committed or published as a secret.

Build and release process

This is the process every SignPath-signed release goes through.

1. Every change lands in develop through a pull request. Direct pushes and force pushes to develop and main are 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.
2. An approver promotes develop to main. Feature branches cannot target main directly.
3. 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_PROVIDER is signpath), 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.
4. 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.