Вчера вышел Homebrew 6.0.0, и на первый взгляд это обычный changelog: tap trust, песочница на Linux, более быстрый JSON API, поддержка macOS 27. Но если соединить точки, складывается совсем другая картина — это один из самых security-ориентированных релизов в истории Homebrew, и почти всё в нём бьёт в одну цель: сократить поверхность, на которой на вашей машине исполняется чужой, непроверенный код. Плюс жёсткий дедлайн для владельцев Intel-маков, который проигнорировать не выйдет. Разберём, что реально под капотом — и почему это логичный ответ на эпоху supply-chain-атак вроде бэкдора в xz.
Tap trust: затыкаем главную историческую дыру
Начнём с того, ради чего, по сути, и подняли мажорную версию. У Homebrew годами зияла концептуальная дыра: сторонний тап мог содержать произвольный, несендбоксенный Ruby, который выполнялся на вашей машине — без единого предупреждения. Подключил репозиторий ради одной утилиты — и доверил ему выполнение кода с правами твоего пользователя. Классический вектор для атаки через компрометацию или подмену репозитория.
Теперь Homebrew требует явно доверять тапу (и tap-qualified формулам/каскам) до того, как их код будет вычислен или запущен. Как это устроено:
🔐 Официальные тапы Homebrew доверены по умолчанию — а вот всё стороннее нужно одобрить руками.
🔐 Untrusted-тапы флагуются до того, как их код исполнится, а не после; авто-подключение недоверенных тапов вообще остановлено.
🔐 Списки allow/forbid/trust привязаны к remote'ам — то есть доверие выдаётся конкретному источнику, а не просто имени тапа, которое можно подменить.
🔐 Появились команды управления: brew tap для trust-операций, доверие тапу по его remote-URL, флаг --json=v1 у brew trust, поле trusted в brew tap-info. И brew bundle теперь понимает опцию trusted:, а brew bundle dump записывает доверенные записи.
Мой взгляд: это абсолютно правильный размен. Да, появляется трение — придётся осознанно нажимать «доверяю». Но именно это и есть смысл: модель «подключил тап и молча отдал ему RCE» была анахронизмом, и хорошо, что её наконец похоронили.
Песочница на Linux: Bubblewrap догоняет macOS
Вторая большая история — Linux наконец получает то, что на macOS было давным-давно. Раньше на маке фазы сборки, теста и postinstall уже крутились в песочнице (через нативный sandbox), а на Linux — нет. То есть самая массовая платформа для CI и серверной разработки была как раз слабым звеном.
В 6.0.0 завезли песочницу на базе Bubblewrap. Если не сталкивались: Bubblewrap (bwrap) — это лёгкий механизм изоляции, который через непривилегированные user namespaces Linux создаёт процессу урезанное окружение: отдельные mount/PID/network-namespace, ограниченный вид файловой системы, без необходимости рутовать всё подряд. Это ровно та технология, на которой стоит песочница Flatpak. Применительно к Homebrew это значит, что сборочные скрипты, тесты, postinstall — и даже исполняемые хуки касков — больше не имеют вольного доступа ко всей вашей системе.
Что важно в деталях: логику песочницы macOS перенесли так, чтобы шарить код между платформами (одна реализация на две ОС — меньше расхождений и багов), укрепили install-фазы, разрешили запись логов внутри сборочной песочницы, а в CI на hosted-Ubuntu Bubblewrap теперь ставится автоматически. Пока по умолчанию это включено для разработчиков, но направление однозначное.
Install steps framework: меньше Ruby — меньше поверхности атаки
А вот это — самое архитектурно красивое, что в заголовках обычно теряется. Подумайте о том, как раньше работал postinstall: почти каждая формула или каск, которой нужно было что-то донастроить после установки (создать директорию, тронуть маркер-файл, переместить или слинковать файлы), везла для этого произвольный Ruby-блок, который скачивался и вычислялся в момент установки. Это и тормоз (нужно тянуть и eval'ить Ruby), и — что важнее — лишний канал исполнения кода.
Новый install steps framework выражает типовые postinstall/preflight/postflight-операции как упорядоченные, literal-only DSL-данные — то есть декларативное описание без исполняемого кода, — и отдаёт их прямо через JSON API. Если формула или каск делает только простую подготовку файлов, ей больше не нужно скачивать и выполнять Ruby-файл при установке. В homebrew/core и homebrew/cask это уже покрывает большую долю post_install и *flight-блоков (mkdir, touch, mv, symlink), и список операций будут расширять.
Уловили философию? Это та же идея, что и в tap trust, только на уровне формул: чем меньше произвольного кода исполняется на машине, тем меньше поверхность атаки. И заодно быстрее. Два зайца одним декларативным выстрелом — на мой взгляд, лучшее инженерное решение всего релиза.
JSON API по умолчанию и cooldowns: меньше сети, меньше supply-chain-риска
Встроенный JSON API теперь дефолт: вместо россыпи запросов все метаданные приезжают одной загрузкой, поэтому brew update быстрее и реже дёргает сеть. Опция была доступна через HOMEBREW_USE_INTERNAL_API ещё с 5.0.0 — теперь эта переменная задепрекейчена за ненадобностью.
Но в той же теме спрятана менее заметная, зато концептуально важная штука — cooldowns. Homebrew добавил «период охлаждения» на свежие релизы из рискованных экосистем: Bundler, RubyGems, npm, pip, PyPI. Зачем? Это прямая защита от классического сценария supply-chain-атаки: злоумышленник публикует скомпрометированную версию пакета и рассчитывает, что её мгновенно подхватят авто-обновления по всему миру. Cooldown ломает этот темп — Homebrew не бросается тянуть только что опубликованный релиз, давая времени отловить заразу. Мелочь, которая отражает зрелое понимание модели угроз.
Три CVE: что именно чинили
Чтобы было предметно, вот три закрытых уязвимости — это буквально учебник по той поверхности, которую весь релиз и сужает:
🚨 GHSA-7699-qf8c-q47m — POST-стратегия загрузки обходила защиту от HTTPS→HTTP-редиректа, отбрасывая разрешённый URL. То есть открывался путь к downgrade-атаке: тебя по-тихому спускают с защищённого канала на незащищённый. Починили принудительным enforce'ом безопасных редиректов.
🚨 GHSA-6689-q779-c33m — исполнение кода с правами root через Git-хуки в postinstall macOS-инсталлятора (.pkg). Починили очисткой git-состояния Homebrew и заменой git-директории инсталлятора.
🚨 GHSA-59v8-x8q4-px5c — macOS-инсталлятор доверял plist-файлу в /var/tmp, контролируемому пользователем, и мог отдать владение Homebrew локальному атакующему. Классический privilege escalation. Починили обработкой package-user plist.
Плюс из практичного для security-гигиены — новая команда brew vulns, которая проверяет установленные пакеты на известные уязвимости. Важный нюанс, который стоит знать: это не core-команда, а отдельный тап (homebrew-brew-vulns) с подкомандой — то есть её нужно подключить отдельно (и, по новой логике, доверить).
Чуть тише, но полезно: ask-режим по умолчанию
По итогам пользовательского опроса Homebrew переключил кучу дефолтов, и самый заметный — режим ask теперь включён по умолчанию для разработчиков. Перед brew install и brew upgrade ты увидишь сводку зависимостей и запрос подтверждения. Конец эпохе, когда невинный апгрейд внезапно тянул за собой лавину из полусотни пакетов. Заодно прикрутили подтверждение одной клавишей и общий fetch апгрейдов, чтобы это не превращалось в пытку.
macOS 27 Golden Gate и закат Intel: тут часики тикают
А вот пункт, который для части читателей самый практичный. macOS 27 (Golden Gate) окончательно роняет поддержку Intel, и Homebrew синхронизирует с этим свои Support Tiers по жёсткому графику:
📅 Сентябрь 2026 — Intel x86_64 уезжает на Tier 3: без CI-поддержки и без новых бинарных бутылок. На практике это значит, что свежие пакеты придётся собирать из исходников локально — а это долго, прожорливо и иногда просто не собирается.
📅 Сентябрь 2027 — Intel x86_64 полностью снимается с поддержки, весь связанный код удаляется.
Если вы (или ваш CI, или ваша команда) ещё сидите на Intel-маках — это не «когда-нибудь потом», а конкретный обратный отсчёт. Год до режима «всё из сорцов» и два — до полного прощания. Планировать миграцию на Apple Silicon (или Linux) стоит начинать уже сейчас.
Бонус: эксперимент brew-rs закрыли — и честно объяснили почему
Отдельно отмечу историю, которая мне импонирует чисто по-инженерному. Homebrew экспериментировал с переносом части Ruby-фронтенда на Rust (brew-rs) — и свернул эксперимент. Причина: бенчмарки показали, что Rust-фронтенд выигрывал только на узких, уже закешированных загрузках бутылок, но не на репрезентативных полных установках (где основное время — это разлив бутылок, линковка, запись метаданных и health-checks). Поэтому фокус производительности вернули обратно в Ruby и в то, чтобы раньше стартовать полезный сетевой и дисковый I/O.
Это правильное, не модное решение: команда убила собственный rewrite, потому что данные его не подтвердили, и опубликовала честный разбор — заодно мягко поддев неофициальные фронтенды, которые «не всегда применяют ту же строгость к своим бенчмаркам, совместимости и безопасности». В мире, где «перепишем на Rust» нередко работает как карго-культ, такая интеллектуальная честность дорогого стоит.
Выводы и прогноз
Если выпарить релиз до сути:
🔑 Это релиз про supply-chain security, а не про фичи. Tap trust, песочница на Linux, install steps framework и cooldowns — не четыре отдельных пункта, а грани одного движения: системно сокращать произвольное исполнение кода на вашей машине. Это defense in depth поверх старого, но рабочего фундамента Homebrew (живое ревью всех изменений, все мейнтейнеры пакетов — мейнтейнеры Homebrew).
🔑 Linux наконец перестал быть слабым звеном. Bubblewrap-песочница уравнивает Linux с macOS — критично для CI на Ubuntu и серверной разработки.
🔑 Intel-маки на таймере. Сентябрь 2026 — конец новым бутылкам, сентябрь 2027 — конец поддержки. Это единственный пункт, требующий действий уже сегодня.
🔑 Практичные мелочи на каждый день: ask-режим по умолчанию (нет внезапным лавинам), brew vulns для скана уязвимостей (не забыть, что это отдельный тап), более быстрый brew update за счёт единого JSON-дауплоада.
Мой прогноз простой. То, что делает Homebrew, — это шаблон, по которому в ближайшие годы пойдут и другие пакетные менеджеры: декларативные метаданные вместо произвольного кода + песочница по умолчанию + охлаждение свежих релизов. Бэкдор в xz и волна атак на npm/PyPI всем наглядно показали, что модель «подключи репозиторий и выполни что угодно с правами пользователя» больше не проходит. Homebrew 6.0.0 — это, по сути, картина того, как выглядит пакетный менеджер, повзрослевший в пост-xz эпоху. И движется он, на мой взгляд, ровно в нужную сторону — пусть и ценой того, что теперь придётся осознанно нажимать «я этому доверяю». Что, если вдуматься, и должно было быть с самого начала.
Источники
🔗 Анонс Homebrew 6.0.0 (оригинал новости): https://brew.sh/2026/06/11/homebrew-6.0.0/
🔗 Документация Tap-Trust: https://docs.brew.sh/Tap-Trust
🔗 Документация Supply-Chain-Security: https://docs.brew.sh/Supply-Chain-Security
🔗 Support Tiers (график deprecation Intel): https://docs.brew.sh/Support-Tiers
🔗 GHSA-7699-qf8c-q47m (HTTPS→HTTP redirect bypass): https://github.com/Homebrew/brew/security/advisories/GHSA-7699-qf8c-q47m
🔗 GHSA-6689-q779-c33m (root RCE через git-хуки в .pkg): https://github.com/Homebrew/brew/security/advisories/GHSA-6689-q779-c33m
🔗 GHSA-59v8-x8q4-px5c (privilege escalation через /var/tmp plist): https://github.com/Homebrew/brew/security/advisories/GHSA-59v8-x8q4-px5c
🔗 Тап brew vulns: https://github.com/Homebrew/homebrew-brew-vulns