世界を動かす技術を、日本語で。

Show HN: Homebrew 6.0.0 の紹介

2026年6月11日原文(brew.sh)

概要

Homebrew 6.0.0がリリースされ、多数の新機能と改善点が追加。 主な変更点は セキュリティ強化パフォーマンス向上macOS 27対応。 新しい tap trust機構Linuxサンドボックスbrew bundleの進化 が目玉。 ユーザーアンケートを反映した デフォルト設定の改善 も実施。 今後のサポート方針や非推奨事項も明確化。

Homebrew 6.0.0の主な新機能と変更点

  • 新tap trustセキュリティ機構 導入

    • サードパーティtapのRubyコード実行前に 明示的な信頼設定 を要求
    • 公式tapは デフォルトで信頼
    • brew tap trust管理コマンド の追加と新オプション対応
    • 信頼リスト のリモート連携や 自動tap防止 など安全性向上
  • デフォルト内部JSON API

    • Homebrewメタデータ を一括取得する 高速・省サイズAPI が標準に
    • brew update の通信量削減と速度向上
    • 旧環境変数 HOMEBREW_USE_INTERNAL_API は非推奨
  • Linuxサンドボックス

    • Bubblewrap によるビルド・テスト・インストール工程の サンドボックス化
    • macOSと同等の セキュリティ強化
    • CI環境でも 自動適用、開発者向けに デフォルトON
  • ユーザーアンケート反映のデフォルト改善

    • askモード を開発者デフォルト化し、依存関係の事前確認と変更前の確認プロンプト表示
    • brew install/upgrade 時の依存関係サマリー表示
    • アップグレードサマリーメタデータ取得の説明 も追加
  • brew bundleの大幅進化

    • 並列インストール を自動化し、 npm/krew/winget 等の拡張サポート
    • クリーンアップ機能 の拡充、 セキュリティ強化
    • mas/cargo/go/uv など各種エコシステムへの対応
    • bundle typeの無効化フラグガイダンス改善
  • パフォーマンス向上

    • 起動速度最適化brew leaves約30%高速化
    • bottle tab取得の並列化Rubyライブラリのロード削減
  • macOS 27 (Golden Gate)初期対応

    • Intelサポート終了の予告
    • サポートTierの明確化関連コードの段階的削除

セキュリティ強化と非推奨事項

  • tap trustによる第三者tapのリスク低減
  • セキュリティアドバイザリ (POSTダウンロード戦略、Git hooks、pkgインストーラの脆弱性修正)
  • 環境変数フィルタリングダウンロード前のチェックcaskのSHA要求
  • デフォルトopt-inの非推奨化、不要オプションの廃止予定
  • SBOMサポートはopt-in

新機能とコマンド追加

  • caskのpinやbrew missing対応AppImage/Linux trash対応
  • caskアップグレードのキュー共有や自動アップデート制御
  • OSサポートの明確化 (Linux/WSL/M5 CPU等)
  • tapリモートの正規化、明示的tapインストール
  • brew info/brew tap-infoの出力改善 (バイナリ一覧、依存関係、インストール状態明示)
  • brew exec/brew as-console-userなど新コマンド
  • ダウンロードの並列化、エラー詳細表示、部分ダウンロード保存
  • brew servicesのsystemdタイマー対応、パス自動作成
  • VCSリビジョン保存、パッチ/メタデータ対応
  • インストールステップフレームワーク (postinstall/preflight/postflightのDSL化)
  • brew vulnsによる脆弱性チェック

サポート・今後の方針

  • macOS Intelサポート終了スケジュール (2026年Tier3、2027年完全終了)
  • master→main移行の継続、@masterユーザーへの警告
  • Gatekeeperチェック非対応caskの廃止予定
  • 今後の更なるセキュリティ・パフォーマンス改善方針

Homebrew 6.0.0は、 セキュリティ・利便性・パフォーマンス の全方位で大きく進化。 今後も 公式ドキュメントサポートポリシー の確認が重要。 質問や詳細は 公式GitHubやdocs.brew.sh まで。

Hackerたちの意見

すごい!アップデートありがとう。'brew upgrade'を実行したときに、すべてのカスクが更新されたことに気づいたんだけど(Cask JSON APIで「auto_updates: true」となっているものも含めて)。これは意図された新しいデフォルトの動作なの?前はこんなことなかった気がするんだけど…

HOMEBREW_NO_UPGRADE_AUTO_UPDATES_CASKSを1に設定する必要があるよ。最初にそれが起こるときにヒントが出るからね。ヒントをオフにしている(HOMEBREW_NO_ENV_HINTS経由で)場合、警告なしにこの動作が始まるかもしれないから、ちょっと残念だね。詳しくはここを見てね: https://docs.brew.sh/FAQ#why-arent-some-apps-included-during...

これは意図的です。自動更新がすでに行われているものはスキップします。このコードはまだ完璧ではないので、正しく動いていないものを見つけたら問題を報告してください。

アップデートありがとう。Homebrewにクールダウンメカニズムを導入する可能性はあるかな?新しいコードをすぐに自分のマシンに送ってくれるのはAppleとブラウザだけでいいんだ。他のもの(vscodeやその拡張、npm、homebrew、自己更新するアプリなど)は、数日待つ方が安心だと思ってる。例外的な0day攻撃があればクールダウンをスキップすることもあるかもしれないけど、今の形だとユーザーはbrew upgradeを実行するまで0day攻撃に対して脆弱だよね。

+1 broxitが何を指しているのか知らない人のために言うと、これは多くのソフトウェアやパッケージマネージャーで供給チェーン攻撃への脆弱性を減らすために使われる--minimum-release-age/minimumReleaseAgeのようなものを指しているよ。こういった攻撃は、侵害から数日以内に検出されることが多いんだ。Bunの例を挙げると、こちら: https://bun.com/docs/pm/cli/install#minimum-release-age

これ絶対必要だよね。

このリリースに含まれてるよ、ここを見てね: > クールダウン、livecheck、バンピング

https://docs.brew.sh/Supply-Chain-Security でクールダウンの扱いや、NPMとは非常にリスクプロファイルが異なる理由について詳しく説明してるよ。また、NPM/PyPi/RubyGemsからパッケージを作成する際に、これらの攻撃にさらされたものについても、パッケージング時と新しいバージョンに更新するためのPRを作成する際に、すでにクールダウンを適用しているよ。

大体の人はリリースチャンネルを使ってこれを対処しています。brew set-channel stable/edgeってやつですね。今週は少しイライラしました。発表後にelixir 1.20を試す時間が数分しかなかったのに、brewが遅れていたからです。他の方法でerlやelixirをインストールすることもできますが(私は自分のツールチェーンを使うのが好きです)、その瞬間にはやる価値がありませんでした。brewには一部のレシピにソースオプションがあったりして、それも基本的には解決策になりますよ、目を細めれば。

フルOSレベルの開発環境をHomebrew+pipx+npmからhttps://mise.jdx.dev/に切り替えたんだ。最初は実験的にやってみたんだけど、実際にすごくうまくいってる。多くのものがGitHubのリリースや対応するパッケージマネージャーから直接インストールされて、再パッケージするためのグルーコードもゼロ、バージョンの遅れもない。任意のバージョンのパッケージをインストールできて、複数のバージョンを同時に使ったり、作業フォルダごとにアクティブなものを動的に調整できるのが面白い。Miseは依存関係をサポートしてないけど、pnpm/uvがそれを処理するか、静的バイナリがそのまま動くから、あまり問題にならないことに驚いた。過去には、Homebrew用にPythonアプリケーションをパッケージングするという不運な経験があって(約50の依存関係を「リソース」としてインポートして、すべてをソースからビルドしたり、すでにHomebrewにあるか手動で確認したり、5つの異なるプログラミング言語のビルドツールチェーンを依存関係として宣言したり、毎回の更新でCIが終わるのを1時間以上待ったり、そして上流の更新で「ビルド時依存関係ループ」が発生してプロジェクトが突然Homebrew用にアンパッカブルになったりしたから、Miseが「簡単な道」を選んだ理由がよくわかるよ。唯一、Brewfileから置き換えられなかったのはDocker CLI(Colimaとやり取りするために必要だった)だけど、カスク用にはまだHomebrewを使ってる。みんなも自分の開発環境を試してみてほしい、新しい素晴らしいツールがたくさんあるから。

miseはパッケージレジストリに依存していることを忘れないでください。自分自身やツールをインストールするために必要です。

みんなの頑張りに感謝!私たちは少数ですが、Homebrewは不変のLinuxディストリビューションで環境を素早く立ち上げるのにとても役立っています。Universal BlueのBazzite (1.28%)、Bluefin (0.49%)、Aurora (0.28%)などの特定のOSは、デフォルトでHomebrewをバンドルしていますね。

Hacker Newsで議論の続きを見る