Chromium 与 Cargo 生态的选型与信任模型comprehensive-rust 课程中的 Rust 构建系统解析【免费下载链接】comprehensive-rustThis is the Rust course used by the Android team at Google. It provides you the material to quickly teach Rust.项目地址: https://gitcode.com/GitHub_Trending/co/comprehensive-rust本文基于 comprehensive-rust 课程的 Chromium 专题系统对比 Chromium 自带的gnninja构建体系与 Rust 社区标准cargo生态之间的差异厘清在 Chromium 仓库内编写 Rust 代码时可以走的三种技术路径及其信任边界。读完本文你将理解为什么把 Rust 构建进 Chromium 浏览器必须走gn/ninja同时掌握 cargo 生态在原型开发、命令行工具、库开源协作等场景中的独特价值以及一套完整的第三方 crate 引入、审计与更新流程。背景两个生态两种默认路径Rust 社区绝大多数项目使用cargo作为构建与依赖管理工具并消费来自 crates.io 的公开库而 Chromium 则使用gn生成 ninja 文件与ninja执行构建依赖关系被限定在一组经过审核的固定 crate 集合中。两者代表的是两种截然不同的工程哲学前者追求依赖获取的便利性与生态丰富度后者追求供应链的可审计性与构建结果的可复现性。在 Chromium 中编写 Rust 代码时你实际上面临三种选择见 cargo.md路径构建方式工具链与依赖来源适用性路径一gnninja借助//build/rust/*.gni中的模板如rust_static_libraryChromium 审核过的工具链与 crate能把 Rust 代码构建进 Chromium 浏览器本体路径二cargo但自律地限制使用 Chromium 审核过的工具链与 crateChromium 审核集合在 Chromium 周边独立工程中使用路径三cargo信任来自网络的自选工具链与 craterustup 安装的工具链 / crates.io 下载的库完全脱离 Chromium 约束的独立项目课程的后续内容聚焦路径一因为只有gnninja才能把 Rust 代码构建进 Chromium 浏览器但 cargo 作为 Rust 生态不可或缺的组成部分应当始终留在开发者的工具箱里。课程也明确提醒即便你只用路径二或路径三Chromium 官方文档docs/rust.md 的 Using cargo 一节也给出了限制自己使用 Chromium 审核过的工具链和 crate的约束建议。为什么 Rust 进浏览器必须走 gn 与 ninjaChromium 的构建系统由gn元构建系统负责生成 ninja 文件和ninja实际执行构建任务组成。要让 Rust 代码成为浏览器二进制的一部分就必须接入这条链路。课程配套的 setup.md 给出了可复现的最小构建流程gn gen out/Debug autoninja -C out/Debug chrome out/Debug/chrome # 或 Mac 上out/Debug/Chromium.app/Contents/MacOS/Chromium这里推荐使用组件化component的 Debug 构建以获得最快的迭代速度——这恰好是默认配置。关于 Rust 在 Chromium 中的整体政策policy.md 指出Rust 既可以用于第一方代码first-party也可以用于第三方库。第一方场景是 C 侧通过语言边界language boundary直接调用 Chromium 自有的 Rust 代码第三方场景则通常是已有的 Rust crate Chromium 自写的少量胶水代码wrapper因为绝大多数 Rust 库并不会直接暴露 C/C API。课程把更复杂的第三方 crate 场景作为主线而胶水代码的编写技术如使用 cxx 绑定见 interoperability-with-cpp.md。在gn体系中一个 Rust 静态库目标形如rust_static_library(my_rust_lib) { crate_root lib.rs sources [ lib.rs ] deps [ //third_party/rust/example_rust_crate/v1:lib ] }这里的deps指向第三方 crate 的:lib目标详见下文依赖声明小节。cargo 的优势场景从原型到生态课程的小组练习mini exercise要求学员头脑风暴cargo 可能带来优势的场景并评估其风险画像。讲者笔记中给出的要点构成了对 cargo 价值的完整论证crates.io 生态的丰富性与易用性写工具或为 Chromium 做原型时几乎任何需求都能找到对应的 crate且普遍好用——clap做命令行解析、serde做序列化/反序列化、itertools处理迭代器等。cargo让尝试一个新库的成本极低只需在Cargo.toml中加一行依赖即可开始编码。可以类比 CPAN 之于 Perl、pythonpip之于 Python 的历史作用。开发体验的完善这不仅有核心 Rust 工具的功劳——例如用rustup在 nightly、当前 stable 与旧 stable 之间切换rustc版本以测试一个 crate——也得益于第三方工具生态Mozilla 提供cargo vet用于简化并共享安全审计criterioncrate 提供开箱即用的基准测试。安装这类工具同样简单cargo install --locked cargo-vet。可以与 Chrome 扩展或 VSCode 扩展的安装体验类比。适合 cargo 的典型项目画像命令行工具是 Rust 在工业界增长最显著的领域之一其库的广度与易用性可与 Python 媲美同时得益于丰富的类型系统更健壮、作为编译型语言运行更快而凡是希望获得外部贡献、或需要在 Chromium 之外如 Bazel、Android/Soong 构建环境被复用的库也应使用 cargo。Chromium 内外的 cargo 实践案例课程特别列举了若干与 Chromium 相关、却基于 cargo 构建的真实项目说明Chromium 生态 ≠ 全部都是 gn/ninjaserde_json_lenient曾在 Google 其他部门实验并获得性能改进的 PR属于 JSON 解析库方向的项目Fontations 系列库如font-types字体处理相关的 Rust 库集合gnrt工具这是课程后续会正式介绍的 crate 下载与构建规则生成工具它本身依赖clap做命令行解析、toml做配置文件读取。其使用 cargo 有一个独特原因——在构建和引导 Rust 标准库即构建 Rust 工具链本身时gn尚不可用。值得注意的是gnrt的供应链细节run_gnrt.py使用 Chromium 自带副本的cargo与rustc来执行gnrt虽然依赖从互联网下载的第三方库但run_gnrt.py要求 cargo 仅允许--locked内容由Cargo.lock锁定版本。也就是说即使引入外部依赖Chromium 也通过锁定文件把不确定性压缩到最小。信任模型全景用 gn 与 cargo 时分别信任谁课程练习的第二部分是讨论使用gn/ninja、离线 cargo 等不同方案时需要信任哪些工具、库和人群。讲者笔记给出了相当完整的信任清单这也是供应链安全教育的核心素材rustcRust 编译器其下游还依赖 LLVM 库、Clang 编译器、从 GitHub 拉取并经 Rust 编译器团队审查的rustc源码以及用于引导bootstrapping的二进制 Rust 编译器rustup值得指出它同样在 rust-lang 组织下开发与rustc同源cargo、rustfmt等标准工具链组件各种内部基础设施构建rustc的机器人、向 Chromium 工程师分发预编译工具链的系统等Cargo 辅助工具如cargo audit、cargo vetvendor 进//third_party/rust的 Rust 库这些由 securitychromium.org 审核其他 Rust 库从冷门小众到相当流行、广泛使用的一应俱全。这条清单的潜台词是无论走哪条路径你都在隐式信任一长串主体gn/ninja 审核 crate 的路径通过把信任集中到 Chromium 自身的审查流程上来换取可控性而 cargo 路径则把信任分散到了整个开源工具链。从选型到落地第三方 crate 引入全流程课程在 adding-third-party-crates.md 中首先点明了 C 库与 Rust crate 的结构性差异属性C 库Rust crate构建系统多种多样统一Cargo.toml典型库大小偏大小传递依赖少多对 Chromium 工程师而言这有利有弊统一的构建系统意味着可以把 crate 的引入过程自动化但传递依赖普遍存在往往一次引入会带来多个库。完整的落地流程由以下环节组成1. 下载 crategnrt vendorgnrtRust Third-Party 工具负责下载 crate 并生成BUILD.gn规则详见 downloading-crates.mdcd chromium/src vpython3 tools/crates/run_gnrt.py -- vendor这个vendor命令可能下载的内容包括目标 crate、直接与传递依赖、以及cargo为解析 Chromium 所需完整 crate 集合而要求升级的其他 crate 的新版本。gnrt虽是 Chromium 源码的一部分但运行该命令会从 crates.io 下载并运行其依赖——这正是上文讨论过的安全决策的又一次体现。此外Chromium 为部分 crate 维护补丁存放在//third_party/rust/chromium_crates_io/patchesvendor 时会被自动重新应用若补丁失败则需要人工介入。2. 配置Cargo.toml集中式依赖管理Chromium 通过单一、集中管理的Cargo.toml//third_party/rust/chromium_crates_io/Cargo.toml维护所有直接 crate 依赖见 configuring-cargo-toml.md[dependencies] bitflags 1 cfg-if 1 cxx 1 # lots more...与其他任何Cargo.toml一样可以针对依赖指定更多细节——通常你会希望声明要启用的features。新增 crate 时往往还需要在另一个文件gnrt_config.toml中补充信息。3. 配置gnrt_config.tomlChromium 专属扩展与Cargo.toml并存的 gnrt_config.toml 包含 Chromium 对 crate 处理的专属扩展。新增 crate 时至少需要指定group取值为以下三种之一# safe: The library satisfies the rule-of-2 and can be used in any process. # sandbox: The library does not satisfy the rule-of-2 and must be used in # a sandboxed process such as the renderer or a utility process. # test: The library is only used in tests.例如[crate.my-new-crate] group test # only used in test codesafe表示库满足 rule-of-2两条安全防线可用于任意进程sandbox表示不满足 rule-of-2必须限定在渲染进程或 utility 进程等沙箱进程中使用test表示仅供测试代码使用。此外根据 crate 源码目录布局可能还需要在此文件中指定其LICENSE文件的位置课程后续还会介绍用该文件解决各种问题如构建问题的更多配置项。4. 依赖声明//third_party/rust/...:lib一旦 crate 已入库并生成构建规则依赖它只需在rust_static_library目标的deps中加上该 crate 的:lib目标见 depending-on-a-crate.md。目标路径的语义为------------ ---------------------- //third_party/rust | crate name | /v | major semver version | :lib ------------ ----------------------即//third_party/rust/crate 名/v主版本号:lib例如//third_party/rust/example_rust_crate/v1:lib。按 major semver 版本分目录组织使多个大版本可并存。5. 入库检查git add -f与包容性语言运行git status应能看到两类变更见 checking-in.mdcrate 代码位于//third_party/rust/chromium_crates_io元数据BUILD.gn与README.chromium位于//third_party/rust/crate/version。后者还需补充一个OWNERS文件。所有内容连同Cargo.toml、gnrt_config.toml的修改一起提交进 Chromium 仓库并且必须使用git add -f否则.gitignore可能跳过部分文件。提交时预检presubmit可能因非包容性语言检查失败——Rust crate 数据常包含 git 分支名而许多项目仍在使用非包容术语——此时需要运行infra/update_inclusive_language_presubmit_exempt_dirs.sh infra/inclusive_language_presubmit_exempt_dirs.txt git add -p infra/inclusive_language_presubmit_exempt_dirs.txt # add whatever changes are yours6. 安全审计从人工清单走向 cargo vet新增库受 Chromium 标准政策约束也必然经过安全审查见 reviews-and-audits.md。由于引入的往往不只是单个 crate 还有传递依赖待审代码量可能相当大但安全的 Rust 代码副作用有限。Chromium 长期目标是迁移到基于cargo vet的流程当前每个新 crate 会检查以下要点弄清每个 crate 的用途与 crate 之间的关系若构建系统含build.rs或过程宏查明其作用并确认与 Chromium 常规构建方式兼容确认 crate 维护状况合理用cargo audit检查已知漏洞先cargo install cargo-audit——讽刺的是这本身就涉及从互联网下载大量依赖cd third-party/rust/chromium_crates_io; cargo audit确保任何unsafe代码满足 Rule of Two 要求检查是否存在fs、netAPI 的使用以足够细的粒度通读全部代码排查可能被恶意插入的异常内容不必追求 100% 完美代码量常常过大。这些只是指导原则——应与 securitychromium.org 的审查者协作确定让 crate 达到可信的正确方式。7. 长期维护安全修复责任作为任何第三方 Chromium 依赖的 OWNER你有责任跟进安全修复见 keeping-up-to-date.md。Chromium 希望在不久的将来自动化 Rust crate 的更新但在那之前这依然是你的责任与对待其他任何第三方依赖无异。课堂练习设计让选型与信任成为直觉本节的 mini exercise 建议将学员分成 34 人小组讨论两个问题一是 brainstorm cargo 可能带来优势的场景并评估其风险画像二是讨论使用gn/ninja、离线 cargo 等不同方案时需要信任哪些工具、库和人群。若学员是线下共处应避免他们在完成练习前偷看讲者笔记。这个练习的价值在于把上文的技术对比转化为对供应链风险的直觉判断——每种选型都不是免费的区别只在于你把信任托付给了谁。小结在 comprehensive-rust 课程的 Chromium 专题中cargo.md 给出了一条清晰的决策主线要构建进 Chromium 浏览器走gn/ninja 审核 crate要快速原型、写独立工具或做开源库cargo是更好甚至唯一现实的选择。而无论选择哪条路供应链信任都是绕不开的命题——rustc、rustup、cargo、vendor 库、内部基础设施层层叠加构成了每一行 Rust 代码背后的信任链条。课程随后用完整的第三方 crate 引入流程vendor 下载 →Cargo.toml/gnrt_config.toml配置 →//third_party/rust/crate/vmajor:lib依赖声明 →git add -f入库 → 安全审计 → 长期维护演示了在严格受控的 Chromium 体系中如何让 cargo 生态的丰富性与工程可审计性共存。【免费下载链接】comprehensive-rustThis is the Rust course used by the Android team at Google. It provides you the material to quickly teach Rust.项目地址: https://gitcode.com/GitHub_Trending/co/comprehensive-rust创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考