Cackle / cargo acl

Rust 代码 ACL 检查器。

Cackle 是一个用于分析你的 crate 的传递依赖，以查看每个 crate 使用了哪些类型的 API 的工具。

其理念是寻找使用了你认为不应该使用的 API 的 crate。例如，一个从描述上看应该只进行数据处理的 crate，但实际上却在使用网络 API。

安装

目前 Cackle 只能在 Linux 上运行。更多详情请参阅 PORTING.md。

cargo install --locked cargo-acl

或者如果你想从 git 安装：

cargo install --locked --git https://github.com/cackle-rs/cackle.git cargo-acl

推荐安装 bubblewrap，因为它允许在沙箱中运行构建脚本（build.rs）、测试和 rustc。

在使用 apt 的系统上，可以通过运行以下命令安装：

sudo apt install bubblewrap

使用方法

在你的项目根目录（包含 Cargo.toml 的目录）中运行：

cargo acl

这将交互式地指导你创建初始 cackle.toml。建议手动编辑 cackle.toml。特别是，你应该查看你的依赖树，思考哪些 crate 导出了你想要限制的 API。例如，如果你使用了提供网络 API 的 crate，你应该在配置中声明这一点。更多详情请参阅 CONFIG.md。

在 CI 中运行

Cackle 可以在 GitHub Actions 中运行。请参阅 cackle-action 仓库中的说明。

特性

• 检查你的依赖树中每个 crate 使用了哪些 API。
• 忽略死代码，如果一个 crate 使用了某个 API，但在你的二进制文件中未被调用的代码中，则不会被计入。
• 限制哪些 crate 允许使用 unsafe。
• 一个终端 UI，显示发现的问题。
  • 预览检测到 API 使用或 unsafe 的源代码。
  • 对于 API 使用，显示该代码如何可达的回溯。
  • 从几个可以应用到你的配置文件以允许使用的编辑中选择。
• 可以在沙箱中运行构建脚本、测试，以限制网络和文件系统访问。
• 每个构建脚本的沙箱单独配置，所以如果一个构建脚本需要额外的访问权限，你可以只授予该构建脚本。
• 可以在沙箱中运行 rustc，从而沙箱化所有过程宏。但目前这不是细粒度的，所以如果一个过程宏需要更多访问权限，就需要授予所有过程宏。幸运的是，需要网络访问的过程宏相对较少。

限制和注意事项

• 过程宏可能会检测到它正在 Cackle 下运行，并发出不同的代码。
• 即使没有过程宏，一个 crate 也可能只在某些配置下使用有问题的 API，而这些配置可能与你运行 Cackle 时使用的配置不匹配。
• 此工具旨在补充和辅助第三方代码的手动审查，而不是替代它。
• 你的配置可能遗漏了定义某个 crate 提供的 API 属于你关心的某个类别。
• 毫无疑问，一个有决心的人可以通过无数种方式规避检测他们正在使用某些 API。随着时间的推移，我们可能会尝试防止这种规避，但目前，你应该绝对假设规避是可能的。

有了这些限制，还有什么意义呢？真正的目标是提高将有问题的代码悄悄混入某个包所需的门槛。使用 Cackle 不应该替代你原本会对依赖进行的任何手动代码审查。

工作原理

请参阅 HOW_IT_WORKS.md。

常见问题

FAQ

贡献

非常欢迎贡献。如果你想参与，请通过提出问题或发送电子邮件给 David Lattimore（电子邮件地址在提交日志中）联系我们。

许可证

此软件根据 MIT 许可证和 Apache 许可证（版本 2.0）的条款分发。

详情请参阅 LICENSE。

除非你另有明确说明，否则你有意提交以包含在本 crate 中的任何贡献，根据 Apache-2.0 许可证的定义，均应按上述方式双重许可，无任何附加条款或条件。