Super Productivity SuperSync 数据库静态加密决策解析为何放弃 LUKS 与 PostgreSQL TDE以及操作员如何补齐存储安全【免费下载链接】super-productivitySuper Productivity is an advanced todo list app with integrated Timeboxing and time tracking capabilities. It also comes with integrations for Jira, GitLab, GitHub and Open Project.项目地址: https://gitcode.com/GitHub_Trending/su/super-productivitySuperSync 是 Super Productivity 的开源同步服务端负责操作日志的中继、排序与冲突裁决。本文围绕仓库中的 ADR 决策文档 docs/supersync-encryption-at-rest-decision.md完整梳理一个关键且容易误读的技术事实SuperSync 当前不提供项目自管理的 PostgreSQL 数据库文件静态加密encryption at rest并且此前尝试过的 LUKS 与 PostgreSQL TDE 两条路径均因生产环境OpenVZ不支持而被正式退役。阅读本文后你将清楚区分客户端 E2EE数据库文件加密备份文件加密这三层安全边界理解退役决策的技术理由与 Git 历史证据并掌握操作员在现有部署下保护数据库、正确备份与恢复、以及未来重新评估该决策所需的完整检查清单。决策结论不接受项目自管的数据库文件加密该 ADR 文档的决策非常明确当前 SuperSync 部署不进行项目管理的 PostgreSQL 数据库文件加密仓库也不提供、不支持 LUKS 或 PostgreSQL 透明数据加密TDE的部署路径。这一结论并非安全设计上的遗漏而是一次经过实验验证后的主动退役。从源码结构看该决策在整个仓库中是成体系的服务器端状态同步文档 packages/super-sync-server/docs/encryption-at-rest.md 以相同口径声明当前 SuperSync 部署不提供数据库文件加密并指向本决策文档作为持久化理由与重新评估标准归档目录 packages/super-sync-server/archive/encryption-attempts-openvz-incompatible/README.md 则保存了完整的历史证据。退役的技术原因OpenVZ 容器环境不支持 LUKS 与 TDE为什么不能直接在 PostgreSQL 数据卷上启用加密根据决策文档与归档说明原因不在于加密算法本身而在于生产部署环境的能力边界LUKS 方案需要dm-crypt等宿主机内核能力。LUKSLinux Unified Key Setup是磁盘块级加密的标准方案但它的使用要求内核提供 device-mapper crypt 目标。在 OpenVZ 这类基于容器虚拟化container-based virtualization的托管环境中租户通常无法加载、管理这些内核模块LUKS 工具链无法运行。PostgreSQL TDE 实验同样不可行。PostgreSQL 社区版本本身不提供内建 TDE透明数据加密项目尝试的实验性方案在该环境下同样无法运转。两个尝试都被退役retired而不是保留在活跃部署路径中。决策文档给出了一条重要的工程原则与其留下一个无法在生产环境测试的安全机制不如将其移除——不可测试的安全机制比没有更危险因为它会给人虚假的安全感。归档 README 记录了完整的实现与退役历史保留了 Git 提交哈希作为溯源指针事件Git 提交LUKS 工具链开始cb2e2e65a2LUKS 测试/迁移支持c8bce3c8cf安全后续跟进0573468797LUKS 方案退役并归档e050eb99faPostgreSQL TDE 实验落地1fdcc9a906PostgreSQL TDE 实验回滚3a58044826归档目录中只保留了说明性文档可执行文件与 runbook 已被删除。这一点是刻意的防止历史脚本被误认为是受支持的生产路径。决策文档明确警告不要把归档的 LUKS 设计描述为生产就绪方案也不要把它当作合规性regulatory compliance的证明。三层安全边界E2EE、数据库文件加密、备份加密是三个不同概念这是理解该决策最关键的辨析点。很多讨论把客户端加密数据库加密备份加密混为一谈而 SuperSync 明确将它们区分为三个独立控制面第一层SuperSync E2EE客户端端到端加密——提供负载机密性SuperSync E2EE 是独立的客户端侧功能。从 packages/sync-core/src/encryption.ts 的实现可以看到完整的加密链路采用Argon2id 密钥派生 AES-GCM 对称加密WebCrypto 可用时使用crypto.subtle否则回退到noble纯 JS 实现。线格式是冻结的公开协议源码 JSDoc 明确标注do not change without a version-byte migrationArgon2id 密文[SALT (16)][IV (12)][AES-GCM ciphertext auth tag] ( 44 bytes) Legacy 密文[IV (12)][AES-GCM ciphertext auth tag] ( 28 bytes)IV每次调用由 CSPRNG 全新生成12 字节保证同一密钥下 IV 唯一性这是 AES-GCM 机密性与完整性integrity的前提。Salt在进程会话, 密码维度派生一次并跨会话缓存复用从而摊薄 Argon2id 每次约 500ms2s 的密钥派生开销会话缓存由 packages/sync-core/src/encryption/session-cache.ts 管理encryptBatch/decryptBatch的批量接口就是为了移动端而优化——一次性派生密钥再并行加解密多个操作。但 E2EE 有一个清晰边界只有operation.payload操作负载在客户端加密。服务器没有密钥只能把它当作不透明值存储。路由与因果元数据——操作 ID、客户端 ID、操作类型、实体 ID、向量时钟、时间戳、schema 版本、导入原因、以及isPayloadEncrypted标志——全部保持明文并且正是靠这些元数据完成校验、排序与冲突检测。这一点在 packages/super-sync-server/docs/architecture.md 的 E2EE Boundary 一节有完整定义。更关键的是AES-GCM 的认证标签并不认证明文元数据。因此 E2EE 提供的是负载的机密性与完整性而不是元数据机密性也不是完整操作端到端认证。换句话说服务器仍能看到谁在什么时候对哪个任务做了什么只是看不到任务内容。服务器侧还存在一个结构分类器用于防止意外明文上传packages/sync-core/src/encryption/transport-shape.ts 中的isEncryptedPayloadTransportShape()是一个零依赖的纯字符串检查要求 payload 是字符串、长度 4 的倍数、符合规范 base64 字符集无空白、无 base64url 字符、填充仅在末尾、解码后字节数不低于对应信封最小值。它只做形状检查而非密码学证明——足够长的 base64 明文也能通过——其目的是在服务器边界拒绝意外明文和畸形上传且不解码、不分配、不记录负载内容。第二层数据库文件加密——当前由基础设施层负责决策文档明确PostgreSQL 文件与普通数据库转储不被 SuperSync 加密。E2EE 的启用与否都不影响这一点——E2EE 加密的是上传到服务器之前的操作负载而数据库卷是另一回事。架构文档也确认加密的全量状态上传仍然是操作行但无法成为服务器可读的状态缓存服务器没有密钥普通明文数据的快照缓存优化对加密账户自动失效。当前部署的数据库形态可以从生产 Compose 文件确认packages/super-sync-server/docker-compose.yml 使用postgres:16-alpine通过postgres-data命名卷持久化数据没有任何加密卷、dm-crypt或文件级加密配置。数据保护完全落在宿主机的访问控制与托管环境上。第三层备份文件加密——独立的运维控制加密的数据库备份流同样独立于活动数据库文件加密。SuperSync 的备份策略是pg_dump定时导出见下文pg_dump输出是明文 SQL。备份加密与否是操作员自行决定的运维控制与数据库文件是否加密是两回事——即使将来启用了数据库文件加密也不等于备份文件自动加密反之亦然。决策文档给出的边界结论是不要因为部署了 E2EE 就认为 PostgreSQL 卷是加密的也不要因为备份文件做了加密就认为数据库文件加密了。操作员指南在无静态加密前提下如何保护数据库既然项目层面不做数据库文件加密决策的后果Consequences就是把责任明确交给部署方部署依赖访问控制和托管环境来保护数据库文件。需要保护的对象根据 packages/super-sync-server/docs/encryption-at-rest.md 的指引包括宿主机控制谁能登录、谁能以 root 操作。PostgreSQL 凭据POSTGRES_PASSWORD、DATABASE_URL等敏感环境变量从 env.example 复制到.env后应严格限制文件权限。文件系统数据库卷、应用数据目录。提供商快照provider snapshots很多 VPS 提供商会做磁盘快照快照同样包含明文数据库文件。备份位置备份目录、rclone 远端见下文。备份与恢复与明文数据库共存的工作流SuperSync 的备份体系在 packages/super-sync-server/docs/backup-and-recovery.md 中有完整文档。架构前提是客户端是数据权威来源clients are the source of truth服务器只是中继——每个客户端在本地 IndexedDB 中保有完整数据副本。这极大简化了灾难恢复只要有一个客户端设备存活所有数据都能恢复。备份脚本创建两类转储转储内容规模全量转储supersync_*.sql.gz完整数据库含全部操作活跃实例约 300MB账户专用转储supersync_accounts_*.sql.gz仅users与passkeys表极小1MB关键配置变量变量默认值说明BACKUP_DIR../backups备份文件存储目录RETENTION_DAYS14删除早于此天数的备份DB_CONTAINERsupersync-postgresDocker 容器名POSTGRES_USERsupersync数据库用户POSTGRES_DBsupersync数据库名RCLONE_REMOTE空可选的 rclone 异地上传远端推荐恢复路径是账户专用恢复accounts-only restore先恢复users passkeys让服务器同步数据从空开始客户端重连时缺口检测gap detection自动触发各客户端重新上传完整状态并收敛到一致状态。这样能避开部分恢复导致的SYNC_IMPORT_EXISTS冲突。全量恢复仅在所有客户端设备全部丢失时作为兜底使用。作为操作员请注意备份文件中包含的是明文数据包括用户邮箱与密码哈希、passkeys 以及全部操作负载——除非客户端启用了 E2EE。因此备份位置本身的保护优先级很高如需对备份加密应使用独立工具如gpg、openssl enc或加密的 rclone 远端这属于运维控制而非项目提供的功能。重新评估条件什么情况下才应重启数据库静态加密项目决策文档并非永久否决而是设定了严格的重新审视revisit条件只有持有**运维方所有operations-owned**的提案时才应重新考虑该决策提案必须包含支持所选机制的部署环境——例如能加载dm-crypt的 KVM 主机而不是 OpenVZ 容器在当前 Compose/数据库布局上经过测试的迁移与回滚流程启动boot、密钥轮换key rotation、备份与灾难恢复的完整程序监控与演练过的恢复测试restore test更新后的威胁模型清晰区分负载 E2EE、数据库文件加密、备份加密三层。文档指出的可行未来方向包括迁移到KVM 主机使用基础设施托管的磁盘加密如 LVM 加密卷、托管磁盘加密或改用提供静态加密的托管 PostgreSQL 服务managed PostgreSQL service。同时强调Git 历史中被退役的实现只能作为研究输入不能作为快速审批的捷径。归档 README 也重申任何未来的存储加密项目都需要在设计、迁移、回滚、启动、密钥轮换、备份与恢复流程上全新设计和演练。测试与验证现有行为有 E2E 覆盖虽然没有数据库静态加密但围绕明文数据生命周期的安全与恢复行为有自动化测试保障备份恢复场景由 e2e/tests/sync/supersync-server-backup-revert.spec.ts 覆盖包括服务器完全数据丢失后单客户端恢复全部数据、服务器回退到旧状态时客户端保留本地数据、账户专用恢复的多客户端收敛、以及混合加密/明文历史的失败关闭fail closed再恢复。加密传输形状分类器在 packages/sync-core/src/encryption/transport-shape.ts 的配套 spec 中与真实encrypt()输出交叉校验字节下限CI 还通过tools/generate-android-crypto-fixtures.mjs把新鲜加密输出喂给 Android Kotlin 测试验证跨端线格式一致见 packages/sync-core/src/encryption.ts 模块说明。服务器侧加密/明文相关的载荷审计与回归用例集中在 e2e/tests/sync/ 目录。此外仓库中还有一份关于清除历史明文同步数据的提案 packages/super-sync-server/docs/e2ee-legacy-data-eradication-plan.md它从另一个角度印证了本文的安全边界服务器仅通过isPayloadEncrypted标志与密文形状来区分加密/明文该标志本身是不带认证的因此计划中反复强调不能只信标志、必须做形状检查并规划了加密-only 上传闸门E2EE_REQUIRED与数据库 CHECK 约束兜底。这再次说明SuperSync 的加密保障体系是客户端 E2EE 服务器形状闸门 运维层存储保护的组合而不是数据库文件静态加密。小结把每层加密放到正确的位置总结这份 ADR 的核心要义项目决策SuperSync 不做项目自管理的 PostgreSQL 数据库文件加密LUKS 与 PostgreSQL TDE 均因生产 OpenVZ 环境不支持而退役归档于 packages/super-sync-server/archive/encryption-attempts-openvz-incompatible/。分层边界E2EE客户端负载加密元数据明文≠ 数据库文件加密未提供≠ 备份文件加密独立运维控制。三者必须分开评估谁都不能替代谁。操作员行动项保护宿主机、凭据、文件系统、快照与备份位置需要加密存储时在基础设施层KVM 磁盘加密或托管 PostgreSQL实现并在精确的生产拓扑上演练迁移、启动/解锁、备份、恢复、密钥轮换、监控与回滚后再宣称合规。重新评估门槛一份由运维方拥有的完整提案包含环境支持、可测试的迁移/回滚、启动与密钥轮换、备份与灾难恢复程序、监控与演练过的恢复测试以及分层清晰的更新威胁模型。【免费下载链接】super-productivitySuper Productivity is an advanced todo list app with integrated Timeboxing and time tracking capabilities. It also comes with integrations for Jira, GitLab, GitHub and Open Project.项目地址: https://gitcode.com/GitHub_Trending/su/super-productivity创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Super Productivity SuperSync 数据库静态加密决策解析：为何放弃 LUKS 与 PostgreSQL TDE，以及操作员如何补齐存储安全
Super Productivity SuperSync 数据库静态加密决策解析为何放弃 LUKS 与 PostgreSQL TDE以及操作员如何补齐存储安全【免费下载链接】super-productivitySuper Productivity is an advanced todo list app with integrated Timeboxing and time tracking capabilities. It also comes with integrations for Jira, GitLab, GitHub and Open Project.项目地址: https://gitcode.com/GitHub_Trending/su/super-productivitySuperSync 是 Super Productivity 的开源同步服务端负责操作日志的中继、排序与冲突裁决。本文围绕仓库中的 ADR 决策文档 docs/supersync-encryption-at-rest-decision.md完整梳理一个关键且容易误读的技术事实SuperSync 当前不提供项目自管理的 PostgreSQL 数据库文件静态加密encryption at rest并且此前尝试过的 LUKS 与 PostgreSQL TDE 两条路径均因生产环境OpenVZ不支持而被正式退役。阅读本文后你将清楚区分客户端 E2EE数据库文件加密备份文件加密这三层安全边界理解退役决策的技术理由与 Git 历史证据并掌握操作员在现有部署下保护数据库、正确备份与恢复、以及未来重新评估该决策所需的完整检查清单。决策结论不接受项目自管的数据库文件加密该 ADR 文档的决策非常明确当前 SuperSync 部署不进行项目管理的 PostgreSQL 数据库文件加密仓库也不提供、不支持 LUKS 或 PostgreSQL 透明数据加密TDE的部署路径。这一结论并非安全设计上的遗漏而是一次经过实验验证后的主动退役。从源码结构看该决策在整个仓库中是成体系的服务器端状态同步文档 packages/super-sync-server/docs/encryption-at-rest.md 以相同口径声明当前 SuperSync 部署不提供数据库文件加密并指向本决策文档作为持久化理由与重新评估标准归档目录 packages/super-sync-server/archive/encryption-attempts-openvz-incompatible/README.md 则保存了完整的历史证据。退役的技术原因OpenVZ 容器环境不支持 LUKS 与 TDE为什么不能直接在 PostgreSQL 数据卷上启用加密根据决策文档与归档说明原因不在于加密算法本身而在于生产部署环境的能力边界LUKS 方案需要dm-crypt等宿主机内核能力。LUKSLinux Unified Key Setup是磁盘块级加密的标准方案但它的使用要求内核提供 device-mapper crypt 目标。在 OpenVZ 这类基于容器虚拟化container-based virtualization的托管环境中租户通常无法加载、管理这些内核模块LUKS 工具链无法运行。PostgreSQL TDE 实验同样不可行。PostgreSQL 社区版本本身不提供内建 TDE透明数据加密项目尝试的实验性方案在该环境下同样无法运转。两个尝试都被退役retired而不是保留在活跃部署路径中。决策文档给出了一条重要的工程原则与其留下一个无法在生产环境测试的安全机制不如将其移除——不可测试的安全机制比没有更危险因为它会给人虚假的安全感。归档 README 记录了完整的实现与退役历史保留了 Git 提交哈希作为溯源指针事件Git 提交LUKS 工具链开始cb2e2e65a2LUKS 测试/迁移支持c8bce3c8cf安全后续跟进0573468797LUKS 方案退役并归档e050eb99faPostgreSQL TDE 实验落地1fdcc9a906PostgreSQL TDE 实验回滚3a58044826归档目录中只保留了说明性文档可执行文件与 runbook 已被删除。这一点是刻意的防止历史脚本被误认为是受支持的生产路径。决策文档明确警告不要把归档的 LUKS 设计描述为生产就绪方案也不要把它当作合规性regulatory compliance的证明。三层安全边界E2EE、数据库文件加密、备份加密是三个不同概念这是理解该决策最关键的辨析点。很多讨论把客户端加密数据库加密备份加密混为一谈而 SuperSync 明确将它们区分为三个独立控制面第一层SuperSync E2EE客户端端到端加密——提供负载机密性SuperSync E2EE 是独立的客户端侧功能。从 packages/sync-core/src/encryption.ts 的实现可以看到完整的加密链路采用Argon2id 密钥派生 AES-GCM 对称加密WebCrypto 可用时使用crypto.subtle否则回退到noble纯 JS 实现。线格式是冻结的公开协议源码 JSDoc 明确标注do not change without a version-byte migrationArgon2id 密文[SALT (16)][IV (12)][AES-GCM ciphertext auth tag] ( 44 bytes) Legacy 密文[IV (12)][AES-GCM ciphertext auth tag] ( 28 bytes)IV每次调用由 CSPRNG 全新生成12 字节保证同一密钥下 IV 唯一性这是 AES-GCM 机密性与完整性integrity的前提。Salt在进程会话, 密码维度派生一次并跨会话缓存复用从而摊薄 Argon2id 每次约 500ms2s 的密钥派生开销会话缓存由 packages/sync-core/src/encryption/session-cache.ts 管理encryptBatch/decryptBatch的批量接口就是为了移动端而优化——一次性派生密钥再并行加解密多个操作。但 E2EE 有一个清晰边界只有operation.payload操作负载在客户端加密。服务器没有密钥只能把它当作不透明值存储。路由与因果元数据——操作 ID、客户端 ID、操作类型、实体 ID、向量时钟、时间戳、schema 版本、导入原因、以及isPayloadEncrypted标志——全部保持明文并且正是靠这些元数据完成校验、排序与冲突检测。这一点在 packages/super-sync-server/docs/architecture.md 的 E2EE Boundary 一节有完整定义。更关键的是AES-GCM 的认证标签并不认证明文元数据。因此 E2EE 提供的是负载的机密性与完整性而不是元数据机密性也不是完整操作端到端认证。换句话说服务器仍能看到谁在什么时候对哪个任务做了什么只是看不到任务内容。服务器侧还存在一个结构分类器用于防止意外明文上传packages/sync-core/src/encryption/transport-shape.ts 中的isEncryptedPayloadTransportShape()是一个零依赖的纯字符串检查要求 payload 是字符串、长度 4 的倍数、符合规范 base64 字符集无空白、无 base64url 字符、填充仅在末尾、解码后字节数不低于对应信封最小值。它只做形状检查而非密码学证明——足够长的 base64 明文也能通过——其目的是在服务器边界拒绝意外明文和畸形上传且不解码、不分配、不记录负载内容。第二层数据库文件加密——当前由基础设施层负责决策文档明确PostgreSQL 文件与普通数据库转储不被 SuperSync 加密。E2EE 的启用与否都不影响这一点——E2EE 加密的是上传到服务器之前的操作负载而数据库卷是另一回事。架构文档也确认加密的全量状态上传仍然是操作行但无法成为服务器可读的状态缓存服务器没有密钥普通明文数据的快照缓存优化对加密账户自动失效。当前部署的数据库形态可以从生产 Compose 文件确认packages/super-sync-server/docker-compose.yml 使用postgres:16-alpine通过postgres-data命名卷持久化数据没有任何加密卷、dm-crypt或文件级加密配置。数据保护完全落在宿主机的访问控制与托管环境上。第三层备份文件加密——独立的运维控制加密的数据库备份流同样独立于活动数据库文件加密。SuperSync 的备份策略是pg_dump定时导出见下文pg_dump输出是明文 SQL。备份加密与否是操作员自行决定的运维控制与数据库文件是否加密是两回事——即使将来启用了数据库文件加密也不等于备份文件自动加密反之亦然。决策文档给出的边界结论是不要因为部署了 E2EE 就认为 PostgreSQL 卷是加密的也不要因为备份文件做了加密就认为数据库文件加密了。操作员指南在无静态加密前提下如何保护数据库既然项目层面不做数据库文件加密决策的后果Consequences就是把责任明确交给部署方部署依赖访问控制和托管环境来保护数据库文件。需要保护的对象根据 packages/super-sync-server/docs/encryption-at-rest.md 的指引包括宿主机控制谁能登录、谁能以 root 操作。PostgreSQL 凭据POSTGRES_PASSWORD、DATABASE_URL等敏感环境变量从 env.example 复制到.env后应严格限制文件权限。文件系统数据库卷、应用数据目录。提供商快照provider snapshots很多 VPS 提供商会做磁盘快照快照同样包含明文数据库文件。备份位置备份目录、rclone 远端见下文。备份与恢复与明文数据库共存的工作流SuperSync 的备份体系在 packages/super-sync-server/docs/backup-and-recovery.md 中有完整文档。架构前提是客户端是数据权威来源clients are the source of truth服务器只是中继——每个客户端在本地 IndexedDB 中保有完整数据副本。这极大简化了灾难恢复只要有一个客户端设备存活所有数据都能恢复。备份脚本创建两类转储转储内容规模全量转储supersync_*.sql.gz完整数据库含全部操作活跃实例约 300MB账户专用转储supersync_accounts_*.sql.gz仅users与passkeys表极小1MB关键配置变量变量默认值说明BACKUP_DIR../backups备份文件存储目录RETENTION_DAYS14删除早于此天数的备份DB_CONTAINERsupersync-postgresDocker 容器名POSTGRES_USERsupersync数据库用户POSTGRES_DBsupersync数据库名RCLONE_REMOTE空可选的 rclone 异地上传远端推荐恢复路径是账户专用恢复accounts-only restore先恢复users passkeys让服务器同步数据从空开始客户端重连时缺口检测gap detection自动触发各客户端重新上传完整状态并收敛到一致状态。这样能避开部分恢复导致的SYNC_IMPORT_EXISTS冲突。全量恢复仅在所有客户端设备全部丢失时作为兜底使用。作为操作员请注意备份文件中包含的是明文数据包括用户邮箱与密码哈希、passkeys 以及全部操作负载——除非客户端启用了 E2EE。因此备份位置本身的保护优先级很高如需对备份加密应使用独立工具如gpg、openssl enc或加密的 rclone 远端这属于运维控制而非项目提供的功能。重新评估条件什么情况下才应重启数据库静态加密项目决策文档并非永久否决而是设定了严格的重新审视revisit条件只有持有**运维方所有operations-owned**的提案时才应重新考虑该决策提案必须包含支持所选机制的部署环境——例如能加载dm-crypt的 KVM 主机而不是 OpenVZ 容器在当前 Compose/数据库布局上经过测试的迁移与回滚流程启动boot、密钥轮换key rotation、备份与灾难恢复的完整程序监控与演练过的恢复测试restore test更新后的威胁模型清晰区分负载 E2EE、数据库文件加密、备份加密三层。文档指出的可行未来方向包括迁移到KVM 主机使用基础设施托管的磁盘加密如 LVM 加密卷、托管磁盘加密或改用提供静态加密的托管 PostgreSQL 服务managed PostgreSQL service。同时强调Git 历史中被退役的实现只能作为研究输入不能作为快速审批的捷径。归档 README 也重申任何未来的存储加密项目都需要在设计、迁移、回滚、启动、密钥轮换、备份与恢复流程上全新设计和演练。测试与验证现有行为有 E2E 覆盖虽然没有数据库静态加密但围绕明文数据生命周期的安全与恢复行为有自动化测试保障备份恢复场景由 e2e/tests/sync/supersync-server-backup-revert.spec.ts 覆盖包括服务器完全数据丢失后单客户端恢复全部数据、服务器回退到旧状态时客户端保留本地数据、账户专用恢复的多客户端收敛、以及混合加密/明文历史的失败关闭fail closed再恢复。加密传输形状分类器在 packages/sync-core/src/encryption/transport-shape.ts 的配套 spec 中与真实encrypt()输出交叉校验字节下限CI 还通过tools/generate-android-crypto-fixtures.mjs把新鲜加密输出喂给 Android Kotlin 测试验证跨端线格式一致见 packages/sync-core/src/encryption.ts 模块说明。服务器侧加密/明文相关的载荷审计与回归用例集中在 e2e/tests/sync/ 目录。此外仓库中还有一份关于清除历史明文同步数据的提案 packages/super-sync-server/docs/e2ee-legacy-data-eradication-plan.md它从另一个角度印证了本文的安全边界服务器仅通过isPayloadEncrypted标志与密文形状来区分加密/明文该标志本身是不带认证的因此计划中反复强调不能只信标志、必须做形状检查并规划了加密-only 上传闸门E2EE_REQUIRED与数据库 CHECK 约束兜底。这再次说明SuperSync 的加密保障体系是客户端 E2EE 服务器形状闸门 运维层存储保护的组合而不是数据库文件静态加密。小结把每层加密放到正确的位置总结这份 ADR 的核心要义项目决策SuperSync 不做项目自管理的 PostgreSQL 数据库文件加密LUKS 与 PostgreSQL TDE 均因生产 OpenVZ 环境不支持而退役归档于 packages/super-sync-server/archive/encryption-attempts-openvz-incompatible/。分层边界E2EE客户端负载加密元数据明文≠ 数据库文件加密未提供≠ 备份文件加密独立运维控制。三者必须分开评估谁都不能替代谁。操作员行动项保护宿主机、凭据、文件系统、快照与备份位置需要加密存储时在基础设施层KVM 磁盘加密或托管 PostgreSQL实现并在精确的生产拓扑上演练迁移、启动/解锁、备份、恢复、密钥轮换、监控与回滚后再宣称合规。重新评估门槛一份由运维方拥有的完整提案包含环境支持、可测试的迁移/回滚、启动与密钥轮换、备份与灾难恢复程序、监控与演练过的恢复测试以及分层清晰的更新威胁模型。【免费下载链接】super-productivitySuper Productivity is an advanced todo list app with integrated Timeboxing and time tracking capabilities. It also comes with integrations for Jira, GitLab, GitHub and Open Project.项目地址: https://gitcode.com/GitHub_Trending/su/super-productivity创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考