Super Productivity SuperSync 数据库静止加密现状与安全边界全解析【免费下载链接】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本文基于 Super Productivity 仓库中packages/super-sync-server/docs/encryption-at-rest.md2026-07-29 验证及其配套决策文档、架构文档与服务端源码整理而成。核心结论先行当前 SuperSync 部署并不对 PostgreSQL 数据库文件与数据卷提供项目自管的静止加密encryption at rest历史上尝试过的 LUKS 与 PostgreSQL TDE 方案均因生产环境OpenVZ无法运行而被退役。本文将从为什么没有加密、哪些数据被保护/不被保护、E2EE 与静止加密的区别、运维人员该怎么办四个层面讲清这一安全边界让部署者能准确判断自身部署的真实加密状态并掌握备份加密、客户端 E2EE、恢复流程等配套手段的用法。现状结论SuperSync 不提供数据库静止加密SuperSync 服务器是一个基于 PostgreSQL 的认证中继、排序服务与上传冲突门卫承载着 Super Productivity 的多端同步协议。关于数据库文件在磁盘上是否加密packages/super-sync-server/docs/encryption-at-rest.md给出的状态非常明确Status:Not provided by the current SuperSync deployment也就是说PostgreSQL 数据文件live database files不由本项目加密**数据卷database volume**同样不在项目加密范围之内项目当前不提供、也不支持一条可运行的 LUKS 或 PostgreSQL TDE透明数据加密部署路径。仓库根目录的决策文档 docs/supersync-encryption-at-rest-decision.md状态 Accepted决策日期 2026-01进一步给出了决策全貌本仓库不提供、不支持 LUKS 或 PostgreSQL 透明数据加密的部署路径此前实现的工具链已被整体退役。为什么OpenVZ 环境下的两次失败尝试这并非疏漏而是一次基于生产环境的实测决策。仓库文档明确记录了两次被退役的实现尝试尝试方案依赖能力失败原因LUKS 磁盘加密工具链宿主内核的dm-crypt等能力生产环境的 OpenVZ 虚拟化环境不提供这些内核能力无法运行PostgreSQL TDE透明数据加密实验数据库层的加密内核模块同样在 OpenVZ 生产环境中不可行关键设计原则与其在活动部署路径中保留一个无法测试的安全机制不如将其整体退役。因此这两个方案最终被移除而不是以看似存在但从未验证的状态留在代码库中。被移除的具体内容存放在归档目录 packages/super-sync-server/archive/encryption-attempts-openvz-incompatible/其中 README.md 记录了历史提交指纹LUKS 工具链起始于cb2e2e65a2其测试/迁移支持在c8bce3c8cf安全跟进提交为0573468797LUKS 方案的退役与归档提交为e050eb99faPostgreSQL TDE 实验在1fdcc9a906落地、在3a58044826回退。归档中只保留了说明性文档README可执行的 Compose override、脚本与 runbook 均已移除避免被误认为受支持的生产路径Git 历史仍保留全部实现仅供取证与 forensic 参考。哪些数据被加密、哪些没有逐项核对encryption-at-rest.md用一条清单明确了加密边界仓库源码与配套文档可以逐项印证数据/能力是否加密依据在线 PostgreSQL 数据文件否文档状态声明 决策文档普通数据库 dump否数据库层无自动 E2EE文档明确说明客户端启用 E2EE 后的操作 payload是客户端加密见下节加密架构文档同步路由与因果元数据否明文服务端架构文档加密的备份文件流是独立的运维控制与在线库加密无关备份与灾备指南可以看到备份加密与在线数据库加密是两个完全不同的控制面前者只保护备份产物并不加密在线数据库后者才是通常意义的静态数据加密。运维者不要把两者混为一谈。深入解读客户端 E2EE 只加密 payloadSuperSync 的端到端加密是客户端特性与数据库静止加密完全分离。从 docs/sync-and-op-log/supersync-encryption-architecture.md 可见其技术选型AES-256-GCM认证加密同时提供机密性与完整性Argon2id密钥派生CPU/内存困难型抗暴力破解加解密全部发生在客户端浏览器 WebCrypto服务器不持有任何密钥。服务端如何识别加密操作服务端通过Operation接口上的isPayloadEncrypted布尔标志识别加密操作。在 sync.types.ts 中可以看到该字段的定义其注释明确写着True if payload is E2E encrypted。该标志同时是数据库中的真实列isPayloadEncrypted并出现在 DUPLICATE_OP_SELECT 的去重比较字段集中——即使 payload 是密文去重仍可基于元数据完成。从源码结构看服务端对加密 payload 的处理是透传但校验结构validatePayload 对字符串形态的 payload即加密后的 base64 密文直接放行注释明确Encrypted payloads are strings - allow them加密的 DEL 操作 payload 也允许为字符串服务端校验的仍是操作标识符、操作类型、大小、时间戳、向量时钟、schema 版本、配额与冲突元数据等明文信封validation.service.ts 中只有!op.isPayloadEncrypted的操作才会走明文 payload 的额外校验路径。E2EE 边界加密了什么没加密什么服务端架构文档 用一段话精确划定了 E2EE 边界启用 E2EE 时只有operation.payload在客户端加密。服务器无密钥将其作为不透明值存储。路由与因果元数据——包括操作 ID 与客户端 ID、action/操作类型、实体 ID、向量时钟、时间戳、schema 版本、导入原因与加密标志——保持明文用于校验、排序与冲突检测。重要的安全推论payload 的 AES-GCM 认证标签并不认证明文元数据。因此 E2EE 提供的是payload 机密性与完整性而非元数据机密性也不是对完整操作的端到端真实性。一个任务内容完全加密的账号其哪些实体在何时被谁修改过这类元数据对服务器仍是可见的。E2EE 对服务器侧能力也有实际约束这在架构文档中多处体现快照缓存失效加密的全量上传仍是 operation但无法成为服务器可读的状态缓存snapshot cache 是明文数据的可选优化服务器侧恢复不可用当重放范围包含加密操作时服务器无法生成 restore 状态generateSnapshotAtSeq会抛出EncryptedOpsNotSupportedError清理策略不依赖明文默认保留期为 45 天基于因果全量边界的前缀清理对加密历史同样有效边界来自操作流本身无需快照游标。运维指南在无静止加密前提下保护数据既然项目不提供数据库静止加密运维者必须把宿主、凭据、文件系统、快照与备份位置都当作敏感基础设施来保护。encryption-at-rest.md给出的运维指引可以归纳为三条保护宿主与凭据PostgreSQL 凭据、文件系统、服务商快照、备份位置均属于敏感资产按最小权限原则管理在受支持的基础设施层提供加密如果业务确实需要静态加密应在部署环境支持的基础设施层提供——例如具备合适虚拟化的 KVM 主机上的宿主级磁盘加密或直接选用提供静态加密的托管数据库服务宣称有加密之前必须实测在真实生产拓扑上演练迁移、启动/解锁、备份、恢复、密钥轮换、监控与回滚全流程。不能仅凭加密算法或归档实现就推断合规性。运维者的三条保护路径对比保护手段保护对象是否由本项目提供说明客户端 E2EE服务器上的操作 payload 内容是客户端特性服务器不可读 payload但元数据明文加密备份流 / 安全备份备份产物备份流程受维护加密是独立运维控制见下节备份与恢复基础设施层磁盘加密在线数据文件否需部署环境支持如 KVM 宿主加密、托管 PG 服务备份与恢复一个独立的控制面加密的备份文件流与在线数据库加密无关但它是当前受维护的恢复程序。详见 备份与灾备指南这里提炼与安全边界直接相关的要点恢复模型的根基Super Productivity 使用追加式操作日志同步所有客户端桌面、移动、Web在本地 IndexedDB 保存完整数据副本客户端才是数据真相来源服务器只是中继。因此只要有一个客户端存活全部数据都可恢复——这与传统服务器权威系统有本质区别。备份内容矩阵数据存放位置备份原因用户账户邮箱、密码哈希仅服务器无此则无法认证PasskeyWebAuthn 凭据仅服务器无法重新生成操作日志服务器 所有客户端客户端全灭时的最后手段任务/项目/标签数据由操作日志派生客户端从 ops 重建每日备份脚本packages/super-sync-server/scripts/backup.sh生成两个 dump全量 dumpsupersync_*.sql.gz活动实例约 300MB仅账户 dumpsupersync_accounts_*.sql.gz仅users与passkeys表1MB。脚本源码backup.sh印证了文档中的配置项BACKUP_DIR默认../backups且chmod 700、RETENTION_DAYS默认 14、DB_CONTAINER默认supersync-postgres、POSTGRES_USER/POSTGRES_DB默认supersync、RCLONE_REMOTE默认空配合--upload做异地上传。推荐的恢复路径是仅账户恢复恢复 accounts dump 后客户端重连时自动触发 gap detection 并重新上传各自完整状态多客户端收敛到一致状态。该场景由 e2e 测试e2e/tests/sync/supersync-server-backup-revert.spec.ts覆盖。全量恢复仅在所有客户端全部丢失时才作为兜底使用。加密账号的恢复特殊点加密账号不能使用应用内 Restore from History服务器无法解密 payload若遭遇单账号被清空优先使用客户端的本地恢复点Settings → Sync Backup → Import/Export → Browse backups。服务器侧的scripts/recover-user.ts可重放用户操作日志到指定serverSeq并解密生成可导入的AppDataCompleteJSON只读数据库、通过RECOVER_ENCRYPT_KEY或--key-file提供密钥但需注意其状态标注为尚未针对真实加密数据端到端验证。何时会重新考虑可回归条件与未来方向决策文档 给出了明确的重新考虑条件——只有在运维方提出包含以下全部要素的提案时才应重新评估该决策一个支持所选机制的部署环境这是本次退役的直接教训在当前 Compose/数据库布局上实测过的迁移与回滚完整的启动、密钥轮换、备份与灾难恢复流程监控与一次实际执行的恢复测试一份更新后的威胁模型清晰区分 payload E2EE、数据库文件加密与备份加密三个层面。文档点名的两个可行未来方向是迁移到支持基础设施托管磁盘加密的 KVM 宿主或使用提供静态加密的托管 PostgreSQL 服务。归档在 Git 历史中的旧实现是研究输入而非通往批准的捷径。结语准确理解安全边界是合规的第一步Super Productivity 的 SuperSync 服务器在静止加密上的立场是清晰且经得起推敲的项目自身不加密 PostgreSQL 数据文件因为无法在 OpenVZ 生产环境中运行 LUKS/TDE它把 payload 机密性交给客户端 E2EE把文件级保护交给部署环境的基础设施层把可恢复性交给客户端为真相源的备份体系。对部署者而言最需要记住的三件事是不要因为仓库里存在曾经实现过加密的历史就宣称部署具备静态加密——归档实现是历史证据不是生产能力需要服务器端盲内容机密性就启用客户端 E2EEAES-256-GCM Argon2id但要接受元数据仍为明文需要文件级静态加密就在部署环境支持的层面提供宿主加密或托管数据库并在真实拓扑上完整演练迁移、恢复与密钥轮换之后再下结论。深入阅读encryption-at-rest.md关联文档原文supersync-encryption-at-rest-decision.mdADR 决策文档archived LUKS/TDE 尝试归档说明SuperSync 服务端架构含 E2EE 边界SuperSync E2EE 加密架构备份与灾难恢复指南备份脚本实现服务端 Operation 类型与 payload 校验【免费下载链接】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 数据库静止加密现状与安全边界全解析
Super Productivity SuperSync 数据库静止加密现状与安全边界全解析【免费下载链接】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本文基于 Super Productivity 仓库中packages/super-sync-server/docs/encryption-at-rest.md2026-07-29 验证及其配套决策文档、架构文档与服务端源码整理而成。核心结论先行当前 SuperSync 部署并不对 PostgreSQL 数据库文件与数据卷提供项目自管的静止加密encryption at rest历史上尝试过的 LUKS 与 PostgreSQL TDE 方案均因生产环境OpenVZ无法运行而被退役。本文将从为什么没有加密、哪些数据被保护/不被保护、E2EE 与静止加密的区别、运维人员该怎么办四个层面讲清这一安全边界让部署者能准确判断自身部署的真实加密状态并掌握备份加密、客户端 E2EE、恢复流程等配套手段的用法。现状结论SuperSync 不提供数据库静止加密SuperSync 服务器是一个基于 PostgreSQL 的认证中继、排序服务与上传冲突门卫承载着 Super Productivity 的多端同步协议。关于数据库文件在磁盘上是否加密packages/super-sync-server/docs/encryption-at-rest.md给出的状态非常明确Status:Not provided by the current SuperSync deployment也就是说PostgreSQL 数据文件live database files不由本项目加密**数据卷database volume**同样不在项目加密范围之内项目当前不提供、也不支持一条可运行的 LUKS 或 PostgreSQL TDE透明数据加密部署路径。仓库根目录的决策文档 docs/supersync-encryption-at-rest-decision.md状态 Accepted决策日期 2026-01进一步给出了决策全貌本仓库不提供、不支持 LUKS 或 PostgreSQL 透明数据加密的部署路径此前实现的工具链已被整体退役。为什么OpenVZ 环境下的两次失败尝试这并非疏漏而是一次基于生产环境的实测决策。仓库文档明确记录了两次被退役的实现尝试尝试方案依赖能力失败原因LUKS 磁盘加密工具链宿主内核的dm-crypt等能力生产环境的 OpenVZ 虚拟化环境不提供这些内核能力无法运行PostgreSQL TDE透明数据加密实验数据库层的加密内核模块同样在 OpenVZ 生产环境中不可行关键设计原则与其在活动部署路径中保留一个无法测试的安全机制不如将其整体退役。因此这两个方案最终被移除而不是以看似存在但从未验证的状态留在代码库中。被移除的具体内容存放在归档目录 packages/super-sync-server/archive/encryption-attempts-openvz-incompatible/其中 README.md 记录了历史提交指纹LUKS 工具链起始于cb2e2e65a2其测试/迁移支持在c8bce3c8cf安全跟进提交为0573468797LUKS 方案的退役与归档提交为e050eb99faPostgreSQL TDE 实验在1fdcc9a906落地、在3a58044826回退。归档中只保留了说明性文档README可执行的 Compose override、脚本与 runbook 均已移除避免被误认为受支持的生产路径Git 历史仍保留全部实现仅供取证与 forensic 参考。哪些数据被加密、哪些没有逐项核对encryption-at-rest.md用一条清单明确了加密边界仓库源码与配套文档可以逐项印证数据/能力是否加密依据在线 PostgreSQL 数据文件否文档状态声明 决策文档普通数据库 dump否数据库层无自动 E2EE文档明确说明客户端启用 E2EE 后的操作 payload是客户端加密见下节加密架构文档同步路由与因果元数据否明文服务端架构文档加密的备份文件流是独立的运维控制与在线库加密无关备份与灾备指南可以看到备份加密与在线数据库加密是两个完全不同的控制面前者只保护备份产物并不加密在线数据库后者才是通常意义的静态数据加密。运维者不要把两者混为一谈。深入解读客户端 E2EE 只加密 payloadSuperSync 的端到端加密是客户端特性与数据库静止加密完全分离。从 docs/sync-and-op-log/supersync-encryption-architecture.md 可见其技术选型AES-256-GCM认证加密同时提供机密性与完整性Argon2id密钥派生CPU/内存困难型抗暴力破解加解密全部发生在客户端浏览器 WebCrypto服务器不持有任何密钥。服务端如何识别加密操作服务端通过Operation接口上的isPayloadEncrypted布尔标志识别加密操作。在 sync.types.ts 中可以看到该字段的定义其注释明确写着True if payload is E2E encrypted。该标志同时是数据库中的真实列isPayloadEncrypted并出现在 DUPLICATE_OP_SELECT 的去重比较字段集中——即使 payload 是密文去重仍可基于元数据完成。从源码结构看服务端对加密 payload 的处理是透传但校验结构validatePayload 对字符串形态的 payload即加密后的 base64 密文直接放行注释明确Encrypted payloads are strings - allow them加密的 DEL 操作 payload 也允许为字符串服务端校验的仍是操作标识符、操作类型、大小、时间戳、向量时钟、schema 版本、配额与冲突元数据等明文信封validation.service.ts 中只有!op.isPayloadEncrypted的操作才会走明文 payload 的额外校验路径。E2EE 边界加密了什么没加密什么服务端架构文档 用一段话精确划定了 E2EE 边界启用 E2EE 时只有operation.payload在客户端加密。服务器无密钥将其作为不透明值存储。路由与因果元数据——包括操作 ID 与客户端 ID、action/操作类型、实体 ID、向量时钟、时间戳、schema 版本、导入原因与加密标志——保持明文用于校验、排序与冲突检测。重要的安全推论payload 的 AES-GCM 认证标签并不认证明文元数据。因此 E2EE 提供的是payload 机密性与完整性而非元数据机密性也不是对完整操作的端到端真实性。一个任务内容完全加密的账号其哪些实体在何时被谁修改过这类元数据对服务器仍是可见的。E2EE 对服务器侧能力也有实际约束这在架构文档中多处体现快照缓存失效加密的全量上传仍是 operation但无法成为服务器可读的状态缓存snapshot cache 是明文数据的可选优化服务器侧恢复不可用当重放范围包含加密操作时服务器无法生成 restore 状态generateSnapshotAtSeq会抛出EncryptedOpsNotSupportedError清理策略不依赖明文默认保留期为 45 天基于因果全量边界的前缀清理对加密历史同样有效边界来自操作流本身无需快照游标。运维指南在无静止加密前提下保护数据既然项目不提供数据库静止加密运维者必须把宿主、凭据、文件系统、快照与备份位置都当作敏感基础设施来保护。encryption-at-rest.md给出的运维指引可以归纳为三条保护宿主与凭据PostgreSQL 凭据、文件系统、服务商快照、备份位置均属于敏感资产按最小权限原则管理在受支持的基础设施层提供加密如果业务确实需要静态加密应在部署环境支持的基础设施层提供——例如具备合适虚拟化的 KVM 主机上的宿主级磁盘加密或直接选用提供静态加密的托管数据库服务宣称有加密之前必须实测在真实生产拓扑上演练迁移、启动/解锁、备份、恢复、密钥轮换、监控与回滚全流程。不能仅凭加密算法或归档实现就推断合规性。运维者的三条保护路径对比保护手段保护对象是否由本项目提供说明客户端 E2EE服务器上的操作 payload 内容是客户端特性服务器不可读 payload但元数据明文加密备份流 / 安全备份备份产物备份流程受维护加密是独立运维控制见下节备份与恢复基础设施层磁盘加密在线数据文件否需部署环境支持如 KVM 宿主加密、托管 PG 服务备份与恢复一个独立的控制面加密的备份文件流与在线数据库加密无关但它是当前受维护的恢复程序。详见 备份与灾备指南这里提炼与安全边界直接相关的要点恢复模型的根基Super Productivity 使用追加式操作日志同步所有客户端桌面、移动、Web在本地 IndexedDB 保存完整数据副本客户端才是数据真相来源服务器只是中继。因此只要有一个客户端存活全部数据都可恢复——这与传统服务器权威系统有本质区别。备份内容矩阵数据存放位置备份原因用户账户邮箱、密码哈希仅服务器无此则无法认证PasskeyWebAuthn 凭据仅服务器无法重新生成操作日志服务器 所有客户端客户端全灭时的最后手段任务/项目/标签数据由操作日志派生客户端从 ops 重建每日备份脚本packages/super-sync-server/scripts/backup.sh生成两个 dump全量 dumpsupersync_*.sql.gz活动实例约 300MB仅账户 dumpsupersync_accounts_*.sql.gz仅users与passkeys表1MB。脚本源码backup.sh印证了文档中的配置项BACKUP_DIR默认../backups且chmod 700、RETENTION_DAYS默认 14、DB_CONTAINER默认supersync-postgres、POSTGRES_USER/POSTGRES_DB默认supersync、RCLONE_REMOTE默认空配合--upload做异地上传。推荐的恢复路径是仅账户恢复恢复 accounts dump 后客户端重连时自动触发 gap detection 并重新上传各自完整状态多客户端收敛到一致状态。该场景由 e2e 测试e2e/tests/sync/supersync-server-backup-revert.spec.ts覆盖。全量恢复仅在所有客户端全部丢失时才作为兜底使用。加密账号的恢复特殊点加密账号不能使用应用内 Restore from History服务器无法解密 payload若遭遇单账号被清空优先使用客户端的本地恢复点Settings → Sync Backup → Import/Export → Browse backups。服务器侧的scripts/recover-user.ts可重放用户操作日志到指定serverSeq并解密生成可导入的AppDataCompleteJSON只读数据库、通过RECOVER_ENCRYPT_KEY或--key-file提供密钥但需注意其状态标注为尚未针对真实加密数据端到端验证。何时会重新考虑可回归条件与未来方向决策文档 给出了明确的重新考虑条件——只有在运维方提出包含以下全部要素的提案时才应重新评估该决策一个支持所选机制的部署环境这是本次退役的直接教训在当前 Compose/数据库布局上实测过的迁移与回滚完整的启动、密钥轮换、备份与灾难恢复流程监控与一次实际执行的恢复测试一份更新后的威胁模型清晰区分 payload E2EE、数据库文件加密与备份加密三个层面。文档点名的两个可行未来方向是迁移到支持基础设施托管磁盘加密的 KVM 宿主或使用提供静态加密的托管 PostgreSQL 服务。归档在 Git 历史中的旧实现是研究输入而非通往批准的捷径。结语准确理解安全边界是合规的第一步Super Productivity 的 SuperSync 服务器在静止加密上的立场是清晰且经得起推敲的项目自身不加密 PostgreSQL 数据文件因为无法在 OpenVZ 生产环境中运行 LUKS/TDE它把 payload 机密性交给客户端 E2EE把文件级保护交给部署环境的基础设施层把可恢复性交给客户端为真相源的备份体系。对部署者而言最需要记住的三件事是不要因为仓库里存在曾经实现过加密的历史就宣称部署具备静态加密——归档实现是历史证据不是生产能力需要服务器端盲内容机密性就启用客户端 E2EEAES-256-GCM Argon2id但要接受元数据仍为明文需要文件级静态加密就在部署环境支持的层面提供宿主加密或托管数据库并在真实拓扑上完整演练迁移、恢复与密钥轮换之后再下结论。深入阅读encryption-at-rest.md关联文档原文supersync-encryption-at-rest-decision.mdADR 决策文档archived LUKS/TDE 尝试归档说明SuperSync 服务端架构含 E2EE 边界SuperSync E2EE 加密架构备份与灾难恢复指南备份脚本实现服务端 Operation 类型与 payload 校验【免费下载链接】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），仅供参考