Безопасность Homebrew и цепочка поставок

Homebrew устанавливает программное обеспечение из всей экосистемы открытого исходного кода. Поэтому безопасность цепочки поставок ПО — людей, участвующих в процессе, репозиториев, систем сборки и серверов загрузки, которые превращают исходный код в программы, запускаемые на вашем компьютере, — имеет для нас первостепенное значение. В этом руководстве по безопасности Homebrew рассказывается о недавних инцидентах безопасности цепочки поставок в других пакетных менеджерах, о том, чем отличается модель доверия Homebrew, и о шагах, предпринятых нами для защиты пользователей.

• Недавние инциденты в других экосистемах
• Чем отличается Homebrew
  • Проверка человеком всех изменений
  • Сопровождающие, а не владельцы пакетов
  • Курируемые пространства имён пакетов
  • Отсутствие доверия к сторонним репозиториям
  • Отсутствие автоматического следования указаниям upstream
  • Загрузки с контрольными суммами, закреплёнными в проверенных метаданных
  • Подписанные метаданные JSON API
  • Бинарные пакеты, собранные Homebrew
  • Подтверждения происхождения бинарных пакетов
  • Многоуровневая инфраструктура с перекрёстными проверками
  • Собственная цепочка поставок Homebrew
  • Статический анализ и линтинг
  • Безопасное и ответственное использование ИИ
  • По умолчанию при установке не выполняется произвольный код
  • Изоляция в песочнице
  • Фильтрация окружения
  • Для cask-пакетов действует другая модель доверия
  • Период ожидания для более рискованных экосистем
  • Приоритет безопасности над обратной совместимостью
• Сравнение моделей доверия
• Дальнейшие планы

Недавние инциденты в других экосистемах

Экосистемы npm и PyPI неоднократно становились мишенями атак на цепочки поставок. Среди повторяющихся сценариев:

• Захват учётных записей сопровождающих. Злоумышленники выманивают данные для входа или подбирают учётные данные учётной записи сопровождающего пакета, а затем публикуют вредоносную версию пакета, которому обычно доверяют. В сентябре 2025 года сопровождающего широко используемых пакетов npm (включая chalk и debug, в совокупности насчитывающих миллиарды загрузок в неделю) обманули с помощью письма, выдававшего себя за запрос на сброс двухфакторной аутентификации npm. Вредоносные версии были доступны около двух часов и содержали криптовалютный похититель, подменявший адреса кошельков в транзакциях.
• Самораспространяющиеся черви. В кампании «Shai-Hulud» против npm скомпрометированный пакет похищал учётные данные (токены npm, персональные токены доступа GitHub и облачные ключи) у каждого разработчика, установившего его, а затем использовал украденные токены для автоматической публикации троянизированных версий других пакетов, распространяясь на сотни пакетов без участия человека.
• Тайпосквоттинг и слопсквоттинг. Вредоносные пакеты публикуются под именами, похожими на имена популярных пакетов, или под правдоподобными названиями, выдуманными большими языковыми моделями, чтобы из-за опечатки или чрезмерного доверия к ИИ-агенту пользователь установил вредоносное ПО.
• Вредоносный код, выполняемый при установке. И npm (скрипты жизненного цикла preinstall/postinstall), и PyPI (произвольный код в setup.py) по своему устройству выполняют код, контролируемый издателем, на компьютере, где устанавливается пакет. Поэтому после одной недобросовестной публикации код сразу запускается на каждом компьютере, где устанавливают этот пакет.
• Мгновенная публикация без проверки. Новая версия становится доступна всему миру сразу после публикации. Проверка человеком и задержка отсутствуют, поэтому скомпрометированный релиз может попасть на огромное количество компьютеров до того, как кто-нибудь это заметит.

Общее для этих ситуаций — реестры рассчитаны на одностороннюю мгновенную публикацию отдельными авторами пакетов, выполнение кода при установке и отсутствие независимой проверки. В результате компрометация одной учётной записи приводит к немедленному автоматизированному выполнению кода по всему миру.

Чем отличается Homebrew

Команде Homebrew известны проблемы безопасности цепочки поставок в других пакетных менеджерах. Архитектура Homebrew отличается несколькими особенностями, которые ограничивают масштабы последствий компрометации upstream. Большинство этих мер защиты появились задолго до недавней волны атак на цепочки поставок и нынешнего внимания к ним: они лежат в основе того, как Homebrew всегда упаковывал ПО, а не являются реакцией на какой-либо отдельный инцидент.

Проверка человеком всех изменений

Любое изменение в репозитории Homebrew, в том числе во всех наших официальных tap-репозиториях (например, homebrew/core и homebrew/cask), проходит через pull request, который проверяет и принимает сопровождающий-человек. Авторы upstream не могут публиковать изменения напрямую в официальные репозитории Homebrew. Между выпуском upstream и появлением этого выпуска у пользователей Homebrew всегда есть проверка человеком. Процесс одобрения pull request ведущими сопровождающими для устаревших PR — узкое исключение Homebrew/brew: он может одобрять только PR не из форков и не в черновом статусе, созданные ведущими сопровождающими, при условии недавней активности сопровождающего по проверке, проверки Copilot, успешного прохождения CI, отсутствия проверок человеком в течение как минимум 48 часов после открытия, одобрения в рабочий день и проверки того, что PR не изменяет чувствительные пути. Такие менее строгие требования допустимы в Homebrew/brew, потому что большинство пользователей работает со стабильной веткой, а для попадания этих изменений к пользователям стабильной версии Homebrew человеку всё равно необходимо выполнить выпуск Homebrew/brew.

Сопровождающие, а не владельцы пакетов

Все сопровождающие пакеты являются сопровождающими Homebrew, а не отдельными авторами upstream каждого пакета. Доверие сосредоточено в проверенной команде, которая проверяет изменения во всём репозитории, а не делегировано тысячам независимых издателей, каждый из которых может стать единственной точкой отказа.

Доступ и активность сопровождающих регулярно проверяются. От сопровождающих ожидается минимальное количество значимых вкладов каждый квартал; те, кто не достигает этого порога, получают личное предупреждение, а если остаются неактивными, их исключают из команды. Сопровождающие также должны включить двухфакторную аутентификацию в своей учётной записи GitHub, не использовать SMS в качестве второго фактора и регулярно удалять ненужные персональные токены доступа. Это снижает вероятность захвата учётных записей, который приводил к компрометации других экосистем.

Курируемые пространства имён пакетов

Имена в официальных tap-репозиториях Homebrew выбираются сопровождающими, а не достаются по принципу «кто первый занял». Новое имя формулы или cask-пакета принимается только в рамках того же процесса рассмотрения pull request, что и само описание пакета. Поэтому опечаточные подделки, слопсквоттинг и вводящие в заблуждение имена можно отклонить ещё до их появления в официальном пространстве имён. Восстановить удалённые формулы и cask-пакеты можно только через pull request, проверенный сопровождающими; как правило, мы не используем повторно старые имена без веской причины. Посторонние не могут единолично присваивать удалённые имена: старые имена остаются под контролем Homebrew благодаря официальным репозиториям, метаданным переименования и метаданным миграции. Благодаря этому официальное пространство имён Homebrew структурно защищено от тайпосквоттинга и атак с перехватом восстановленных имён, которым подвержены открытые реестры.

Отсутствие доверия к сторонним репозиториям

Homebrew не доверяет сторонним репозиториям, не рекомендует их и не устанавливает из них ПО автоматически. По умолчанию доверие распространяется только на официальные tap-репозитории Homebrew и встроенные команды. Неофициальный tap — это исполняемый код, а не обычные метаданные, поэтому его загрузка может запустить Ruby с правами вашего пользователя. Homebrew переходит к требованию явного доверия для неофициальных tap-репозиториев, а brew trust позволяет доверять отдельной формуле, cask-пакету или команде, а не всему tap-репозиторию. О том, как доверять только тому, что вам нужно, а также о недавно добавленных настройках управления brew trust, brew untrust и Brewfile trusted: true, см. раздел Доверие к tap-репозиториям.

Миграции tap-репозиториев Homebrew остаются внутри организации Homebrew: формула или cask-пакет перемещается только в официальные tap-репозитории Homebrew или между ними, но никогда — в сторонний tap-репозиторий. Поэтому переименование или перемещение не может незаметно перенаправить пользователей в сторонний репозиторий. Если GitHub перенаправляет tap-репозиторий после переименования его владельца или репозитория, Homebrew следует проверенному перенаправлению, направляет локальный tap на новый канонический удалённый репозиторий и аннулирует записи доверия для старого имени tap-репозитория, а не переносит доверие незаметно.

Отсутствие автоматического следования указаниям upstream

Главная ответственность Homebrew — перед пользователями, а не перед поставщиками upstream. Обычно мы не будем объявлять пакет устаревшим, отключать или удалять его либо перенаправлять его в upstream tap-репозиторий только потому, что этого просит upstream: технические проблемы, нарушения политик или потребности всего проекта важнее. Это также защита от компрометации upstream: злоумышленник, захвативший учётную запись upstream, не может с помощью запроса на удаление или перенаправление побудить пользователей Homebrew перейти на вредоносную замену. См. раздел Взаимодействие с Homebrew в качестве upstream-проекта.

Загрузки с контрольными суммами, закреплёнными в проверенных метаданных

В формуле для каждой загрузки указана конкретная контрольная сумма sha256, которая хранится в файле формулы. Контрольная сумма входит в изменение, проверяемое человеком, и Homebrew отказывается устанавливать загруженный файл, если его содержимое не соответствует ей. Если злоумышленник подменит архив на сервере upstream после публикации, это приведёт к несовпадению контрольной суммы и сбою установки, а не к незаметной компрометации. Для обновления контрольной суммы требуется ещё один проверенный pull request; мы проверяем такие изменения, чтобы убедиться, что они не выглядят вредоносными.

Подписанные метаданные JSON API

Формулы и cask-пакеты — это определения пакетов на Ruby, а безопасно проверить код Ruby, не выполняя его, невозможно. Для установок по умолчанию из официальных tap-репозиториев Homebrew снижает риск, используя предварительно сформированные метаданные JSON API вместо локального выполнения кода Ruby формул или cask-пакетов из core. Файлы API по умолчанию, включая formula.jws.json, cask.jws.json и внутренние файлы JSON пакетов, используемые при установке, подписаны в формате JWS и проверяются Homebrew перед использованием. Это означает, что при обычной установке бинарных пакетов используются подписанные структурированные данные пакетов, сформированные Homebrew, а не исполняемые определения пакетов с локального компьютера пользователя. Эти подписанные файлы загружаются через отдельный репозиторий Homebrew/formulae.brew.sh, что обеспечивает дополнительное разделение между клиентом Homebrew/brew, репозиториями пакетов Homebrew/homebrew-core и Homebrew/homebrew-cask и публикацией JSON API. Разработчики и пользователи могут отключить этот механизм с помощью HOMEBREW_NO_INSTALL_FROM_API, например при локальном редактировании формул или сборке из исходного кода по неподдерживаемым сценариям.

Бинарные пакеты, собранные Homebrew

Подавляющее большинство пользователей устанавливает бинарные пакеты — предварительно скомпилированные пакеты, которые Homebrew самостоятельно собирает на BrewTestBot по проверенной формуле, вместо запуска скриптов сборки upstream на собственном компьютере. Формулы homebrew/core собираются из исходного кода собственной изолированной средой CI Homebrew, а не загружаются от upstream в виде заранее собранных пакетов. Каждая сборка выполняется на временном исполнителе CI, который после этого уничтожается, поэтому скомпрометированная сборка не может сохраниться между сборками пакетов или похитить долгосрочные секреты. Контрольные суммы указываются и для итоговых бинарных файлов. Даже отдельные этапы подготовки бинарных пакетов не доверяют безоговорочно входным и выходным данным друг друга. brew test-bot отслеживает JSON-файлы бинарных пакетов и контрольные суммы архивов, отклоняет отсутствующие, изменённые или неожиданные артефакты и повторно использует кэшированный пакет только в том случае, если его JSON-файл указывает на ревизию tap-репозитория, в которой формула и её соответствующие зависимости не изменились. Некоторые этапы обработки артефактов выполняются с помощью HOMEBREW_DISABLE_LOAD_FORMULA=1, поэтому кэшированные артефакты можно загрузить и проверить, не выполняя код Ruby формулы. Сборка из исходного кода уже защитила пользователей Homebrew: во время компрометации Trivy в 2026 году в уведомлении upstream указывалось, что формула homebrew/core не пострадала, поскольку была собрана из исходного кода, а не из бинарных файлов перевыпущенного релиза.

Homebrew собирает и поддерживает бинарные пакеты только для homebrew/core, а cask-пакеты — для homebrew/cask; сторонние tap-репозитории не поддерживаются. Если вы отклоняетесь от поддерживаемых сценариев — например, собираете ПО из исходного кода или устанавливаете его из недоверенного tap-репозитория, — Homebrew явно предупреждает, что такая конфигурация не поддерживается.

Подтверждения происхождения бинарных пакетов

Контрольные суммы подтверждают, что загруженные байты соответствуют проверенным метаданным. Подтверждения происхождения бинарных пакетов обеспечивают другую проверку: кто собрал эти файлы и из какого исходного кода. Проверка подтверждений для бинарных пакетов доступна в Homebrew с версии Library/Homebrew/attestation.rb; если задано HOMEBREW_VERIFY_ATTESTATIONS, Homebrew использует инструменты проверки подтверждений GitHub, чтобы перед установкой проверить подтверждения происхождения сборки бинарного пакета homebrew/core. CI Homebrew также создаёт подтверждения для бинарных пакетов с помощью actions/attest, связывая артефакты с идентификатором GitHub Actions и контекстом сборки, в которых они были созданы. Мы надеемся в будущем включить проверку подтверждений по умолчанию, когда её можно будет реализовать на чистом Ruby, не полагаясь на инструмент gh.

Эти подтверждения опираются на журнал прозрачности Sigstore — единственную в этом конвейере перекрёстную проверку, размещённую не на GitHub. Злоумышленнику, способному загрузить бинарный пакет и изменить размещённые на GitHub метаданные, всё равно потребуется создать соответствующее публично зарегистрированное подтверждение происхождения для ожидаемого идентификатора сборки Homebrew.

Многоуровневая инфраструктура с перекрёстными проверками

Конвейер Homebrew разделён между несколькими компонентами: клиентом Homebrew/brew, который большинство пользователей запускает из помеченных стабильных выпусков, а не из последнего коммита; репозиториями формул и cask-пакетов Homebrew/homebrew-core и Homebrew/homebrew-cask; JSON API formulae.brew.sh, который формируется и обслуживается через GitHub Pages; а также бинарными пакетами homebrew/core, размещёнными в GitHub Packages.

Все эти компоненты размещены на GitHub, а не на полностью раздельной инфраструктуре, поэтому они не образуют полностью независимые границы доверия. Тем не менее они взаимно проверяют друг друга. Например, токен, получивший доступ к GitHub Packages, может быть использован для загрузки вредоносного бинарного пакета, но контрольная сумма этого пакета не будет соответствовать значению sha256, записанному в размещённом на GitHub репозитории. А изменение контрольной суммы требует pull request, проверенного сопровождающим-человеком. Подписанный JSON API и подтверждения происхождения бинарных пакетов обеспечивают дополнительные перекрёстные проверки: метаданные API должны пройти проверку по ключу подписи JWS Homebrew, а происхождение бинарного пакета должно быть подтверждено ожидаемым идентификатором сборки и публичным журналом прозрачности. Поэтому для атаки на пользователей злоумышленнику необходимо одновременно скомпрометировать несколько компонентов.

Поскольку большая часть этой системы опирается на GitHub, мы включаем все новые функции безопасности GitHub сразу, как только это становится возможным. К ним относятся обязательная двухфакторная аутентификация, запрет SMS в качестве второго фактора, обязательная защита веток во всех репозиториях Homebrew и неизменяемые выпуски GitHub. Обновления Dependabot открываются через pull request с периодом ожидания в репозиториях Homebrew, поэтому автоматизация самого пакетного менеджера не получает сразу только что опубликованный выпуск зависимости. Файл конфигурации Dependabot, хранящийся в репозитории, синхронизируется из общего репозитория Homebrew/.github, что помогает поддерживать единые правила для общих файлов политики во всех репозиториях Homebrew. Homebrew также сводит к минимуму число владельцев организации GitHub и ограничивает доступ с высокими привилегиями в 1Password лицами и командами, указанными в документах Управление Homebrew и Контрольный список для новых сопровождающих. События pull request с высокими привилегиями используются редко: проверка pull request — единственный процесс pull_request_target в этом репозитории; он отказывается запускаться после извлечения кода и читает только доверенные файлы базовой ветки через GitHub API. В большинстве процессов избегают actions/checkout, если извлечение кода не требуется; когда его используют, версию закрепляют и обычно задают persist-credentials: false. Процесс одобрения pull request ведущими сопровождающими для устаревших PR может одобрять только PR Homebrew/brew не из форков и не в черновом статусе, которые соответствуют требованиям проверки и CI и поступили в рабочее время; он также отказывается одобрять изменения чувствительных путей.

Собственная цепочка поставок Homebrew

Сам Homebrew — это код Ruby, распространяемый из репозитория Homebrew/brew. Большинство пользователей запускает помеченные стабильные выпуски; режим разработчика может отслеживать последний коммит в main, но для обычных пользователей это не сценарий по умолчанию. Зависимости Homebrew для Ruby во время выполнения включены непосредственно в репозиторий и закреплены в Library/Homebrew/Gemfile.lock, а не разрешаются при каждом запуске из RubyGems во время обычного выполнения brew. Обновления этих зависимостей проверяются так же, как и другие изменения Homebrew; период ожидания Dependabot обеспечивает дополнительную задержку для недавно опубликованных выпусков гемов. Это уменьшает поверхность атаки в собственной цепочке зависимостей пакетного менеджера — уязвимом месте, которое регулярно встречается в экосистемах, где плагины пакетного менеджера или библиотеки времени выполнения разрешаются динамически во время выполнения.

Статический анализ и линтинг

Homebrew предпочитает «максимум проверок линтерами», поскольку автоматическая проверка помогает выявлять целые классы ошибок в цепочке поставок ещё до того, как их придётся обнаруживать вручную. Для Ruby brew style рекомендует по возможности включать стандартные cop-проверки RuboCop, а затем добавлять специфичные для Homebrew проверки RuboCop из Library/Homebrew/rubocops, охватывающие правила пакетного менеджера, о которых универсальные инструменты Ruby знать не могут. Для кода оболочки и конфигураций рабочих процессов CI запускает ShellCheck, actionlint и zizmor; zizmor загружает результаты анализа безопасности рабочих процессов GitHub Actions в формате SARIF, а общая политика .github zizmor обеспечивает единые правила закрепления действий Homebrew во всех репозиториях. Для проверки типов brew typecheck использует Sorbet, а Homebrew применяет # typed: strict ко всем возможным файлам Ruby, не относящимся к тестам; небольшое число загрузочных файлов, которые загружаются до обычной поддержки среды выполнения, по возможности проверяются с помощью объявлений типов RBI и статических проверок. brew lgtm объединяет проверку типов, исправление стиля в изменённых файлах и соответствующие тесты, благодаря чему локальные проверки и CI используют одни и те же ограничения. В статье Майка Маккуэйда Ruby под защитой ограждений описана общая философия: автоматизировать шумные повторяющиеся проверки, чтобы проверяющие могли сосредоточиться на корректности, безопасности и взвешенных решениях.

Безопасное и ответственное использование ИИ

Изменения с помощью ИИ рассматриваются как недоверенные вклады, а не как способ обойти модель проверки Homebrew. Руководство Homebrew по ответственному использованию ИИ требует, чтобы авторы до передачи изменений сопровождающим проверили, поняли и протестировали работу, выполненную с помощью ИИ, и сообщили об использовании ИИ. Авторам, использующим агентов, рекомендуется изолировать их с помощью изолированных рабочих деревьев git, ограниченных учётных данных и отдельных веток, как описано в статье Майка Маккуэйда об изолированных рабочих деревьях для агентов. К работе с помощью ИИ по-прежнему применяются все описанные здесь меры защиты: небольшие изменения, проверка человеком, brew lgtm, CI, доверие к tap-репозиториям и изолированное выполнение пакетов. Это позволяет использовать ИИ для автоматизации, сохраняя ответственность человека и многоуровневые проверки, на которые полагается Homebrew.

По умолчанию при установке не выполняется произвольный код

Установка бинарного пакета распаковывает проверенные файлы, собранные заранее. Сборка из исходного кода выполняется в песочнице (см. ниже). Выполнение этапа post_install формулы — как при установке бинарного пакета, так и при сборке из исходного кода — может запустить программное обеспечение, предоставленное upstream, но и в этом случае оно выполняется в песочнице.

Изоляция в песочнице

Сборки, этапы post_install и тесты выполняются в песочнице, ограничивающей доступ к файловой системе и сети:

• Песочница в macOS уже давно изолирует сборку формул.
• Песочница в Linux обеспечивает такую же защиту для Homebrew в Linux.
• Ограничение чтения чувствительных данных не позволяет коду сборки и тестов читать чувствительные части домашнего каталога (например, учётные данные и ключи SSH), ограничивая объём данных, которые вредоносная сборка могла бы похитить.

Фильтрация окружения

Сборки Homebrew выполняются в отфильтрованном, очищенном окружении, а не в полном окружении вашей оболочки. Это не позволяет раскрыть секреты и неожиданную конфигурацию из вашего окружения коду сборки и тестов.

Для cask-пакетов действует другая модель доверия

Cask-пакеты устанавливают готовые приложения непосредственно от поставщика, а не из бинарного пакета, собранного Homebrew, поэтому их модель доверия неизбежно слабее, чем у формул. Homebrew проверяет описание cask-пакета и, если возможно, контрольную сумму sha256 загружаемого файла, однако в некоторых cask-пакетах задано sha256 :no_check, потому что upstream url не меняется между выпусками, а во многих задано auto_updates true, указывающее, что приложение обновляется самостоятельно. Для таких cask-пакетов поставщик, а не Homebrew, контролирует файлы, которые вы в итоге запускаете; приложения с автообновлением загружают последующие версии уже вне Homebrew. После принятия cask-пакета действия по установке приложения поставщика считаются доверенными, поэтому предпочитайте cask-пакеты от поставщиков, которым вы доверяете.

Тем не менее в худшем случае установка cask-пакета не менее безопасна, чем самостоятельная загрузка и запуск того же ПО непосредственно с сайта поставщика, что и является реалистичной альтернативой. В лучшем случае, если в cask-пакете закреплена sha256, Homebrew дополнительно гарантирует, что загружаемый файл не изменился с момента проверки сопровождающим. Это гораздо безопаснее, чем загрузка вручную без проверки.

Период ожидания для более рискованных экосистем

Для экосистем с историей быстро развивающихся атак на цепочки поставок Homebrew вводит период ожидания перед загрузкой: недавно опубликованная upstream-версия не принимается сразу, чтобы у сообщества было время обнаружить и сообщить о вредоносном выпуске до того, как он затронет пользователей Homebrew. Период ожидания введён для:

• Bundler
• livecheck RubyGems
• настроек по умолчанию для npm и pip
• разрешения зависимостей ресурсов PyPI
• npm и PyPI в bump

Homebrew применяет период ожидания адресно, только к тем языковым экосистемам, которые действительно подвергались быстро развивающимся атакам на цепочки поставок, а не задерживает обновление каждого пакета. Общий период ожидания означал бы небольшое, гипотетическое снижение риска для цепочки поставок ценой реальной задержки критически важных исправлений для всех пакетов: когда в используемой повсеместно программе вроде OpenSSL обнаруживается уязвимость нулевого дня, Homebrew старается как можно быстрее предоставить пользователям исправление. Кроме того, архитектура Homebrew означает, что обновление одного пакета может потребовать обновления других. За всю историю Homebrew гораздо больше пользователей получили защиту благодаря быстрой доставке исправлений уязвимостей нулевого дня, чем пострадали от атак с кражей токенов или майнингом криптовалюты, подобных атакам на npm. Поэтому общий период ожидания ухудшил бы безопасность большинства пользователей. Более глубокая причина, по которой Homebrew не нужен общий период ожидания, заключается в том, что, в отличие от пакетных менеджеров языков программирования, он уже отделяет публикацию от распространения: upstream-выпуск доходит до пользователей только после проверки человеком, CI и подтверждения контрольной суммы. Именно такое окно для проверки пытаются создать периоды ожидания в языковых экосистемах.

Homebrew также является пакетным менеджером с непрерывным выпуском обновлений, поэтому необходимо найти реальный баланс между немедленной доставкой согласованного исправления уязвимости нулевого дня, как в случае с уязвимостью Heartbleed в OpenSSL, и задержкой обновлений для смягчения атак на цепочки поставок. Учитывая нашу модель доверия, профиль рисков и широту поддерживаемых нами экосистем, мы предпочитаем применять период ожидания при обновлении upstream-пакета, а не вводить дополнительный период ожидания Homebrew для конечных пользователей при обновлении. Иначе возникнет «двойной период ожидания», который дважды задержит исправления безопасности почти без дополнительной пользы.

Приоритет безопасности над обратной совместимостью

Когда приходится выбирать между безопасностью и обратной совместимостью, Homebrew отдаёт приоритет безопасности. Политика объявления функций устаревшими и регулярные основные и промежуточные выпуски позволяют нам последовательно объявить рискованное поведение или значение по умолчанию устаревшим, затем отключить, а затем полностью удалить его в следующих выпусках — зачастую в течение примерно шести-девяти месяцев. Готовность нарушать совместимость в такие сроки во многом позволяет Homebrew быстрее реагировать на новые угрозы цепочке поставок, чем экосистемы, которым приходится бессрочно сохранять прежнее поведение.

Сравнение моделей доверия

Дальнейшие планы

Эта проблема не решена окончательно, и мы не утверждаем, что Homebrew неуязвим. Мы предприняли шаги для снижения этих рисков для пользователей. Некоторые меры действуют давно (песочница macOS, проверка человеком всех изменений, фильтрация окружения, все сопровождающие пакетов являются сопровождающими Homebrew), другие появились недавно (песочница Linux, ограничение чтения чувствительных данных, периоды ожидания для более рискованных экосистем). Мы продолжим следить за ситуацией с безопасностью цепочек поставок и при необходимости принимать дополнительные меры.