Kaldera代码签名政策
最后更新：2026 年 10 月 · 提供 12 种语言。
1. 本政策规定的内容
本页说明 KalderaShield 的哪些发布产物由谁签名、采用何种密钥保管方式，以及每份签名由谁负责批准。仓库中同一文档的源版本：CODE_SIGNING_POLICY.md
2. Windows
Free code signing provided by SignPath.io, certificate by SignPath Foundation.
状态：尚未提交申请。 KalderaShield 计划向 SignPath Foundation 提交申请，并已提前准备好本政策，因为对方条款要求本政策在提交申请之前就已存在。申请尚未提交，也没有待决结论。本节不得被理解为任何 Windows 产物目前已签名。它并未签名。在首个已签名版本真正发布之前，诚实的表述就是下面的状态表；本节会在该版本发布之前更新。
将被签名的文件是 NSIS 安装程序（KalderaShield_<版本>_x64-setup.exe）、用于受管部署的 MSI 包（KalderaShield_<版本>_x64.msi）以及无需安装的便携可执行文件（KalderaShield_<版本>_x64-portable.exe）。三者均由本仓库构建，并在发行页面发布。凡非由本仓库构建的产物，一律不以本项目证书签名；也不会用该证书对任何第三方二进制文件重新签名。
密钥保管：私钥在 SignPath 的 HSM 中生成并保存。本项目从不持有该密钥，从不导出，也绝不将其传递给构建运行器或开发人员机器。签名在 SignPath 一侧进行，响应的是本仓库 CI 提交并由人工批准的签名请求。
链条：推送版本标签 → GitHub Actions 构建这些文件（工作流是公开的，第三方 action 按 commit SHA 固定，令牌权限为只读）→ 构建将文件上传至 SignPath 并发起签名请求，但自身不签名 → 一位 Approver 批准或拒绝 → SignPath 使用 Foundation 证书签名 → 已签名文件与 SHA256SUMS.txt 一并发布。每个发行版都需要人工批准；不存在无人值守的签名路径，也不会新增。
有效的 SignPath Foundation 签名意味着该二进制文件是可验证的自动化构建，源自本仓库在发行版所指明提交处的源代码。这并不意味着软件经过审计，也不构成对该应用的安全背书。本项目发布了威胁模型与质量门禁文档，但没有完成的独立第三方安全审计：
3. 团队角色
KalderaShield 由一人维护。此处如实说明，而非包装成团队，因为下面这些角色正是 SignPath 所要求的，而唯一的维护者只有独自一人才能诚实地承担。所有对本仓库拥有写入权限的账户均已启用多重身份验证。
作者（Authors） — 无需额外审查即可修改源代码的人员：
hafgit99— github.com/hafgit99
这是唯一拥有写入权限的账户。本仓库由个人账户而非组织所有，因此写入路径是一个启用了多重身份验证的单一身份。
审查者（Reviewers） — 在合并前审查无提交权限者提出的每一项更改的人员：
hafgit99
目前没有无提交权限的贡献者，因此该角色与其说人手稀少，不如说实际上是空的。
批准人（Approvers） — 在产物被签名前批准每份签名请求的人员：
hafgit99
已知缺口：三个角色都由同一人承担，编写代码的人也就批准了自己的签名。SignPath 的模型假定 Approver 是「受全团队信任」的人，而这预设了团队成员不止一位。增设第二名 Approver 的计划已有，但尚未完成。认为这一点构成否决理由的审查者，应当现在就提出，而不是等到批准之后。
4. 隐私政策
按 SignPath 要求的措辞：本程序不会将任何信息传输到其他联网系统，除非用户或安装、运行本程序的人明确提出要求。
KalderaShield 是一款离线优先、零知识的密码管理器。保管库内容在设备上使用由主密码派生的密钥加密，绝不传输。它没有账户、没有同步服务、没有遥测、没有分析。Windows 二进制文件中除操作系统自身的组件外，不含任何网络客户端。完整文本见 隐私政策. 影响用户的第三方组件行为记录在 LICENSE-3RD-PARTY.md 中。
5. 其他平台
macOS — 产物使用 Apple Developer ID 签名并由 Apple 公证。证书尚未签发，因此没有任何 macOS 产物已签名，也没有发布任何 macOS 产物。Linux — .deb、.rpm、.AppImage 以分离式 GPG 签名（.sig）发布；SBOM 与浏览器扩展包以无密钥 Sigstore 签名（.sigstore.json）发布。Android — 发行版 APK 使用保存在 GitHub Actions 机密中的发行密钥库签名；Android 签名与 Authenticode 相互独立。任何平台在真正签名之前，都不会被描述为已签名。
当前状态：Linux、Android 和浏览器扩展已发布并已签名。Windows 仅以未签名预览形式发布：这是一份预发行版，不是稳定发行版，latest 也不会指向它。未签名文件会触发 Windows SmartScreen 的"已保护你的电脑"提示，需要点击"更多信息"→"仍要运行"才能运行安装程序——这是预期行为。运行前请用 SHA256SUMS.txt 核对 SHA-256 摘要。向 SignPath Foundation 的签名申请尚未提交。macOS 未发布且未签名（证书尚未签发）。
Windows 产物不作为发行版发布——发布流水线把未签名的桌面发行版视为失败，且 .github/workflows/ 中没有任何工作流能够发布它。预览版由维护者在自己的机器上手工组装、通过 GitHub 自身的发行表单上传，并标记为预发行版，因此它明显是临时性的，latest 绝不会指向它，下一个已签名发行版会取代它。这条路线是有意为之，而非变通做法。仓库中有一道安全闸门（npm run security:release-signing），会拒绝任何能把未签名构建变成发布物的工作流，它的结论性主张是：没有签名机密时，公开的桌面发行版按设计不可能存在。为工作流添加例外，等于用一项便利换取这条主张变成谎言。把上传留在浏览器里，才保住了这个保证。该闸门记录在代码签名与产物签名指南中，分步流程见计划：先上线站点，再发布 Windows 未签名预览。
6. 报告问题
如果你认为某个以 SignPath Foundation 证书签名的产物违反了本政策，请将该产物的哈希值和理由发送至 support@signpath.io。关于这些产物的其他任何问题，请使用 security@kalderashield.com；披露流程见 SECURITY.md。
如有差异，以本政策的土耳其语文本为准。