Официальное объявление runner-images указывает на план изменения CLI openssl по умолчанию в образах macOS 26 и Xcode 27: с OpenSSL 3.x на OpenSSL 4.x. Плановый интервал развёртывания — с 2 ноября по 8 ноября 2026 года. Это объявленный график, а не подтверждение, что обновление уже появилось во всех запусках или что затронет каждый macOS runner. Проверяйте актуальное объявление и записи выпусков образов, прежде чем менять производственный workflow.

Объявление также указывает, что OpenSSL 3 остаётся доступен через версионированный путь Homebrew. Если вашему workflow нужна именно эта версия, её следует выбирать явно и проверять путь вызова; полагаться на неизменность системного значения по умолчанию нельзя. Официальное предупреждение рекомендует проверить задачи, связанные с сертификатами, ключами, подписью и TLS, но не утверждает, что все такие задачи ломаются.

Для решения важно не смешивать несколько разных состояний:

• OpenSSL установлен — пакет присутствует на машине.
• CLI по умолчанию — команда, которую shell найдёт первой при обращении к имени openssl.
• PATH workflow — порядок каталогов именно в запущенном задании и именно на момент вызова.
• Динамическая зависимость — библиотека, с которой собранный компонент связан при запуске.
• Конфигурация собственного Mac — установленные инструменты и переменные на вашем узле, которые не обязательно совпадают с hosted-образом.

Наличие OpenSSL 3 и 4 одновременно не доказывает, что сборка использует нужный бинарный файл или библиотеку. Кроме того, успешная команда openssl version в отдельном терминале не подтверждает выбор версии в CI: другой shell, action или скрипт мог изменить PATH. Сначала подтвердите путь и версию в том же контексте, где возникает сбой.

Разделите проблему на наблюдаемый симптом и проверяемое действие. Ошибка TLS-соединения сама по себе не доказывает смену OpenSSL: причиной могут быть конечная точка, сетевой доступ, доверенная цепочка или учётные данные. Чтобы не смешать эти причины, начните с конкретной команды, которая завершилась ошибкой, и восстановите её входные данные и окружение.

• Изменился результат сертификатной команды. Повторите операцию на безопасном тестовом сертификате. Сверьте код выхода, распознанные атрибуты и проверку цепочки. Затем сравните точную команду, флаги и входные данные с последним успешным запуском. Если отличаются входной файл или набор доверенных сертификатов, сперва устраните это расхождение.
• Не проходит обработка ключа или подписание. В изолированном задании проверьте загрузку тестового ключа и выпуск тестового артефакта через тот же этап workflow. Не печатайте ключ, пароль или секрет в журнал. Доступ к секрету проверяйте отдельно от совместимости команды, иначе отказ в разрешениях можно ошибочно принять за изменение поведения OpenSSL.
• Скрипт не принимает вывод проверки TLS. Найдите в логе конкретный вызов и выясните, сравнивает ли сценарий фиксированный текст, формат или код завершения. Повторите запрос отдельно и проверьте его параметры по документации s_client. Если проверка основана на буквальном сравнении вывода, проверьте саму логику сценария и не считайте любое отличие текста доказательством нарушения TLS.
• Соединение не устанавливается. Зафиксируйте имя TLS-узла, результат DNS и сетевого подключения, наличие и корректность сертификата, а затем команду OpenSSL. Сопоставьте эти данные, чтобы не приписывать сетевой сбой изменению CLI. Проверьте также, происходит ли отказ до установления соединения или при проверке сертификата: это разные этапы диагностики.

Для проверок, зависящих от поведения TLS или текста вывода, сравните фактические параметры и ответ команды с руководством по миграции OpenSSL. Конкретный эффект зависит от операции, входных данных и сценария, поэтому проверяйте используемую команду, а не предполагайте различия по одному только номеру версии.

При работе с секретами выводите в журнал только диагностические сведения, разрешённые вашей политикой. Если шагу нужно сообщить о результате в интерфейсе workflow, используйте документированные команды GitHub Actions для управления выводом и сообщениями, не превращая лог в хранилище секретов. При необходимости сохраняйте код выхода и краткий статус проверки, а не содержимое ключа или полный вывод конфиденциальной операции.

Для начала добавьте временный диагностический шаг непосредственно перед командой, которая обычно выполняет криптографическую операцию:

- name: Diagnose OpenSSL selection
  run: |
    echo "PATH=$PATH"
    command -v openssl
    type -a openssl
    openssl version -a

Команда command -v показывает, что shell выберет при обращении к имени openssl. type -a помогает увидеть другие совпадения в пути поиска. openssl version -a выводит сведения о фактически запущенном CLI; назначение команды версии и её параметров описано в официальной документации OpenSSL.

Запускайте проверку в том же job и после тех шагов, которые меняют PATH. Если диагностическая команда выполнена в одном shell-контексте, а сборочная — в другом, её вывод может не отражать реальный выбор. При необходимости напечатайте результат непосредственно перед проблемной командой, а затем проверьте, не задаёт ли workflow, action или shell-сценарий собственный путь. Если путь добавляется через переменную окружения, проверьте, что эта настройка действует для последующего шага, а не только для завершившегося shell-процесса.

Проверьте также тип runner. У GitHub-hosted и self-hosted машин различаются способы управления средой; собственный Mac может иметь свою версию OpenSSL и свой PATH. В workflow проверьте runs-on по официальной документации о синтаксисе, а область hosted-исполнителей — по описанию GitHub-hosted runners. Изменение объявлено для названных образов, а не автоматически для всех macOS-хостов.

Практический сценарий: команда получает ошибку TLS после обновления образа, но на собственном Mac тот же шаг проходит. Вместо немедленного отката сравните в обоих окружениях runs-on, путь openssl, его версию, эффективный PATH и команду запроса. Если бинарный файл отличается — зафиксируйте выбор версии в workflow и повторите задачу. Если путь и версия одинаковы, продолжайте проверку сетевого маршрута, сертификата, конфигурации и входных данных. Сохраните эти сравнения рядом с номером сборки, чтобы следующий инженер мог повторить проверку без догадок.

Сбой компиляции или запуска зависимости следует связывать с OpenSSL только после проверки фактического места интеграции. Нативный пакет может явно выбирать версию, полагаться на каталог по умолчанию, читать переменные сборки или загружать библиотеку при исполнении. Проверьте build-скрипты, конфигурацию пакетного менеджера, параметры компилятора и сведения о линковке. Ошибка может быть в конфигурации поиска, а не в TLS или сертификатной команде.

Сравнивайте результаты на одной ревизии исходного кода. Для каждого прогона сохраните:

• путь и версию CLI перед сборкой;
• выбранные пути заголовков и библиотек, если сборочный инструмент их сообщает;
• команду конфигурации и компиляции;
• диагностические строки компилятора и линкера;
• результат запуска компонента и его тестов.

Установка нескольких версий без явного выбора — недостаточная проверка: это не доказывает, какой CLI использовал скрипт и с какой библиотекой связан результат. Изучите список команд OpenSSL и руководство по миграции, затем сопоставьте их с реальной командой проекта. Если сценарий задаёт переменные или параметры поиска, проверьте их значения в том же job; само наличие пакета не подтверждает, что компилятор выбрал ожидаемые заголовки и библиотеку.

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

Для сравнения не меняйте одновременно базовый образ, версию Xcode, пакетные зависимости и способ выбора OpenSSL. Иначе результат не покажет, какое изменение вызвало отклонение. Достаточно иметь сопоставимые прогоны на одной ревизии и документировать различающиеся условия. Если подтверждена проблема линковки, исправьте выбор библиотеки или конфигурацию сборки и повторите тест запуска: успешная компиляция сама по себе не гарантирует, что приложение загрузит ожидаемую библиотеку в рабочем задании.

Выбирайте версию по результатам вашего рабочего pipeline. Ниже — основная развилка: фиксировать проверенный OpenSSL 3, испытывать OpenSSL 4 или пока не расширять rollout.

Зафиксируйте версию явным способом, который подходит вашему окружению. Для OpenSSL 3 официальный анонс указывает на доступность версионированного Homebrew-пути. Не копируйте путь из старого лога вслепую: подтвердите его в текущем образе, добавьте требуемый каталог в PATH в рамках конкретного job и сразу выведите command -v openssl и openssl version -a. Задайте выбор рядом с задачей, которая от него зависит, чтобы последующее изменение окружения было обнаруживаемым.

Порядок проверки:

1. Зафиксируйте runner, ревизию workflow, затронутые команды и последний известный успешный прогон.
2. Создайте изолированный job или ветку workflow, не меняя основной путь публикации.
3. Проверьте PATH, путь бинарного файла и версию непосредственно перед сертификатными и TLS-вызовами.
4. Запустите реальные задачи на тестовых входных данных: сборку, обработку сертификата и ключа, подписание тестового артефакта и сетевую проверку.
5. Соберите журналы команд, результаты тестов и подтверждение линковки; удалите из них секреты и чувствительные входные данные.
6. Сравните результаты с проверенной конфигурацией на той же ревизии и зафиксируйте критерии возврата на прежний выбор версии.
7. Только после успешной проверки всех критичных путей включайте изменение в production-процесс; заранее определите ответственного за откат.

Версию можно считать принятой не потому, что хост доступен или отдельный шаг завершился успешно. Допуск требует подтверждения ключевых сборок, операций с сертификатами и подписью, TLS-сценариев и зависимостей. Для публикации проверьте ещё и конечный результат: подпись и полученный артефакт должны соответствовать вашим правилам выпуска. Храните доказательства так, чтобы по ним можно было восстановить runner, выбранный OpenSSL и результаты каждого проверенного этапа.

Если проверка не прошла, зафиксируйте, какая именно команда дала отклонение, и вернитесь к явно заданной ранее проверенной версии. Если все важные задания прошли на новой версии, путь подтверждён в логах, а возврат проверен, можно расширять её применение по принятой в компании процедуре. Один зелёный smoke test без проверки публикации не является достаточным основанием для допуска.

Для команды, которой нужен отдельный Mac для воспроизводимой проверки, выбор удалённой машины не отменяет эти критерии: всё равно придётся подтвердить реальный PATH, инструменты, доступы и результаты CI. Если вы оцениваете такой узел как отдельную среду, сопоставьте задачи и требования к доступу с условиями заказа Mac и заранее определите, какие именно проверки будут выполняться на нём. Информация о доступных вариантах удалённого Mac поможет оценить формат среды, но не является подтверждением совместимости конкретной версии OpenSSL или вашего workflow.

Когда ждать изменения версии по умолчанию

Плановый интервал — с 2 по 8 ноября 2026 года для образов macOS 26 и Xcode 27, согласно официальному объявлению runner-images. Проверяйте также актуальные выпуски образов: дата в объявлении не подтверждает фактическое состояние каждого runner. До переключения используйте результаты собственного workflow, а не один лишь план обновления.

Как отличить OpenSSL 3 от OpenSSL 4 в сценарии

В проблемном job выведите command -v openssl, type -a openssl и openssl version -a. Делайте это после настройки PATH и непосредственно перед вызовом, который нужно диагностировать. Сохранённый путь вместе с выводом версии помогает отличить наличие пакета от фактического выбора shell. При необходимости проверьте также переменные окружения и скрипты, которые могли изменить путь поиска.

Что включить в проверку сертификатов и ключей

Повторите рабочие операции в изоляции на тестовых данных. Проверяйте код завершения, распознавание сертификата, результат проверки цепочки и итог подписи. Не выводите приватный ключ или пароль в логи; доступ и хранение секретов проверяйте отдельно. При отклонении сравните входные данные и параметры команды с последним подтверждённым прогоном.

Как подтвердить связь ошибки зависимости с OpenSSL

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

Если сейчас вы полагаетесь только на образ hosted runner, вы принимаете его обновления по умолчанию и можете иметь ограниченный контроль над состоянием конкретной машины. Если обслуживаете собственный Mac, контроль выше, но на вашей команде остаются обслуживание, доступы и проверка конфигурации. Арендованный удалённый Mac может быть отдельной средой для проверки CI, когда нужна дополнительная управляемая рабочая площадка. Его пригодность следует подтвердить по требованиям проекта и условиям поставки, а не предполагать поддержку конкретной версии OpenSSL. Сначала зафиксируйте вызываемый бинарный файл и критерии приёмки, затем сравните их с вашим pipeline и условиями удалённого доступа.