Homebrew 6.0 刚改变了 Mac 安装软件的方式

BBetter Stack
Computing/SoftwareInternet Technology

Transcript

00:00:00就在几个月前,在这个频道里,我们制作了一期视频,基本上把 Homebrew
00:00:05形容成了石器时代的产物,说 Nix 简直能吊打它。所以,我觉得非常有必要
00:00:12重新回到这个话题,告诉大家:我们之前说的那个“石器时代工具”,刚刚发布了
00:00:17几年来的第一个重大版本——Homebrew 6.0。重点在于,这次头条新闻并非新增了一堆
00:00:23新功能,而是一次全面的安全性重构。Homebrew 真的蜕变长大了。
00:00:30现在,让我来解释一下到底改变了什么,因为这比单纯升了个版本号更有意思。
00:00:38在 Homebrew 过去几乎整个生命周期里,当你添加第三方 Tap(也就是别人的
00:00:45软件包仓库)时,Homebrew 会直接运行他们的 Ruby 代码。就是直接执行那些代码。任何 Tap、
00:00:51任意代码,几乎不过问任何问题。现在,想象一下我们如今所处的环境。
00:00:56包管理器是目前供应链攻击的首要目标。NPM 等各类工具
00:01:01接连不断地遭受打击。“直接运行仓库给的任何代码”是个糟糕的默认设置。而 Homebrew
00:01:086.0 的新功能正是为了杜绝这一点。它叫做 Tap Trust(Tap 信任机制)。如果你喜欢这样的编程技巧和心得,
00:01:15记得关注订阅。我们一直有视频更新。不过让我先从大家每天
00:01:19都能切身体会到的部分讲起。Brew version。看,6.0。现在看好了,当我安装
00:01:25一个需要拉取若干依赖项的软件时会发生什么。Brew 不再默默直接安装,而是会列出
00:01:31即将在你的设备上安装的所有内容的摘要,并等待你确认“yes”。这就是全新的 Ask 模式,
00:01:38现在对开发者默认开启。微小的改变,但这意味着在 Brew 对机器进行任何操作前,你都能看到计划。
00:01:44现在重头戏来了,Tap Trust。看看当我添加第三方 Tap 时会怎样。
00:01:50Homebrew 会立刻叫停。提示说这个 Tap 尚未受信任,并且绝不会运行其中的哪怕一行代码,
00:01:56除非我手动明确许可。只有在我通过 Brew Trust 主动确认信任后,它才会真正
00:02:03开始执行。Homebrew 官方的 Tap 则开箱即用、默认受信任。所以日常正常的 Brew 安装体验
00:02:09完全没有变化。但对于那些从 GitHub 陌生人的 readme 文档里找来的、有点可疑的 Tap,
00:02:16现在就像加了一道锁。你必须手动授权批准它。说实话,
00:02:20就目前的大环境来看,这绝对是个相当明智的决定。而且这还不是唯一的实质性升级。
00:02:25内部元数据系统现在成为了默认配置,这意味着你的所有软件包信息都能在一次
00:02:30干净利落的下载中搞定,而不需要发起十几小个网络请求。因此 Brew update 变快了很多。还有一个
00:02:37全新的命令 Brew execute,本质上就是 Homebrew 版的 NPX。可以运行一次工具,而无需将其
00:02:45永久安装到你的系统中。还有 Brew vulns,它能够扫描你已安装的软件包,对照
00:02:51已知安全问题和警告。另外 6.0 还悄悄修复了三个安全漏洞,包括一个可能在 Mac 安装包中以 root 身份运行代码的漏洞。
00:02:58这是一个非常有担当和风骨的版本。好了,但这里面也有个隐患/限制。对你们其中的一些人来说,影响可能会很大。所以我直接明说了吧。
00:03:09Tap Trust 是个破坏性变更(Breaking Change)。如果你的 CI 流水线依赖于第三方 Tap,
00:03:14Brew doctor 只要检测到未信任的 Tap 会直接抛出错误。而海量的标准 GitHub
00:03:20Actions 第一步就是运行 Brew doctor。所以很多人更新后,他们的构建流程就开始报错失败。
00:03:28解决办法是在配置中将这些 Tap 标记为受信任,但这需要你自己手动去配置。
00:03:35没人会帮你做。Ask 模式也是同理。如果你有一些脚本默认假设
00:03:41Brew 安装无需任何提示,那么这个全新的确认提示可能会导致脚本永久卡死。再说说整体观感,
00:03:46如果你只是个日常安装应用的用户,表面上几乎看不出什么区别。
00:03:51这是一个侧重安全和架构更新的版本,可不只是换了个外壳刷了层新漆。这里顺便澄清一个误区。
00:03:58现在很多东西都在用 Rust 重写。但 Homebrew 并没有用 Rust 重写,
00:04:04至少目前没有。那只是一次实验。核心重点依然像以前一样,重新回到了 Ruby 代码库本身。
00:04:10那么,大家应该升级到 Homebrew 6.0 吗?对绝大多数人来说,答案是:直接升。
00:04:16你会获得三个安全补丁,而且说实话,Brew update 也会直接把你推向 6.0,
00:04:22无论你有没有提前规划。现在需要稍微放慢脚步的,是那些
00:04:27运行着涉及第三方 Tap 的 CI 流水线,或者依赖静默安装自动化的开发者。先把这些处理好,
00:04:33你就完全没问题了。如果你还在用 Intel 芯片的 Mac,注意了:6.0 明确指出了
00:04:40在接下来的几年里淘汰 Intel 支持的时间表。而 Apple Silicon(Apple 芯片)用户,也就是用新电脑的朋友,
00:04:46我们完全不用担心。它甚至还增加了对全新 M5 芯片的支持。最后我是这样看待这次更新的:
00:04:53多年来,退一步讲,Homebrew 一直是个便利工具,只是在 Mac 上获取软件最快的方式。
00:04:59而在 6.0 版本中,它似乎变成了一个安全关卡,进入机器的代码
00:05:05终于必须证明自己是受信任的。这是迈出的关键一大步。包管理器
00:05:10终于赶上了我们所有人多年来一直在面对的安全威胁模型。这才是最重要的事,
00:05:15而不是框框里的数字是 6.0 还是 6.1,而是随之而来的安全理念。如果你喜欢这样的
00:05:21编程技巧与心得,请务必订阅 BetterStack 频道。我们下期视频再见。

Key Takeaway

Homebrew 6.0 通过 Tap Trust 授权、Ask 确认模式和原生漏洞扫描重构了底层安全架构,将包管理器从纯粹的便捷安装工具转变为强制安全校验的管理关卡。

Highlights

  • Homebrew 6.0 引入 Tap Trust 机制,默认拦截所有第三方仓库的 Ruby 代码执行,需手动输入 brew trust 授权。

  • 全新的 Ask 模式为开发者默认开启,在执行任何安装或更新前会列出完整依赖项摘要并等待 confirm 确认。

  • 系统内置元数据架构成为默认配置,大幅减少网络请求数量,显著提升了 brew update 的运行速度。

  • 新增 brew execute 用于临时运行工具而无需安装,新增 brew vulns 扫描已安装软件包的安全漏洞。

  • 版本更新修补了三个安全漏洞,其中包括一个允许在 macOS 安装包中以 root 权限运行代码的高危漏洞。

  • Tap Trust 与 Ask 模式属于破坏性变更(Breaking Change),会导致依赖第三方 Tap 的 CI 流水线和自动化脚本挂起报错。

Timeline

版本安全重构背景

  • Homebrew 6.0 是近年来的首次重大版本更新。
  • 本次更新的核心并非堆叠新功能,而是对整体安全架构进行全面升级。

相较于此前被拿来与 Nix 等新兴工具对比的旧版本,6.0 版本标志着 Homebrew 机制的成熟。安全性的彻底重构构成了本次更新的基石。

Tap Trust 与 Ask 模式机制

  • 历史版本无条件直接运行第三方 Tap 中的 Ruby 代码,存在极高的供应链攻击风险。
  • Tap Trust 默认拦截第三方仓库的代码运行,仅官方 Tap 开箱即用。
  • Ask 模式要求用户在写入系统前手动确认依赖项摘要。

包管理器已成为软件供应链攻击的核心目标。在 6.0 中,直接运行第三方仓库代码的默认设置被彻底废除。添加非官方 Tap 时,系统会暂停并提示该 Tap 未受信任,直至通过 brew trust 显式授权。同时,对开发者默认启用的 Ask 模式能在变动生效前展现完整的依赖变更图谱。

新工具与性能优化

  • 元数据架构优化将多次网络请求整合为单次干净下载,加速 brew update。
  • 新增 brew execute 与 brew vulns 命令,并修复了 root 权限漏洞。
  • 核心代码库重置回 Ruby,并非使用 Rust 重写。

内部元数据的整合极大地提升了索引拉取效率。brew execute 提供了类似于 NPX 的即用即走体验,无需持久化安装软件包;brew vulns 则实现了已安装软件与已知安全数据库的交叉比对。本次更新还修复了三项安全漏洞,包含一个可能导致以 root 权限执行代码的漏洞。此前关于使用 Rust 重写 Homebrew 核心的传闻被证实仅为实验,核心逻辑仍维持在 Ruby 代码库。

破坏性变更与 CI 流水线影响

  • Tap Trust 机制会导致包含未信任 Tap 的 CI 流水线直接抛出 brew doctor 错误。
  • Ask 模式的交互式提示会导致无无人值守自动化脚本永久卡死。

针对 CI/CD 环境,6.0 带来了显著的兼容性挑战。许多 GitHub Actions 工作流在首个步骤调用 brew doctor 时,会因未授权的第三方 Tap 而中断。自动化脚本若未预先配置 Tap 的信任状态或未适配交互提示,构建任务将被阻塞。

升级建议与硬件支持时间表

  • 普通用户应直接升级以获取安全补丁,自动化环境需先完成配置适配。
  • 更新已明确包含未来几年内逐步淘汰 Intel 芯片支持的时间表。
  • 新版本已加入对 Apple M5 芯片的原生支持。

对于没有复杂 CI/CD 依赖的常规使用者,直接升级是最佳选择,brew update 也会自动推动升级过程。涉及第三方 Tap 的自动化环境需在配置文件中明确标记信任状态后再进行升级。此外,6.0 正式规划了 Intel Mac 的淘汰周期,并针对最新 Apple Silicon 硬件添加了适配。

Community Posts

View all posts