协同办公密码学【免费下载链接】tutanotaTuta is an email service with a strong focus on security and privacy that lets you encrypt emails, contacts and calendar entries on all your devices.项目地址https://gitcode.com/gh_mirrors/tu/tutanota点击查看免费下载本文基于开源仓库 gh_mirrors/tu/tutanota 的 doc/HACKING.md 编写。Tuta 是一款以安全与隐私为核心的邮件服务可对邮件、联系人与日历条目进行端到端加密。本指南将带你完整梳理 Tuta 客户端的仓库布局、线程模型与消息通信机制、Mithril 组件编写规范、网络与实体更新链路并给出 Web / 桌面 / Android / iOS 的构建步骤、测试命令以及保证包体健康的分块Chunking规则。读完本文你将能够在本地把 Tuta 客户端跑起来理解其主线程 Worker 原生层的协作方式并为后续开发与调试建立完整地图。仓库基本结构一张目录地图Tuta 客户端仓库的顶层布局清晰地划分了公共代码与平台专属代码两个维度src/承载共享逻辑与桌面客户端移动端则各自独立成目录路径职责src公共部分与桌面客户端代码app-androidAndroid 专属代码mail / calendar / drive 三个模块app-iosiOS 专属代码tutanota / calendar / drive 三个 target 及扩展libsvendor 依赖目录包含非压缩与压缩两种形态的第三方库由于安全敏感每次升级都会人工审查版本间的 difftest测试代码TypeScript 测试套件位于 test/testsandroid.js构建 Android 应用的脚本make.js构建开发debug版本的脚本desktop.js构建桌面客户端 release 版本的脚本webapp.js构建 Web 应用 release 版本的脚本tutao-pub.pem用于校验桌面客户端签名的公钥原文档还提到resources/多为内嵌进代码的图片资源以及位于app-android内的fdroid-metadata-workaround链接由于 Android 工程不在仓库根目录F-Droid 无法直接找到元数据此链接用于绕开该问题待 F-Droid 修复后可移除这两者在当前仓库快照中未包含阅读时以原文档说明为准。仓库顶层还依赖三个 Git 子模块见 .gitmoduleslibs/webassembly/phc-winner-argon2Argon2 密码散列实现、libs/webassembly/liboqs开源量子安全算法库用于 Kyber 后量子加密、libs/Signal-FTS5-Extension全文搜索的 FTS5 扩展。克隆后必须初始化这些子模块才能完成构建。代码结构三线程模型与模块划分Web 部分被拆成三个角色client主线程、worker工作线程与common共享代码。src/中除了api目录之外其余代码都面向 GUI 与系统交互api目录则集中了服务端通信、加密、索引等核心逻辑——这也是为什么加密与网络相关代码大多以Facade形式存在的原因。整体架构可参考仓库自带的架构总览图术语表Glossary读懂 Tuta 的命名约定阅读源码前先掌握这套后缀约定它决定了每个类在系统中的位置与职责术语含义SomethingView应用中的大块视图与 URL 对应如mail、contact、settings、searchSomethingListView以列表形式展示事物的组件通常位于第二列SomethingViewer展示单个元素的组件如选中的邮件或联系人SomethingModel某部分应用的逻辑位于主线程部分SomethingController负责记账或通用操作但不绑定具体 UI 部分的组件SomethingFacade某单一领域的逻辑位于 api 部分SomethingApp与原生部分通信、在特定领域执行任务的组件app更大的领域结构目前有管理账户的systemapp 与处理邮件/联系人的tutanotaappEntity与服务端数据库实体对应的对象TypeModel描述实体类型的模型TypeRef小型对象用于标识实体是哪一个并能在需要时定位TypeModel以 Worker 侧暴露的能力为例WorkerImpl.ts 中定义的WorkerInterface罗列了loginFacade、mailFacade、calendarFacade、driveFacade、searchFacade、cryptoFacade、sqlCipherFacade、eventBus等数十个门面基本印证了一个领域一个 Facade的组织方式。通信机制MessageDispatcher、WorkerClient 与 NativeInterfaceWorker、主线程与各 app 之间通过消息通信协议定义在 MessageDispatcher.ts客户端向 Worker 发送WorkerRequestWorker 以WorkerResponse或WorkerError应答Worker 向客户端发送ClientCommands客户端直接执行无需回包。MessageDispatcher是这套远程调用的核心。从源码看它的工作机制是postRequest()为每个请求生成自增 idmakeRequestIdGenerator(prefix)前缀如main-worker、worker-main并把回调存入_messages表handleMessage()根据消息类型分发response解析对应请求、requestError拒绝对应请求、request则查找注册的命令处理器并执行——源码中特别约定每个暴露的方法必须返回 Promise否则直接抛错以尽早暴露契约违规MessageDispatcher.ts。客户端侧的实现是 WorkerClient.ts它在浏览器中以new Worker(/worker-bootstrap.js, { type: module })启动 Worker并通过WebWorkerTransport桥接MessageDispatcher在Test模式下则跳过真实 Worker直接把 Worker 队列与客户端队列对接方便 Node 环境跑测试。它向 Worker 注册了execNative、error、facade等命令WorkerClient.ts。Worker 侧由 WorkerImpl.ts 实现原文档指向的src/applications/common/api/worker/WorkerImpl.ts已在重构后迁移至 mail-app 目录。它实现了NativeInterface同样持有MessageDispatcher并通过initLocator()装配全部 Facade 与索引器Indexer、SearchFacade 等。原生代码则通过 NativeInterface.ts 与 Web 部分通信其核心只有一个方法invokeNative(requestType, args): Promiseany同时定义了可被 Web 部分访问的原生接口面ExposedNativeInterface如postLoginActions。也就是说主线程 ⇄ Worker 走 MessageDispatcherWeb ⇄ 原生走 NativeInterface两条通道职责清晰。UI 代码基于 Mithril 的组件写法UI 使用 Mithril——一个自带路由与虚拟 DOM 的轻量框架采用 hyperscript 语法m(ComponentOrDomElement, {param: value}, [children])。初次接触可能觉得陌生但实际很简单。定义新式组件N 后缀如ButtonN的推荐方式是 ES6 class 属性React 语境中的 props让 Mithril 自行实例化// Defining import { Component } from mithril type Attrs { param1: string, paramTwo?: number } class MyComponent implements ComponentAttrs { view(vnode: VnodeAttrs) { return m(.h1, Hello vnode.attrs.param1) } } // Usage // ... m(MyComponent, { param1: Mithril, param2: 1 })要点相比旧的手动创建实例方式新式组件把类与属性交给 hyperscript让框架负责生命周期因此新代码几乎总是优先使用带N后缀的新式组件。网络层EntityWorker、EntityRestInterface 与实体更新与实体打交道时优先使用注入的EntityWorker而非游离的独立函数这样便于在需要时替换网络接口。EntityWorker之下一层是EntityRestInterface目前有两种实现EntityRestClient与EntityRestCache。缓存会把请求过的实体保存在内存中并通过 WebSocket 事件保持更新。EntityRestInterface的契约定义在 EntityRestCacheInterface.ts包括load、loadRange、loadMultiple、setup、setupMultiple、update、erase等方法注释明确说明读取时实体在返回前完成解密写入时实体在发送前完成加密。如果你在 Worker 部分监听 WebSocket 更新且必须有充分理由应修改 EventBusClient.ts 来实现主线程则可以订阅 EventController.ts。从源码看Worker 侧的EventBusClient维护 WebSocket 连接与事件队列处理entityUpdate、unreadCounterUpdate、phishingMarkers、leaderStatus、operationStatusUpdate、initialSyncDone、initialSyncWorkEstimate等消息类型EventBusClient.ts主线程的EventController维护监听器集合onEntityUpdatesReceived()会先通知UserController再按监听器优先级排序后逐个派发EventController.ts。EventBus与EntityRestClient共同保证实体在需要时被自动加密/解密参见decryptAndMapToInstance()CryptoFacade.ts。实体更新Entity updates服务端数据库的大多数变更都会以EntityUpdate形式推送给客户端每条更新描述发生在实体上的操作更新被分组为EntityEventBatch。这些批次是有序的客户端缓存与索引会尽量与服务端保持同步。EventBusClient中还包含批次过期等健壮性设计ENTITY_EVENT_BATCH_EXPIRE_MS 44 * 24 * 60 * 60 * 1000实体事件批次 45 天过期预留 1 天安全差以及基于尝试次数与服务器响应分档的重连间隔RECONNECT_INTERVAL小 [5,10] 秒、中 [20,40] 秒、大 [60,120] 秒随机取值以避免所有客户端同时重连压垮服务器EventBusClient.ts。工作流与构建从克隆到跑起来以下流程对应 debug 开发版本如需 release 版本node webapp prod可参考 doc/BUILDING.md其中还列出了 Emscripten 3.1.59、Rust/Cargo 1.80 等额外前置条件。准备项目克隆仓库git clone https://github.com/tutao/tutanota.git进入目录cd tutanota初始化 liboqs 与 argon2 子模块git submodule init同步子模块git submodule sync --recursive更新子模块git submodule update安装依赖npm ci依赖版本有硬性要求package.json 的engines字段声明npm 10.0.0、node 24.17.0。preinstall与postinstall脚本buildSrc/preinstall.js/postinstall.js会处理原生依赖的准备工作。构建 Web 客户端开发版不带特定目标构建以浏览器 URL 作为 API 端点node make对生产服务器构建node make prod启动任意静态服务器指向build目录即可运行npx serve build -s -p 9000 或 python -m SimpleHTTPServer 9000make.jsmake.js的完整参数如下均可用node make --help查看参数说明test/prod/local/localSecure/host url构建阶段stage默认locallocalSecure等价于host https://app.local.tuta.com:9000-a, --app type构建目标应用mail、calendar、drive默认mail-c, --clean清理 build 目录-d, --start-desktop组装并启动桌面客户端以 Electron 运行--inspect5858开启调试端口--desktop-build-only只组装桌面客户端不启动-v, --verbose在桌面客户端中启用详细日志ELECTRON_ENABLE_LOGGING1-s, --serve启动本地服务器当前版本已禁用提示改用静态服务器或桌面构建--network-debugging在 JSON 请求/响应载荷中附带 attributeNames / attributeIds便于网络调试-D, --dev-tools以 DevTools 打开的方式启动桌面客户端注意make.js还内置了一个临时清理逻辑递归删除src树中的dist目录注释表明这是 2027 年可移除的临时修复。构建桌面客户端对生产服务器构建桌面客户端node make -d prod-d会在构建后调用node_modules/.bin/electron启动桌面客户端日历应用则使用build-calendar-app目录。Android app前置条件Android SDK 与 NDK28.2.13676358最简单的方式是使用 Android Studio但任何能运行 Gradle 的环境都可以。步骤先构建 Web 部分node make prodAndroid 客户端内嵌 Web 资源再以常规方式构建 Android 应用例如在 Android Studio 中导入app-android工程注意原文档中的android-app为笔误对 mail 应用运行apptarget。日历应用则改用node make prod -a calendar仓库中的 app-android 下包含appmail、calendar、drive三个 Android 模块另有tutashared共享模块与libs/sqlcipher-android.aar等本地依赖。iOS app前置条件Xcode 与 xcodegen可能需要 swiftlint、swift-format可用 homebrew 安装。步骤先构建 Web 部分node make prod再生成 iOS 工程pushd tuta-sdk/ios # 进入 SDK 目录 xcodegen # 生成 XCode 工程 popd # 返回 mkdir -p build mkdir -p build-calendar-app cd app-ios # 进入 iOS 应用目录为两个 app 生成工程 xcodegen --spec calendar-project.yml xcodegen --spec mail-project.yml之后在 Xcode 中打开app-ios/tuta.xcworkspace即可构建 mail 应用另有drive-project.yml对应 drive 应用。仓库在package.json中也提供了等价命令npm run ios:generate-project会依次为 mail、calendar、drive 及 SDK 生成工程。日历应用的 Web 部分同样要使用node make prod -a calenarcalenar为原文档中的拼写实际参数请使用calendar。测试体系Rust 侧测试SDK 与 mimimicargo test --all # 部分 sdk 与 node mimimi 测试需要本地 HTTP 服务器目前没有 mock 服务器 # 在开发机上运行包含本地 HTTP 服务器依赖的测试 cargo test --all --features test-with-local-http-server这些测试对应 tuta-sdkRust SDK含 crypto-primitives 与 uniffi 绑定与 src/app-kit/mimimiRust 实现的本地存储模块含 17 个.rs文件与.toml配置。TypeScript 测试运行全部 TypeScript 测试npm test只运行指定测试npm run test -- -f CalendarModel不经 npm 直接运行node test -f CalendarModel在浏览器中运行测试npm run test -- -br只在浏览器中运行不跑 Node 侧npm run test -- --no-run -br查看全部测试选项npm run test -- --helppackage.json中npm test实际执行cd test node --enable-source-maps testpackage.jsonCI 则使用test-cinode test --ci。测试代码位于 test/tests按领域组织为api、crypto、mail、calendar、desktop、network、settings、subscription等目录。Chunking 规则保持启动包体健康的红线Tuta 的打包是手工控制的。正如 webapp.js 的注释所述Rollup 已不再自动优化 chunk 大小而团队比工具更清楚哪些代码必须一起加载因此手工分块反而更优但手工分块具有传染性——一旦把某模块放入某 chunk其全部静态依赖也会被拉入除非它们被显式排入其他 chunk。分块规则如下违反时可用node webapp local检查不要静态导入你不希望被打包到一起的东西例如从 login 导入 settings 会把整个 settings 在启动时加载common-min是 api/common 中被主线程与 worker 启动所需的部分用//bundleInto:common-min注解标记例如 Logger.ts 顶部即有此注解api/common 其余部分归入commonmain是主线程其余代码不含 GUI 相关代码且不依赖 sanitizer / luxondate是 luxon 及所有静态依赖 luxon 的代码其余 chunk 按功能命名login、mail-view、mail-editor、calendar-view、search、settings、worker任何代码都可以依赖common-min除common-min与app.js外任何代码都可以依赖common除 worker、common-min、common 外任何代码都可以依赖app.jsGUI 相关代码如login、mail-view可以依赖gui-base当前main也依赖gui-base但这并不理想不要静态依赖settings/subscription/login/mail-view/mail-editor/calendar-view/contacts所有依赖 luxon 的代码进入date并动态导入原生代码只能从公共代码中动态导入worker 因技术原因例外contacts与mail-editor静态依赖 sanitizer其余部分不依赖。通过node webapp local可以验证你的 import 是否符合分块约束。这一机制是 Tuta 在保持端到端加密复杂逻辑的同时、仍能让各平台启动体验流畅的关键工程实践。延伸阅读doc/BUILDING.mdWeb / Android / iOS release 版本构建指南含 Emscripten、Rust 版本要求与常见错误如未初始化子模块导致的liboqs.h file not found的处理方式doc/HACKING.md本文依据的原始文档test/tests各领域测试用例是理解行为约定的最佳示例.gitmodulesliboqs、argon2、Signal-FTS5-Extension 三个子模块的来源与用途。赞分享协同办公密码学【免费下载链接】tutanotaTuta is an email service with a strong focus on security and privacy that lets you encrypt emails, contacts and calendar entries on all your devices.项目地址https://gitcode.com/gh_mirrors/tu/tutanota点击查看免费下载相关推荐如何从源码构建Tuta Mail客户端Web/Android/桌面版全指南如何从源码构建Tuta Mail客户端Web/Android/桌面版全指南 前言 Tuta Mail原名Tutanota是一款注重隐私安全的开源电子邮件服协同办公密码学redis-py代码结构解析深入理解客户端库架构设计redis py代码结构解析深入理解客户端库架构设计 概述 redis py是Redis数据库的Python客户端库提供了全面的Redis命令支持和高效的连后端数据库客户端缓存Conky 仓库开发指南构建测试、代码规范与架构扩展实战Conky 仓库开发指南构建测试、代码规范与架构扩展实战 本篇指南以 Conky 仓库根目录的 AGENTS.md https://link.gitcode.桌面应用系统监控创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考