Bitwarden server 如何准备覆盖各加密模式与附件方案的测试 vault 数据验证客户端解密【免费下载链接】serverBitwarden infrastructure/backend (API, database, Docker, etc).项目地址: https://gitcode.com/GitHub_Trending/ser/serverBitwarden 服务端仓库自带一个数据库 Seederutil/Seeder它的encryption-modes预设可以一次灌入按历史客户端各个时代加密方式写入的 vault 数据cipher 加密分 user-keyCipher.Key为 null字段直接挂在 vault key 下和 cipher-key每个 cipher 有独立 key由 vault key 包裹两种附件分 v0无附件 key字节和文件名直接挂在 vault key 下、v1附件 key 由 vault key 包裹、v2附件 key 由 cipher key 包裹三档。当你需要验证某个客户端能否正确解密老版本和新版本写入的数据时跑一次这个预设然后登录它生成的账号用真实客户端打开 vault 和附件即可。适用环境本地开发库。Seeder 直接写数据库文档明确要求只在本地开发库上运行The Seeder writes directly to your database. Only run it against local development databases.。准备条件本地 Bitwarden 开发环境已可访问SeederUtility 连上你的开发库连接串来自bitwarden-seeder-utilityuser secrets能写入数据。运行 .NET 工具SeederUtility 的入口说明是Build and run from theutil/SeederUtilitydirectory即所有命令都在util/SeederUtility/下执行dotnet build dotnet run -- command [options]附件存储配置一致encryption-modes预设会带附件附件 blob 写入{globalSettings:attachment:baseDirectory}/{cipherId}/{attachmentId}。SeederUtility 必须能解析到一个可写的globalSettings:attachment:baseDirectory并且要让客户端能下载到附件它必须与运行中的 dev API 读取的目录是同一个。注意仓库自带的util/SeederUtility/appsettings.Development.json默认给的是globalSettings:attachment:connectionString为UseDevelopmentStoragetrueAzurite。如果你走本地目录方案需要在配置中提供globalSettings:attachment:baseDirectory覆盖并保证 dev API 侧指向同一目录——仓库文档只给出这一条约束具体配置入口以你本地环境的 appsettings/user secrets 为准。先用dotnet run -- preset --list确认individual.encryption-modes在预设清单中再执行播种。执行播种个人账户预设个人 vault 的主路径命令在util/SeederUtility/下dotnet run -- preset --name individual.encryption-modes这是 fixture 驱动播种同样的输入每次产生同样的数据关系账号邮箱固定为预设里的user.email字段。跑完得到一个Premium1GB个人账户登录encryptionmodesindividual.example密码asdfasdfasdfSeederUtility 中所有被播种用户默认使用这个密码可用--password覆盖。如果数据库里已经有过这个预设的数据、需要再播一份而不冲突加--mangle它会随机化 ID、邮箱和标识符实现测试隔离此时登录邮箱不再是上文的固定值以命令输出为准。可选分支同一 fixture 的组织 vault 版本如果你的解密验证要在共享组织 vault多人可见、走 collection 授权里做用同一个encryption-modesfixture 的组织预设dotnet run -- preset --name qa.paper-trail-partners-team它创建一个 Teams 计划的组织Paper Trail Partnersowner、admin、member 都在一个All-Access组里owner 能看到全部 34 个 cipher。登录trail.ownerpapertrail.example密码asdfasdfasdf。两个预设覆盖的加密模式完全一致差别只在个人库 vs 组织库、以及组织版把 cipher 轮转分配到十个 collection。播种后能得到什么两个预设都写入34 个 cipher覆盖全部 8 种 cipher 类型login、card、identity、secure note、SSH key、bank account、drivers license、passport并保证以下分支都被覆盖维度覆盖内容Cipher 加密user-key 与 cipher-key 两种且两种都同时出现在带附件和不带附件的 cipher 上附件方案v0、v1、v2 三档另有同时挂 v0 和 v1 两个附件的 cipher生命周期部分条目已归档、部分已软删除、个别两者皆是其中一部分仍带附件归档/删除日期是回填的对照项一个 user-key 和一个 cipher-key cipher各不带附件fixture 的不变式见 util/Seeder/README.mdcipher 和它的附件使用同一套策略——v2附件必须由cipherKeycipher 承载v0/v1附件必须由userKeycipher 承载。附件正文是Seeds/attachments/下的mock-seeder-data-*.txt/.pdf文件文档明确说 blobs decrypt end-to-end即正文解密后应能还原出这些文件内容。需要提醒的一点Seeder 产出的一切都是Encryption-V1AES-256-CBC-HMACtype-2 EncString。附件的v0/v1/v2只描述附件 key 的包裹方式和账户级别的 Encryption V1/V2 不是一回事Seeder 没有 XChaCha20/COSEEncryption V2路径。如果你的验证目标是 Encryption V2这个预设帮不上忙。结果验证确认数据入库SeederUtility 播种成功会打印执行结果--mangle运行时注意记录它输出的实际登录邮箱。客户端登录验证用上面的账号密码登录 Bitwarden 客户端打开 vault应能看到 34 个 cipher逐项打开重点核对cipher-key 条目带 per-cipher key 的与 user-key 条目都能正常显示明文字段带附件的条目能下载附件且 v0/v1/v2 三种方案的附件都能还原出mock-seeder-data-*文本/PDF 内容归档与软删除条目仍可按客户端的对应视图如回收站找到且它们上面的附件依旧可解密。判断标准Seeder 通过 Rust SDK 的 FFI 加密路径写入CipherViewDto → encrypt_fields → EncryptedCipherDto → Server Format文档给出的结论是 This ensures seeded data can be decrypted and displayed in the actual Bitwarden clients。所以只要客户端尤其是你正在验证的老版本或新版本客户端能把上述字段和附件正文解密显示出来就完成了一次端到端验证任何一个分支某档附件、某类 cipher显示失败就是待排查的解密分支。限制与已知边界只跑本地开发库Seeder 直接写数据库不要指向生产或共享环境。重复播种会冲突不加--mangle的固定邮箱预设第二次运行会撞上已有账号需要多次播种时加--mangle。附件目录不一致时客户端下不到附件Seeder 写的目录和 dev API 读的目录不同数据库里有附件记录但客户端下载拿不到 blob。播种前确认两边配置指向同一baseDirectory。不含 Encryption V2见上文说明附件 v0/v1/v2 轴不产生任何 XChaCha20/COSE 数据。延伸文档组织版场景util/Seeder/Seeds/docs/scenarios/encryption-modes-org.md预设总目录含全部预设和登录邮箱清单util/Seeder/Seeds/docs/presets.mdCLI 完整参数util/SeederUtility/README.md场景索引util/Seeder/Seeds/docs/scenarios/README.md【免费下载链接】serverBitwarden infrastructure/backend (API, database, Docker, etc).项目地址: https://gitcode.com/GitHub_Trending/ser/server创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Bitwarden server 如何准备覆盖各加密模式与附件方案的测试 vault 数据验证客户端解密
Bitwarden server 如何准备覆盖各加密模式与附件方案的测试 vault 数据验证客户端解密【免费下载链接】serverBitwarden infrastructure/backend (API, database, Docker, etc).项目地址: https://gitcode.com/GitHub_Trending/ser/serverBitwarden 服务端仓库自带一个数据库 Seederutil/Seeder它的encryption-modes预设可以一次灌入按历史客户端各个时代加密方式写入的 vault 数据cipher 加密分 user-keyCipher.Key为 null字段直接挂在 vault key 下和 cipher-key每个 cipher 有独立 key由 vault key 包裹两种附件分 v0无附件 key字节和文件名直接挂在 vault key 下、v1附件 key 由 vault key 包裹、v2附件 key 由 cipher key 包裹三档。当你需要验证某个客户端能否正确解密老版本和新版本写入的数据时跑一次这个预设然后登录它生成的账号用真实客户端打开 vault 和附件即可。适用环境本地开发库。Seeder 直接写数据库文档明确要求只在本地开发库上运行The Seeder writes directly to your database. Only run it against local development databases.。准备条件本地 Bitwarden 开发环境已可访问SeederUtility 连上你的开发库连接串来自bitwarden-seeder-utilityuser secrets能写入数据。运行 .NET 工具SeederUtility 的入口说明是Build and run from theutil/SeederUtilitydirectory即所有命令都在util/SeederUtility/下执行dotnet build dotnet run -- command [options]附件存储配置一致encryption-modes预设会带附件附件 blob 写入{globalSettings:attachment:baseDirectory}/{cipherId}/{attachmentId}。SeederUtility 必须能解析到一个可写的globalSettings:attachment:baseDirectory并且要让客户端能下载到附件它必须与运行中的 dev API 读取的目录是同一个。注意仓库自带的util/SeederUtility/appsettings.Development.json默认给的是globalSettings:attachment:connectionString为UseDevelopmentStoragetrueAzurite。如果你走本地目录方案需要在配置中提供globalSettings:attachment:baseDirectory覆盖并保证 dev API 侧指向同一目录——仓库文档只给出这一条约束具体配置入口以你本地环境的 appsettings/user secrets 为准。先用dotnet run -- preset --list确认individual.encryption-modes在预设清单中再执行播种。执行播种个人账户预设个人 vault 的主路径命令在util/SeederUtility/下dotnet run -- preset --name individual.encryption-modes这是 fixture 驱动播种同样的输入每次产生同样的数据关系账号邮箱固定为预设里的user.email字段。跑完得到一个Premium1GB个人账户登录encryptionmodesindividual.example密码asdfasdfasdfSeederUtility 中所有被播种用户默认使用这个密码可用--password覆盖。如果数据库里已经有过这个预设的数据、需要再播一份而不冲突加--mangle它会随机化 ID、邮箱和标识符实现测试隔离此时登录邮箱不再是上文的固定值以命令输出为准。可选分支同一 fixture 的组织 vault 版本如果你的解密验证要在共享组织 vault多人可见、走 collection 授权里做用同一个encryption-modesfixture 的组织预设dotnet run -- preset --name qa.paper-trail-partners-team它创建一个 Teams 计划的组织Paper Trail Partnersowner、admin、member 都在一个All-Access组里owner 能看到全部 34 个 cipher。登录trail.ownerpapertrail.example密码asdfasdfasdf。两个预设覆盖的加密模式完全一致差别只在个人库 vs 组织库、以及组织版把 cipher 轮转分配到十个 collection。播种后能得到什么两个预设都写入34 个 cipher覆盖全部 8 种 cipher 类型login、card、identity、secure note、SSH key、bank account、drivers license、passport并保证以下分支都被覆盖维度覆盖内容Cipher 加密user-key 与 cipher-key 两种且两种都同时出现在带附件和不带附件的 cipher 上附件方案v0、v1、v2 三档另有同时挂 v0 和 v1 两个附件的 cipher生命周期部分条目已归档、部分已软删除、个别两者皆是其中一部分仍带附件归档/删除日期是回填的对照项一个 user-key 和一个 cipher-key cipher各不带附件fixture 的不变式见 util/Seeder/README.mdcipher 和它的附件使用同一套策略——v2附件必须由cipherKeycipher 承载v0/v1附件必须由userKeycipher 承载。附件正文是Seeds/attachments/下的mock-seeder-data-*.txt/.pdf文件文档明确说 blobs decrypt end-to-end即正文解密后应能还原出这些文件内容。需要提醒的一点Seeder 产出的一切都是Encryption-V1AES-256-CBC-HMACtype-2 EncString。附件的v0/v1/v2只描述附件 key 的包裹方式和账户级别的 Encryption V1/V2 不是一回事Seeder 没有 XChaCha20/COSEEncryption V2路径。如果你的验证目标是 Encryption V2这个预设帮不上忙。结果验证确认数据入库SeederUtility 播种成功会打印执行结果--mangle运行时注意记录它输出的实际登录邮箱。客户端登录验证用上面的账号密码登录 Bitwarden 客户端打开 vault应能看到 34 个 cipher逐项打开重点核对cipher-key 条目带 per-cipher key 的与 user-key 条目都能正常显示明文字段带附件的条目能下载附件且 v0/v1/v2 三种方案的附件都能还原出mock-seeder-data-*文本/PDF 内容归档与软删除条目仍可按客户端的对应视图如回收站找到且它们上面的附件依旧可解密。判断标准Seeder 通过 Rust SDK 的 FFI 加密路径写入CipherViewDto → encrypt_fields → EncryptedCipherDto → Server Format文档给出的结论是 This ensures seeded data can be decrypted and displayed in the actual Bitwarden clients。所以只要客户端尤其是你正在验证的老版本或新版本客户端能把上述字段和附件正文解密显示出来就完成了一次端到端验证任何一个分支某档附件、某类 cipher显示失败就是待排查的解密分支。限制与已知边界只跑本地开发库Seeder 直接写数据库不要指向生产或共享环境。重复播种会冲突不加--mangle的固定邮箱预设第二次运行会撞上已有账号需要多次播种时加--mangle。附件目录不一致时客户端下不到附件Seeder 写的目录和 dev API 读的目录不同数据库里有附件记录但客户端下载拿不到 blob。播种前确认两边配置指向同一baseDirectory。不含 Encryption V2见上文说明附件 v0/v1/v2 轴不产生任何 XChaCha20/COSE 数据。延伸文档组织版场景util/Seeder/Seeds/docs/scenarios/encryption-modes-org.md预设总目录含全部预设和登录邮箱清单util/Seeder/Seeds/docs/presets.mdCLI 完整参数util/SeederUtility/README.md场景索引util/Seeder/Seeds/docs/scenarios/README.md【免费下载链接】serverBitwarden infrastructure/backend (API, database, Docker, etc).项目地址: https://gitcode.com/GitHub_Trending/ser/server创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考