Переключение macOS CI на OpenSSL 4 не означает, что все сборки автоматически упадут. Сначала сравните фактическую версию и поведение команд в реальном Runner; если зависимость проекта пока требует OpenSSL 3, явно закрепите эту версию вместо того, чтобы полагаться на значение по умолчанию.

Этот материал предназначен инженерам, которые сопровождают GitHub Actions macOS Runner и хотят заранее найти уязвимые скрипты и сборки. Он пригодится разработчикам нативных зависимостей, а также Ruby- и Python-проектов с интеграцией OpenSSL. Руководителям DevOps он поможет выбрать между адаптацией, фиксацией версии и временной отсрочкой переключения.

Последнее обновление: 23 октября 2026 года. Сверка выполнена по объявлению Runner Images. Объявленный срок — план, а не подтверждение, что переключение уже завершено.

Плановое изменение и фактическое состояние Runner

В объявлении GitHub Runner Images указано, что для macOS 26 и Xcode 27 планируется изменить версию OpenSSL, запускаемую командой openssl по умолчанию: с 3.x на 4.x. Переход запланирован на период с 2 по 8 ноября 2026 года и должен проводиться постепенно; актуальное состояние следует проверять по объявлению и его последующим обновлениям. Там же сказано, что OpenSSL 3 останется доступен. Следовательно, речь идёт об изменении значения по умолчанию, а не о заявленном удалении OpenSSL 3.

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

Наблюдаемая ситуация Что может измениться Что проверять перед решением
Скрипт запускает openssl через PATH Выбранный исполняемый файл и результат команды могут отличаться Путь команды, версию и последующий разбор вывода
Зависимость собирается с OpenSSL Возможны несовместимость API или ошибки компоновки Заголовки, параметры компиляции и сообщения линковщика
Готовое приложение использует динамическую библиотеку Успешная команда в терминале не подтверждает успешную загрузку библиотеки приложением Фактически загружаемый файл, его путь и среду запуска
CI генерирует или проверяет сертификаты Может отличаться результат конкретной команды или обработка её вывода Параметры, формат результата и проверки следующего шага

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

Для сверки живой среды сравнивайте журнал конкретного задания с актуальным перечнем программного обеспечения macOS 26 Runner. Перечень может обновляться; поэтому опубликованный файл сам по себе не заменяет диагностический вывод из той среды, где проходила сборка.

Проверка команды и предположений скрипта

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

Добавьте в диагностический шаг вывод пути и версии:

command -v openssl
openssl version

Документация OpenSSL описывает вывод команды version; используйте её при интерпретации результата, а не предполагайте формат по памяти: справка по команде openssl version. Затем проверьте сам скрипт и его зависимости от этого вывода.

  • [ ] Зафиксируйте путь, который вернула команда command -v openssl.
  • [ ] Сохраните полный вывод openssl version в журнале задания.
  • [ ] Найдите в скриптах вызовы openssl, проверки номера версии и разбор строк с помощью grep, sed, регулярных выражений или условий оболочки.
  • [ ] Проверьте, не трактуется ли неизвестная версия как ошибка до выполнения основной задачи.
  • [ ] Сравните вывод двух запусков на одинаковом коммите, не меняя одновременно Runner и зависимости.
  • [ ] Уберите ненужную проверку конкретного номера версии либо замените её проверкой требуемой возможности, если это соответствует логике проекта.

Если нужно явно выбирать образ Runner, сверяйтесь с документацией GitHub Actions о выборе Runner для задания. Не выводите фактическую версию OpenSSL только из названия образа: подтверждением служат сведения, полученные непосредственно во время задания.

Разделение ошибок компиляции, линковки и загрузки

Фраза «ошибка OpenSSL» слишком общая, чтобы выбрать исправление. Ошибка компиляции указывает на один класс проблем, ошибка линковки — на другой, а сбой при запуске может возникнуть уже после того, как сборка завершилась успешно. В каждом случае нужен отдельный набор проверок.

Этап сбоя Признаки в логах Что проверить
Компиляция Компилятор сообщает о недоступных декларациях, заголовках или несовместимом API Версию заголовков, используемые API и требования зависимости
Линковка Сборка доходит до компоновщика, но тот не разрешает требуемые символы Параметры линковки, выбранные библиотеки и документацию зависимости
Запуск Сборка прошла, но процесс не находит библиотеку или не может её загрузить Путь библиотеки в среде запуска и сведения о загруженном файле
Скриптовый шаг Команда выполняется, но последующая проверка завершается ошибкой Ожидаемый вывод, код возврата и условие завершения скрипта

Не исправляйте ошибку загрузки заменой заголовков: заголовок участвует в компиляции, но не доказывает, какую библиотеку приложение найдёт при запуске. Для динамических библиотек на macOS отдельно проверяйте пути загрузки. В документации Apple объясняется, как исполняемый файл использует пути, связанные с динамическими библиотеками: руководство Apple по Run-Path Dependent Libraries.

Для каждой нативной зависимости сверяйте её официальные требования к версии OpenSSL и способу сборки. Если документация не даёт однозначного ответа, подтвердите совместимость сборкой именно того проекта, который запускается в CI. Подмена этой проверки версией, установленной на рабочей станции разработчика, не покажет, какие заголовки и библиотеки выбраны в Runner.

Проверка TLS, сертификатов и ожидаемого поведения

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

Если CI создаёт или проверяет сертификаты, тестируйте именно используемые команды и параметры. Например, поведение команды x509 нужно сверять с соответствующей справкой OpenSSL, а не переносить предположения с другого инструмента или предыдущего образа: документация OpenSSL по openssl x509. Проверяйте также формат сертификата на входе и выходе, имена создаваемых файлов и то, как приложение использует их далее.

  • [ ] Воспроизведите выдачу тестового сертификата теми же параметрами, что использует pipeline.
  • [ ] Проверьте задачу, которая читает сертификат, а не только ту, которая его создаёт.
  • [ ] Убедитесь, что тестовое TLS-подключение проходит на том же этапе и в той же среде, где выполняется CI.
  • [ ] Сопоставьте поведение командной утилиты с поведением самого приложения.
  • [ ] Проверьте, что следующий шаг не зависит от случайного форматирования текстового вывода.

Успешный вызов openssl доказывает только, что сработал этот вызов. Он не подтверждает автоматически, что Ruby, Python или собранный нативный модуль использует ту же библиотеку, те же параметры и тот же путь загрузки.

Сравнение локальной среды и GitHub Actions

Если локальная сборка проходит, а CI — нет, сначала найдите различия окружения, а не делайте вывод о несовместимости OpenSSL. Локальная машина и Runner могут различаться образом, архитектурой, значениями PATH, способом установки зависимости, состоянием кэша и фактически загруженными библиотеками. Не меняйте несколько таких факторов в одном запуске: иначе будет трудно установить причину результата.

Для сравнения выполните один и тот же коммит на Runner и в локальной среде с максимально сопоставимыми командами. В журналах сохраните вывод command -v openssl и openssl version, команды сборки и релевантные сообщения компилятора и линковщика. Если проблема возникает только во время запуска, собирайте дополнительные сведения о загруженных библиотечных файлах в той среде, где воспроизводится ошибка.

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

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

Критерии выбора версии и последовательность приёмки

Выбор между адаптацией и фиксацией OpenSSL 3 должен следовать из результатов проекта, а не из предположения, что новый основной номер обязательно ломает сборку. Если используемые зависимости и тесты проходят с OpenSSL 4 в целевом Runner, можно готовить изменение скриптов и принимать его постепенно. Если зависимость требует OpenSSL 3 или поведение ещё не подтверждено, закрепите версию явно и запланируйте отдельную проверку совместимости.

Для macOS Runner зафиксируйте способ выбора версии в конфигурации задания или в шаге установки, если выбранный образ и используемые инструменты это поддерживают. Проверьте официальное объявление о смене версии по умолчанию и текущий перечень программного обеспечения образа; не предполагайте, что явный вызов openssl будет и дальше указывать на прежнюю установку. Сохраняйте путь и версию в логах: без них при следующем обновлении образа будет сложнее доказать, какую среду проверяли.

Проведите приёмку последовательно:

  • [ ] Запишите исходный коммит, выбранный Runner и диагностический вывод команды openssl.
  • [ ] Найдите скрипты, которые проверяют версию, разбирают вывод команды или полагаются на её параметры по умолчанию.
  • [ ] Сопоставьте требования нативных зависимостей с логами компиляции и линковки.
  • [ ] Отдельно проверьте запуск приложения и фактическую загрузку динамических библиотек.
  • [ ] Прогоните сертификатные, TLS- и интеграционные тесты, использующие OpenSSL.
  • [ ] Сравните результат для одной и той же версии проекта в сопоставимых условиях.
  • [ ] Примите решение: адаптировать проект или явно закрепить OpenSSL 3.
  • [ ] Запишите условие отката — например, конкретный сбой обязательной сборки, TLS-проверки или запуска, который воспроизводится и связан с изменением версии.
  • [ ] После успешного сравнения расширяйте переключение постепенно и повторно проверяйте ключевые задачи.

Такой порядок отделяет ошибки скрипта от несовместимости API, проблемы линковки и сбоя загрузки. Он также не позволяет считать изменение принятой настройкой, пока не проверены сборка, тесты и TLS-функции на целевом Runner.

Частые вопросы

Обновление по умолчанию означает автоматический отказ всех CI?

Нет. Объявление относится к версии команды openssl по умолчанию в указанных образах и сообщает, что OpenSSL 3 останется доступен; это не означает, что все проекты автоматически перейдут на неё во всех своих зависимостях. Определяйте риск по реальному пути команды, ожиданиям скриптов и результатам тестов проекта. Для запланированного периода сверяйте актуальное состояние объявления.

Как узнать фактический openssl в GitHub Actions?

Добавьте в диагностический шаг command -v openssl и openssl version, затем сохраните оба результата в журнале. Первая команда показывает выбранный исполняемый файл, вторая сообщает версию, объявляемую этой утилитой. Сведения не устанавливают, какую динамическую библиотеку загрузило приложение: для этого анализируйте сборку и запуск отдельно.

Как продолжить использовать OpenSSL 3 на macOS Runner?

Если проверка показывает, что проекту пока нужна версия 3, выбирайте её явно в конфигурации, используя поддерживаемый выбранным образом способ. Сначала убедитесь по текущему перечню Runner, что необходимый инструмент доступен, а затем проверьте путь, версию и результат сборки. Не считайте, что прежнее значение PATH останется неизменным после обновления образа.

Что обязательно включить в тест перед переходом?

Проверьте логику скриптов, сборку зависимостей, линковку, запуск приложения и загрузку библиотек, а также задачи с сертификатами и TLS. Сравнивайте одинаковый коммит и записывайте версию и путь команды в Runner. Успех отдельного вызова openssl не заменяет проверку нативной зависимости или приложения, которое может загружать другую библиотеку.

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