政策与署名
ResumeForge 的 Windows 安装包由 SignPath Foundation 的免费开源代码签名计划提供签名。证书主体为 SignPath Foundation，而非项目维护者的 GitHub 账号；这是该计划的既定安排。当前是否已有签名版本发布，以「当前状态」一节为准。
Free code signing provided by SignPath.io, certificate by SignPath Foundation.
本页是 SignPath 要求项目公示的签名政策。下文所述流程与仓库中的工作流定义一一对应，可直接对照公开代码核对。
签名覆盖哪些文件
签名范围仅包含一个产物：Windows 安装包 ResumeForge-Setup-<version>.exe（NSIS 安装器）。该文件使用 SHA-256 摘要的 Authenticode 签名；RFC 3161 时间戳由 SignPath 侧的签名策略附加。仓库中的工作流不向签名服务传递任何签名参数，摘要算法与时间戳均由 SignPath 的 artifact configuration / signing policy 决定，相关配置需在 SignPath 后台核对。时间戳的作用是：即使证书日后到期或被吊销，已发布安装包的签名仍可验证为「签名当时有效」。
其余产物不在签名范围内，具体如下：
| 产物 | 签名范围 | 说明 |
|---|---|---|
ResumeForge-Setup-<version>.exe | 包含 | Windows 安装包；SHA-256 Authenticode，RFC 3161 时间戳由 SignPath 侧签名策略附加 |
ResumeForge-<version>-x64.dmg / -arm64.dmg | 不包含 | macOS 签名证书尚未配置，因此未签名、也未公证；首次打开需右键 →「打开」，或按安装文档的说明处理。证书配置后将更新本表 |
| 源码 zip（all / windows / macos） | 不包含 | 纯源码发行包，用对应的 .sha256 校验完整性；它不会被当作程序直接执行，因此无需 Authenticode 签名 |
每个安装包与 dmg 均附带同名 .sha256 文件，与 Release 页面上的附件一一对应；哈希值按最终发布的文件计算。
签名来自哪一次构建
签名请求仅有一个来源：公开仓库 magicapple123/ResumeForge 里的 .github/workflows/release-assets.yml。流程固定为三步：
- GitHub 托管的
windows-latestrunner 从指定的 tag（或用于演练的 ref）检出源码，构建前端与桌面壳，打出 NSIS 安装包； - 该安装包作为本次 workflow run 的 artifact 上传；
- SignPath 的 GitHub Action 用该 artifact 提交签名请求，并校验它确实来自这一次 workflow run（origin verification）之后才会签名；签名完成后把重签的文件回传给同一次 run。
构建与签名均在 CI 中完成，不存在经由开发机或人工上传安装包签名的通道。要确认某次发布是否经由该流程，可查看该 release 对应的 workflow run：运行页面会记录签名请求的链接与请求 ID。
团队角色与批准流程
项目目前由单一维护者维护（Cenguo Huang，GitHub @magicapple123）。下列三个角色当前均由该维护者承担；三者按职责划分，不因人员数量而合并。
| 角色 | 成员 | 职责 |
|---|---|---|
| Authors | @magicapple123 | 编写并提交代码。外部贡献者的 Pull Request 须经维护者评审后方可合入 main；外部贡献者没有直接推送权限。 |
| Reviewers | @magicapple123 | 评审与发布链路相关的改动，包括构建脚本、release-assets.yml 中与签名相关的每个步骤，以及版本号与 tag。改动须经评审通过后合入。 |
| Approvers | @magicapple123 | 批准签名请求。每次签名请求均需 Approver 在 SignPath 后台人工批准；CI 通过不会自动签发。 |
维护者在 GitHub 与 SignPath 两个账号上均启用了多因素认证（MFA）。签名所需的 API token 只存放在 GitHub 仓库的 Secrets 里，工作流运行时注入，不出现在日志或产物中。
隐私
签名完全发生在构建侧，不涉及终端用户数据。引入签名不改变隐私与数据主权页面中的任何承诺：简历、岗位、资料、提醒与助手会话只保存在本机数据目录，应用没有账号体系、埋点或遥测，AI 功能仅在用户主动调用时联网。
签名环节涉及的两个系统只获得必要信息：SignPath 接收待签名的二进制文件，以及该次构建的 workflow 元数据（仓库、commit、run 标识），用于验证来源。签名服务不接触用户数据，用户数据既不在构建产物中，也不在上传范围内。签名也不会在用户电脑上安装或修改任何内容；安装包保存在本地，签名验证由 Windows 完成。
如何验证签名
签名生效后，Windows 安装界面显示的发布者名称为 SignPath Foundation，而非 magicapple123。证书由基金会持有并签发给通过审核的开源项目，因此发布者名称与项目作者不一致属于正常情况。该签名证明的是：文件由本项目的 CI 构建，并由基金会签发。
如需自行验证，可在 PowerShell 中执行以下命令（将文件名替换为实际下载的文件）：
| 命令 | 检查项 |
|---|---|
Get-AuthenticodeSignature .\ResumeForge-Setup-<version>.exe | Format-List Status, StatusMessage, SignerCertificate | Status 应为 Valid；若不是，StatusMessage 会说明原因（常见为根证书不受信任）。SignerCertificate.Subject 应包含 SignPath Foundation |
Get-FileHash .\ResumeForge-Setup-<version>.exe -Algorithm SHA256 | 与 Release 页面上同名 .sha256 附件的内容比对，确认下载没有出错 |
Get-AuthenticodeSignature .\ResumeForge-Setup-<version>.exe | Select-Object -ExpandProperty TimeStamperCertificate | 能取到时间戳证书，说明 RFC 3161 时间戳已经附加 |
若 Status 为 NotSigned，说明该文件没有签名，常见原因是该版本发布于签名接入之前。此时仍可用 SHA-256 校验文件完整性，但不应将其视为已验证发布者的文件。
当前状态
截至 2026-11-06，test-signing 已通过端到端验证：CI 完成了构建、上传 artifact、提交签名请求、SignPath 验证来源、回签，以及用签名后的文件生成 .sha256 的完整流程，签名请求状态为 Completed。该结果即上文所述流程的一次实际执行记录。
可核对的记录有两份：演练工作流运行（全部作业通过），以及对应的签名请求 ec1837db-7b38-4053-8f70-ea8b34824e8e（可在 SignPath 后台的 Signing Requests 中查询）。本次签名使用 test-signing 的测试证书，主体为 CN=Test certificate for 'ResumeForge [OSS]'；其根证书不在 Windows 信任列表中，因此签名验证状态为 UnknownError，而非 Valid。这是该阶段的预期结果：测试证书用于验证流程可用，其产物不面向最终用户，也不会发布到 Release。
生产证书仍待 SignPath Foundation 签发，因此 Release 中当前可下载的安装包尚未签名。在此之前，请使用 .sha256 校验下载文件，并按 Windows 的常规提示完成安装。状态发生变化时，本页与 CHANGELOG.md 将同步更新。
如对本页有疑问，可在公开仓库中查阅签名工作流、构建脚本与发布记录，也可以到 GitHub Issues 提问。