TRUST / VERIFY
这一页，
不需要你相信我们
承诺可以写得很漂亮，边界也可以只挑好听的说。这一页反过来：先讲清我们做不到什么，再把你亲自核验每一条声明的方法一条条列出来——材料全部在公开仓库里，命令可以直接复制粘贴。
先说不做的事
我们承诺什么，
不承诺什么
- 绝不运营收集用户数据的云服务器——服务端由你自托管，构造上只经手密文。
- 绝不加入后门、密码找回绕过机制，或任何远程解锁途径。
- 绝不加入遥测、分析或广告。
- 绝不未经你显式操作就自动更新或自动上传数据。
- 安全问题透明披露：先修复、后发布，并致谢报告者。
- 已解锁的会话——解锁期间，能操作你机器的人能看到你所看到的。
- 内存提取——库解锁期间，密钥存在于进程内存中。
- 丢失或遗忘密码——没有找回路径，没有后门，没有远程解锁。
- 胁迫与威逼——没有胁迫密码，也没有似是而非的否认模式。
- 多用户隔离——这是单用户桌面应用。
- 安全擦除——删除后不对存储层面的残留做任何承诺。
- 自托管服务端的可用性——拒绝服务在模型之外。
- 已被攻陷的操作系统、固件或虚拟机监控程序。
- 任何"官方云"才需要防的事——我们并不运营云。
- 你的网络元数据——出站连接列在应用内的网络活动面板里。
防得住谁，防不住谁
七类攻击者，
逐类写清边界
边界：隐私锁 + 你的 Windows 账户权限。成立前提：库已加密且应用处于锁定状态。失效：隐私锁未开，或应用已解锁且无人看管。
边界：结构上不存在。以你的权限运行的代码能读到应用所读的明文、截获密码、并在解锁期间取出进程内存中的密钥。
边界：AES-256-GCM + 每用户随机盐 + 300 万次迭代 PBKDF2-SHA256。成立前提：加密容器且密码足够强——KDF 抬高每次猜测的成本，救不了弱密码。
边界：服务端只保存密文块与小型明文信封，不持有任何密钥；协议假定 HTTPS。注意：服务端是你主动运行的组件，TLS 与暴露面由你的部署负责。
边界：解锁门禁、按客户端授权、权限矩阵、字段脱敏、删除总闸与审计。失效：宽权限客户端把合法读到的内容转发给云端服务——其供应商如何处理数据，Novara 控制不了。
边界：CI 全绿才产出、每个版本带 SHA256SUMS、镜像 digest 钉在 IMAGES.txt、发布 SBOM；安装包与镜像自 10.1 起再加无密钥 Sigstore 签名（把工作流与 tag 钉死）。详见下方核验区。
引导级篡改、被攻陷的固件或虚拟机监控程序、胁迫——不在威胁模型范围内，是刻意的立场而非疏漏。
| 缓解措施 | 防护对象 | 不防护的对象 |
|---|---|---|
| AES-256-GCM（12 字节 nonce、16 字节 tag，带版本头） | 加密文件被静默篡改与未授权读取（A1、A3） | 明文库；已解锁的会话 |
| 每用户随机盐 + PBKDF2-SHA256（300 万次迭代） | 离线猜测的成本（A3） | 弱密码；机器上软件的直接窥视 |
| 连续 5 次失败封 30 分钟（状态落盘、单调时钟） | 锁屏界面上试密码（A1） | 对已复制文件发起的离线攻击 |
| 原子写入 + Flush(true)、串行化保存队列、单实例互斥与独占锁 | 损坏与并发覆盖 | 保密性——这是一条数据完整性措施 |
| 回收站与滚动本地备份 | 误删 | 对机器本身的蓄意破坏 |
| .novaenc v4 容器、导出强制密码门、封包前剥离凭据 | 明文离开本机；快照外泄（A3） | 弱导出密码 |
| 服务端只存密文、密钥分离、token 仅存 SHA-256 且常时比较限流 | 好奇或被攻陷的服务端（A4） | 未做 TLS 的部署；服务端可用性 |
| 浏览器阅读器只在 JS 内存中持有明文，不持久化 | 数据滞留在共用浏览器上 | 已被攻陷的浏览器或扩展 |
| MCP 默认关闭、解锁门禁、按客户端授权、权限矩阵、删除总闸、字段脱敏、本地审计 | 权限过宽或好奇的 Agent 客户端（A5） | 供应商如何处理客户端合法读到的数据 |
| 导入与编辑器按严格白名单净化，不对不可信输入求值 | 通过导入内容进行的注入 | 在已被攻陷的渲染器内渲染的恶意内容 |
| 桌面端不开放监听端口、出站只走你主动触发的路径 | 远程攻击面（A4） | 你自己关于"要连什么"的决定 |
| CI 门禁、SHA256SUMS、镜像 digest 钉值、SBOM、无密钥 Sigstore 签名（10.1 起） | 分发渠道被篡改（A6） | 平台本身或签名基础设施被攻陷 |
本页核心
下载来的文件，
自己动手验
材料随每个版本附带，命令可直接复制粘贴；具体这一版的哈希值在下载页与中转页上。完整说明见公开仓库的《校验你的下载》。
最基础的一步，人人可做。下载安装包与 SHA256SUMS 附件，在 PowerShell 中：
Get-FileHash .\Novara_Setup_novara12.exe -Algorithm SHA256
有 sha256sum 的话，把安装包放到 SHA256SUMS 旁边，一条命令完成：
sha256sum -c SHA256SUMS
每个服务端版本都在 IMAGES.txt 附件里钉住镜像 digest——按 digest 拉取可以把字节钉死：
docker pull ghcr.io/novara-owner/novara-sync@sha256:<IMAGES.txt 中的 digest>
校验已拉到本地的镜像：
docker inspect --format='{{index .RepoDigests 0}}' ghcr.io/novara-owner/novara-sync:12.0.0
发布附件里有 SPDX 格式的物料清单（Syft 生成），列出产品中的每一个组件：
jq -r '.packages[].name' novara-sync-12.0.0.spdx.json | sort -u
自 10.1 起，每个版本都由发布工作流以无密钥方式签名：短期证书证明"哪个仓库、哪个工作流、哪个 tag"产出了这份字节，并记入公开透明度日志；10.0.0 未附签名包。把 signature.bundle 与安装包放到同一目录：
cosign verify-blob \ --bundle signature.bundle \ --certificate-identity-regexp '^https://github\.com/Novara-owner/Novara-Vault/\.github/workflows/ci\.yml@refs/tags/(v|novara)' \ --certificate-oidc-issuer https://token.actions.githubusercontent.com \ Novara_Setup_novara12.exe
镜像签名存放在镜像仓库中，按 digest 校验，身份条件相同：
cosign verify \ --certificate-identity-regexp '^https://github\.com/Novara-owner/Novara-Vault/\.github/workflows/ci\.yml@refs/tags/(v|novara)' \ --certificate-oidc-issuer https://token.actions.githubusercontent.com \ ghcr.io/novara-owner/novara-sync@sha256:<IMAGES.txt 中的 digest>
Windows 安装包暂未做 Authenticode 签名：首次运行时 SmartScreen 可能弹提示。先完成上文的校验，再选择"更多信息 → 仍要运行"。该状态一旦改变，签名方式与每次发布的批准流程都写在下方 Code signing policy 节。
完整校验说明（VERIFYING.md）一个版本是怎么来的
构建被钉到什么程度，
以及我们不声称什么
版本由公开仓库的 CI 工作流在版本 tag 上产出。这一板块的单一出处是仓库的《构建溯源》（PROVENANCE.md），此处只做摘要。
- 构建与测试——还原依赖、构建、全量单元测试。能拦。
- 依赖与许可证审计——出现 Critical 漏洞公告直接失败。能拦。
- 桌面构建（WinUI 应用）。能拦。
- 发布产物（自包含同步服务端可执行文件）。能拦。
- 打包安装包——手动触发；构建安装包，并比对两趟发布是否逐字节一致。能拦。
- 签名——自 10.1 起对容器镜像与安装包以无密钥 Sigstore 方式签名。能拦。
- Novara_Setup_x.y.z.exe — Windows 安装包
- SHA256SUMS — 安装包的 SHA-256
- IMAGES.txt — 容器镜像的精确 digest（GHCR 与 Docker Hub 同值）
- novara-sync-x.y.z.spdx.json — 软件物料清单（SPDX，Syft 生成）
- signature.bundle — 安装包的 Sigstore 签名包（10.1 起）
- SDK 版本在 global.json 里精确钉死并关闭 roll-forward。
- 依赖由 NuGet 锁文件钉住，CI 以锁定模式还原——对不上即失败。
- 源码路径映射到中性根目录，出厂二进制不携带构建机目录结构。
- 发布产物在 Level 1 上可复现——同一冻结提交、同一环境，产出逐字节相同；发布前构建两次并逐文件比对，编译安装包两次并比对哈希。
- 不能从公开仓库复现——那是发布快照；复现基准是开发仓的冻结提交。
- 不能跨机器复现——Level 1 的含义是同一环境。
- 安装包尚未做 Authenticode 签名，SmartScreen 仍可能提示。
- 出厂二进制包含调试信息（随 exe 提供 .pdb）。
- 没有第三方独立审计——Scorecard 是自动评分，威胁模型是我们自己写的。
代码签名政策
Code signing policy
Free code signing provided by SignPath.io, certificate by SignPath Foundation
（中文大意：免费代码签名由 SignPath.io 提供，证书由 SignPath Foundation 签发。）
签的是什么Novara_Setup_x.y.z.exe —— 随 Release 页附上的 Windows 安装包。自 10.0 起，安装包由 CI 从打了 tag 的源码构建，且每一次发布都要人工批准才提交签名；9.4.0 及以前由发布机打包。安装包内的程序来自同一次构建；上游开源项目的二进制（.NET 运行时、Windows App SDK、Win2D）以未签名形式随包分发——给它们签名是各自维护方的责任，不是我们的。
团队角色与成员Novara 由单一账号维护，该账号同时承担全部角色。角色定义与 SignPath Foundation 一致。
| 角色 | 成员 |
|---|---|
| Authors（作者）——可不经额外评审直接改动源码 | @Novara-owner |
| Reviewers（评审）——评审非提交者提出的改动 | @Novara-owner |
| Approvers（批准）——对每一次发布决定是否可签名 | @Novara-owner |
Novara 是本地优先的，除非你要求，它不会向我们或任何第三方传输信息。
隐私政策 ↗ 状态SignPath Foundation 证书覆盖本政策生效之后发布的第一个安装包。在此之前发布的安装包未经 Authenticode 签名、也未追溯补签——对这些版本，请按上方核验区校验 SHA-256 与 Sigstore 签名。Sigstore 签名自 10.1 起随每个版本提供。
完整政策（CODE_SIGNING_POLICY.md）发现了问题