Die geplante Umstellung des OpenSSL-Standardbefehls auf bestimmten macOS-Runnern ist für den Zeitraum vom 02.11.2026 bis 08.11.2026 angekündigt; sie bedeutet nicht, dass jede macOS-CI automatisch fehlschlägt. Prüfen Sie zuerst Ihre echten Workflows auf Versions-, Options- und Laufzeitabhängigkeiten und legen Sie OpenSSL 3 nur dann ausdrücklich fest, wenn die Tests eine konkrete Inkompatibilität zeigen.

Zuletzt geprüft am 23.10.2026. Der Zeitplan und der angekündigte Umfang beruhen auf der offiziellen Ankündigung der Runner Images. Für den aktuellen Softwarebestand ist zusätzlich die macOS-26-Runner-Softwareliste zu kontrollieren. Der geplante Rollout ist zum genannten Prüfzeitpunkt noch nicht als abgeschlossen zu behandeln.

Dieser Leitfaden richtet sich an Verantwortliche für GitHub-Actions-macOS-Workflows, die mögliche Auswirkungen vor einer Änderung erkennen möchten.
Er hilft außerdem Entwicklern, die native Abhängigkeiten oder Ruby- und Python-Laufzeiten prüfen müssen, sowie DevOps-Teams, die über Anpassung, feste Version oder Rückstellung entscheiden.

OpenSSL-4-Kompatibilität in macOS-CI zuerst nach tatsächlichem Risiko ordnen

Die Ankündigung betrifft die Standardversion des mit openssl aufrufbaren Befehls auf macOS 26- und Xcode-27-Runnern: Geplant ist eine Umstellung von OpenSSL 3.x auf OpenSSL 4.x. Sie besagt nicht, dass OpenSSL 3 entfernt wird, und sie belegt auch nicht, dass jede Anwendung, die OpenSSL nutzt, automatisch auf die neue Version umgestellt wird. Maßgeblich ist, was der konkrete Job auflöst, kompiliert und zur Laufzeit lädt.

OpenSSL 4.0 ist laut offizieller Migrationsdokumentation eine Änderung der Hauptversion. Programme, die veraltete APIs verwenden, können Anpassungen benötigen; daraus folgt aber keine pauschale Aussage über die Kompatibilität jedes Projekts. Prüfen Sie die OpenSSL-Migrationshinweise zu Version 4.0 gegen die tatsächlich verwendeten Bibliotheken und den Build Ihres Projekts.

Vor der Fehlersuche sollte das Problem in drei verschiedene Ebenen eingeordnet werden:

  • Kommandozeile: Ein Skript ruft über PATH einen anderen openssl-Befehl auf als erwartet oder verarbeitet eine geänderte Versionsausgabe falsch.
  • Build: Eine Abhängigkeit findet Header oder Funktionen nicht, oder der Linker kann die benötigten Symbole nicht auflösen.
  • Laufzeit: Das Programm wird gebaut, lädt aber eine andere dynamische Bibliothek als erwartet oder scheitert erst beim TLS- beziehungsweise Zertifikatsvorgang.

Diese Trennung verhindert, dass ein fehlgeschlagener Zertifikatsschritt vorschnell als allgemeine OpenSSL-Inkompatibilität eingeordnet wird. Sie macht auch deutlich, welche Tests nötig sind, bevor eine Versionsentscheidung getroffen wird.

Runner-Verhalten mit einer kontrollierten Gegenüberstellung prüfen

Für eine belastbare Entscheidung müssen Sie nicht sofort jede Pipeline umstellen. Vergleichen Sie zuerst denselben Commit unter dokumentierten Bedingungen. So lässt sich feststellen, ob ein Unterschied tatsächlich mit dem OpenSSL-Standardbefehl zusammenhängt oder etwa auf eine geänderte Runner-Umgebung, andere Abhängigkeiten oder einen Cache-Effekt zurückgeht.

Option Geeignet, wenn … Was vor der Freigabe nachzuweisen ist
OpenSSL 4 übernehmen Skripte und Abhängigkeiten die neue Version nachweislich unterstützen. Build, Tests sowie betroffene TLS- und Zertifikatsaufgaben laufen auf dem vorgesehenen Runner erfolgreich.
OpenSSL 3 ausdrücklich auswählen Eine geprüfte Abhängigkeit oder ein Skript vorerst auf OpenSSL 3 angewiesen ist. Der Job löst gezielt die vorgesehene Installation auf; Build und Laufzeit laden dazu passende Bibliotheken.
Umstellung zurückstellen Der Fehler noch nicht auf eine Ursache eingegrenzt ist oder die Tests keine belastbare Freigabe erlauben. Der Rückfall bleibt dokumentiert und die Pipeline verwendet nicht unbemerkt einen zufälligen Standardpfad.

Die Entscheidung ist keine allgemeine Präferenz für eine Hauptversion. Wenn die Pipeline mit OpenSSL 4 stabil durchläuft, müssen Sie nicht vorsorglich auf OpenSSL 3 festlegen. Wenn dagegen ein bestimmter Build oder eine Laufzeitprüfung reproduzierbar scheitert, ist die explizite Auswahl einer kompatiblen Version ein kontrollierter Rückweg, bis Abhängigkeit oder Skript angepasst sind.

Schrittweise den tatsächlich ausgeführten Befehl nachweisen

Beginnen Sie bei der Shell des fehlgeschlagenen Jobs, nicht bei der lokalen Entwicklungsmaschine. Auf einem GitHub Actions macOS Runner kann die verfügbare Werkzeugkette vom lokalen Rechner abweichen; GitHub dokumentiert, dass Workflows ihre Jobs auf unterschiedlichen Runnern ausführen können. Prüfen Sie deshalb den für den konkreten Job gewählten Runner anhand der Dokumentation zur Runner-Auswahl.

  1. Runner und Job festhalten. Notieren Sie den Runner-Bezeichner aus der Workflow-Konfiguration und sichern Sie den Job-Log des fehlgeschlagenen Laufs. Vergleichen Sie keine lokalen Resultate mit CI-Ausgaben, bevor klar ist, dass Betriebssystem, CPU-Architektur und relevante Werkzeugketten für die Fragestellung vergleichbar sind.

  2. Pfad und Version im Job ausgeben. Fügen Sie vor dem ersten OpenSSL-Aufruf einen Diagnoseabschnitt ein: sh command -v openssl type -a openssl openssl version -a command -v zeigt, welcher Befehl beim Aufruf aufgelöst wird; type -a kann weitere gleichnamige Treffer sichtbar machen. Die Versionsausgabe lässt sich mit der dokumentierten Funktion des OpenSSL-Befehls version abgleichen. Wichtig ist, diese Angaben im betroffenen Job zu erfassen, nicht nur in einem separaten Diagnosejob mit möglicherweise anderen Umgebungsvariablen.

  3. Alle Aufrufstellen suchen. Durchsuchen Sie Workflow-Dateien, Shell-Skripte, Build-Konfigurationen und Hilfsprogramme nach openssl, fest eingetragenen Verzeichnissen, Versionsprüfungen und Optionen. Prüfen Sie auch, ob ein Wrapper oder ein zuvor gesetzter PATH den Befehl auf ein anderes Verzeichnis lenkt. Eine erfolgreiche Diagnoseausgabe am Jobanfang beweist noch nicht, dass ein später gestartetes Teilprogramm denselben Befehl oder dieselbe Bibliothek verwendet.

  4. Versionsannahmen in Skripten bewerten. Achten Sie auf Bedingungen, die nur eine bestimmte Hauptversionszeichenfolge akzeptieren, sowie auf Parser, die feste Wörter oder Felder in der Ausgabe erwarten. Ein Skript kann die neue Version korrekt finden und trotzdem abbrechen, wenn es jede Abweichung als Fehler wertet. Prüfen Sie, ob die eigentliche Aufgabe – etwa das Erzeugen einer Datei – fehlschlägt oder nur die vorgeschaltete Versionskontrolle.

  5. Protokollierung ohne Geheimnisleck ergänzen. Speichern Sie Pfad, relevante Versionsausgabe und Exit-Status in einem klar erkennbaren Diagnoseblock. Vermeiden Sie dabei Shell-Tracing, wenn im gleichen Bereich Zugangsdaten, private Schlüssel oder Tokens verwendet werden könnten. GitHub beschreibt die unterstützten Workflow-Befehle zur strukturierten Job-Ausgabe; verwenden Sie solche Meldungen nur für nicht vertrauliche Diagnosewerte.

Die sichtbare Versionsausgabe ist ein wichtiger Befund, aber kein vollständiger Kompatibilitätsnachweis. Sie beschreibt den Kommandozeilenaufruf, nicht automatisch die OpenSSL-Bibliothek, die eine native Abhängigkeit beim Start lädt. Diese Unterscheidung wird besonders wichtig, wenn ein Skript erfolgreich ist, der anschließende Anwendungsstart aber scheitert.

Build- und Ladefehler getrennt diagnostizieren

Wenn ein nativer Build fehlschlägt, ordnen Sie den ersten konkreten Fehler einer Phase zu. Eine Meldung über nicht gefundene Header deutet auf eine andere Fehlerstelle als eine nicht auflösbare Funktion beim Linken. Ein Programm, das erfolgreich gebaut wird, aber beim Start eine fehlende oder unerwartete Bibliothek meldet, ist wiederum ein Laufzeitproblem. Die Phasen brauchen unterschiedliche Abhilfen; eine pauschale Änderung des PATH kann einen Linkerfehler oder eine falsche dynamische Bibliothek nicht zuverlässig beheben.

Bei einem Header- oder API-Fehler prüfen Sie zunächst, welche OpenSSL-Header der Build tatsächlich einbindet und ob die betroffene Abhängigkeit die verwendeten Schnittstellen unterstützt. Die OpenSSL-Migrationsdokumentation ist ein Anhaltspunkt für mögliche Änderungen, aber kein Ersatz für die Kompatibilitätsangaben des jeweiligen Bibliotheks- oder Laufzeitprojekts. Entscheidend bleibt, ob der echte Projekt-Build mit der betroffenen Version gelingt.

Bei Linkerfehlern vergleichen Sie die Bibliothekssuchpfade und die verwendeten Linkerargumente mit dem erwarteten Build-Setup. Prüfen Sie, ob die Build-Konfiguration Header und Bibliotheken aus unterschiedlichen Installationen kombiniert. Ein solcher Mischzustand kann die Diagnose verfälschen: Ein Kompilierungsschritt kann eine Schnittstelle sehen, während der Linker gegen eine andere Bibliothek arbeitet.

Bei einem Fehler nach erfolgreicher Kompilierung muss die geladene Bibliothek untersucht werden. Apple erläutert, wie dynamische Bibliotheken über Laufzeitpfade gefunden werden; die Dokumentation zu Run-Path-Dependent Libraries hilft, rpath und die Abhängigkeit von Bibliothekspfaden einzuordnen. Daraus folgt nicht, dass ein bestimmtes Projekt zwangsläufig falsch lädt. Es zeigt aber, warum die Versionsausgabe eines Shell-Befehls allein nicht belegt, welche OpenSSL-Bibliothek eine Anwendung verwendet.

Für Ruby- oder Python-Projekte gilt dieselbe Phasentrennung: Prüfen Sie, welche native Erweiterung gebaut wird, welche OpenSSL-Komponenten der Build findet und ob die Anwendung im CI-Lauf tatsächlich die erwartete Bibliothek verwendet. Setzen Sie nicht voraus, dass die Interpreter-Version automatisch dieselbe OpenSSL-Version nutzt wie der Aufruf openssl in der Shell. Dokumentieren Sie die Herkunft der Abhängigkeit und vergleichen Sie sie mit dem konkreten Build- und Laufzeitverhalten.

TLS- und Zertifikatsaufgaben mit echten Projektbefehlen abnehmen

Ein erfolgreiches openssl version ist kein TLS-Test. Ebenso belegt ein erfolgreicher Build nicht, dass ein Zertifikatsschritt oder eine Anwendung zur Laufzeit korrekt arbeitet. Erstellen Sie eine Liste aller CI-Schritte, die Schlüssel oder Zertifikate erzeugen, Zertifikatsdaten prüfen, Vertrauensketten verarbeiten oder TLS-Verbindungen aufbauen. Testen Sie die tatsächlich verwendeten Befehle und Optionen, statt nur ein allgemeines OpenSSL-Beispiel auszuführen.

Bei Zertifikatsaufgaben sollten Sie mindestens die folgenden Aspekte abgleichen:

  • Bleiben Eingabe- und Ausgabedateien an den erwarteten Orten, und enthalten die Ausgaben die Felder, die nachfolgende Schritte verarbeiten?
  • Verarbeitet das Skript Exit-Status und Diagnosemeldungen korrekt, oder setzt es eine bestimmte Formulierung im Text voraus?
  • Werden private Schlüssel und sensible Testdaten im Log geschützt?
  • Prüft die Pipeline tatsächlich die für das Projekt relevanten Zertifikatsmerkmale und nicht nur, ob ein Kommando ohne offensichtlichen Fehler endet?

Für die Prüfung von Zertifikatsdateien beschreibt die OpenSSL-Referenz zum Befehl x509 dessen verfügbare Funktionen. Verwenden Sie sie, um Ihre Aufrufe zu verstehen; übernehmen Sie aber nicht ungeprüft eine Option, die im Projekt bislang gar nicht eingesetzt wird. Für TLS gilt außerdem: Ein Kommandozeilentest und die Verbindung der Anwendung sind unterschiedliche Prüfpunkte. Die Anwendung kann eigene Bibliotheken, Konfigurationen oder Zertifikatsspeicher verwenden.

Das Ergebnis sollte pro CI-Aufgabe festgehalten werden: erwartetes Verhalten, tatsächlich ausgeführter Befehl, Exit-Status und relevante Ausgabe. So kann ein Team unterscheiden, ob die OpenSSL-Version selbst, ein hart kodierter Optionssatz oder ein nachgelagerter Parser die Ursache ist. Gerade bei Zertifikats- und TLS-Schritten ist ein einmaliger Erfolg in einer interaktiven Shell kein ausreichender Freigabenachweis für die Pipeline.

Vorher und nachher mit vergleichbaren Runner-Logs bewerten

Um einen versionsbedingten Rückschritt nachzuweisen, brauchen Sie Logs, die sich sinnvoll vergleichen lassen. Führen Sie denselben Commit auf den relevanten Runnern aus und protokollieren Sie neben dem OpenSSL-Pfad und der Versionsausgabe auch die für das Projekt entscheidenden Eigenschaften des Jobs: Runner-Auswahl, CPU-Architektur, PATH, Abhängigkeitsquellen und gegebenenfalls geladene Bibliotheken. Die offizielle Ankündigung bezieht sich auf bestimmte macOS-Runner und einen geplanten Rollout; sie besagt nicht, dass jede Umgebung gleichzeitig oder identisch umgestellt wird. Prüfen Sie daher den aktuellen Stand der Ankündigung zusammen mit der Softwareliste des verwendeten Images.

Achten Sie außerdem auf Cache-Effekte. Ein erfolgreicher Lauf kann ein zuvor gebautes Artefakt wiederverwenden und dadurch einen neuen Kompilierungsfehler verdecken. Umgekehrt kann ein Cache-Miss die Pipeline verändern, ohne dass OpenSSL die Ursache ist. Vergleichen Sie deshalb einen Lauf, der die relevanten Abhängigkeiten tatsächlich neu aufbaut, mit dem gewohnten Ablauf, und vermerken Sie, ob Cache und Build-Ausgabe aus demselben Kontext stammen.

Bei der Gegenüberstellung sollten Sie nur eine für die Fragestellung relevante Variable ändern. Wenn Sie gleichzeitig Runner, Abhängigkeitsversionen und Build-Skripte austauschen, wird die Ursache schwer zu bestimmen sein. Ein sinnvoller Vergleich zeigt mindestens, ob der Kommandozeilenpfad anders ist, ob derselbe Build an einer bestimmten Phase scheitert und ob die Laufzeitbibliothek abweicht. Das ist aussagekräftiger als ein einfacher Vergleich von „lokal grün“ und „CI rot“.

Freigabe oder Rückfall anhand überprüfbarer Kriterien entscheiden

Eine Umstellung kann freigegeben werden, wenn die relevanten Builds und Tests auf dem vorgesehenen Runner erfolgreich sind, die Zertifikats- und TLS-Aufgaben erwartungsgemäß arbeiten und keine Abhängigkeit unbemerkt eine andere Bibliothek lädt. Werden die Workflows angepasst, sichern Sie die Änderung mit denselben repräsentativen Jobs ab, die zuvor den Fehler sichtbar gemacht haben. Erweitern Sie die Freigabe erst, wenn die Logs nachvollziehbar und wiederholbar sind.

Wenn eine geprüfte Abhängigkeit OpenSSL 4 noch nicht unterstützt oder eine konkrete Aufgabe unter der neuen Version reproduzierbar scheitert, wählen Sie OpenSSL 3 ausdrücklich aus, statt den zufälligen Standard des Runner-Images vorauszusetzen. Die Runner-Images-Ankündigung nennt die explizite Auswahl als mögliche Abhilfe und sagt zugleich, dass OpenSSL 3 erhalten bleibt. Prüfen Sie dennoch, welche Installation im konkreten Runner verfügbar ist, und legen Sie den gewünschten Pfad kontrolliert in der Workflow-Konfiguration fest. Verlassen Sie sich nicht auf einen undokumentierten Verzeichnispfad, der sich mit dem Image ändern kann.

Eine Rückstellung ist angemessen, wenn Sie die Fehlerquelle noch nicht eingrenzen können oder der Testaufbau keine vergleichbaren Ergebnisse liefert. Halten Sie dann fest, welcher Befund die Freigabe blockiert, wer die Abhängigkeit oder das Skript prüft und unter welcher Bedingung erneut getestet wird. Ohne dokumentierte Rückfallbedingung kann eine vorübergehende Festlegung auf OpenSSL 3 unbemerkt zur dauerhaften Abhängigkeit werden.

Prüfliste für die CI-Abnahme

  • [ ] Der tatsächliche Runner und der Zeitpunkt der Ausgabe sind aus dem Job-Log ersichtlich.
  • [ ] Der aufgelöste openssl-Pfad und die Versionsinformationen sind dokumentiert.
  • [ ] Skripte, feste Versionsprüfungen, Optionen und nachgelagerte Ausgabeparser wurden überprüft.
  • [ ] Build-, Linker- und Laufzeitprobleme sind getrennt klassifiziert.
  • [ ] Relevante Zertifikats-, Schlüssel- und TLS-Aufgaben wurden mit den Projektbefehlen ausgeführt.
  • [ ] Lokale und CI-Ergebnisse wurden nicht ohne Prüfung von Runner, Architektur, Abhängigkeiten und Cache gleichgesetzt.
  • [ ] Für die Freigabe oder den Rückfall auf OpenSSL 3 sind ein konkreter Nachweis und eine Rückkehrbedingung festgehalten.

Häufige Fragen zur Umstellung im macOS-Runner

Führt die Umstellung bei jedem macOS-CI-Lauf zu einem Fehler?

Nein. Geplant ist eine Änderung des Standardbefehls auf den genannten Runnern, keine pauschale Aussage über jede Anwendung oder jede dynamisch geladene Bibliothek. Betroffen sind vor allem Jobs, deren Skripte eine bestimmte Versionsausgabe, Option oder ein bestimmtes Standardverhalten voraussetzen. Ermitteln Sie zuerst die im Job aufgelöste Version und testen Sie danach die betroffenen Builds und Aufgaben.

Wie lässt sich die Version auf einem GitHub Actions macOS Runner kontrollieren?

Geben Sie command -v openssl, type -a openssl und openssl version -a im betroffenen Job aus. Vergleichen Sie den Pfad mit dem erwarteten PATH und prüfen Sie, ob später gestartete Skripte eine andere Umgebung erhalten. Protokollieren Sie die Werte nahe am fehlerhaften Schritt und schützen Sie Geheimnisse; eine Versionsausgabe aus einem separaten Job ist kein Beleg für den Pfad des Builds.

Wie bleibt OpenSSL 3 auf dem macOS Runner verfügbar?

OpenSSL 3 soll laut Runner-Images-Ankündigung erhalten bleiben. Für eine kontrollierte Nutzung wählen Sie die passende Installation ausdrücklich aus, statt sich auf den Standardbefehl zu verlassen. Verifizieren Sie den Pfad im Job und prüfen Sie, ob auch Build und Laufzeit dieselbe vorgesehene Installation verwenden. Die bloße Verfügbarkeit von OpenSSL 3 beweist nicht, dass ein beliebiges Projekt automatisch dagegen kompiliert.

Welche Tests müssen vor einer Freigabe laufen?

Testen Sie den betroffenen Build einschließlich nativer Abhängigkeiten, die zugehörigen Anwendungstests sowie die im Projekt tatsächlich verwendeten Zertifikats- und TLS-Schritte. Wenn dynamische Bibliotheken im Spiel sind, gehört auch ein Laufzeittest dazu. Führen Sie die Jobs mit demselben Commit und nachvollziehbarer Runner-Konfiguration aus, damit ein Fehler nicht mit Cache, Architektur oder einer anderen Werkzeugkettenänderung verwechselt wird.

Wenn eine verlässliche Abnahme eine echte macOS-Umgebung außerhalb der vorhandenen CI erfordert, kann ein separater Remote-Mac-Knoten den Vergleich von Runner-Logs und Projektabhängigkeiten ergänzen. Das ist sinnvoll, wenn ein Team wiederholt macOS-spezifische Builds prüfen muss; es ersetzt nicht automatisch die Prüfung auf dem produktiv verwendeten Runner. Informationen zur Remote-Mac-Umgebung von RUVCLOUD helfen dabei, diese Möglichkeit gegen vorhandene CI-Knoten abzuwägen. Für Teams, die eine zusätzliche Testumgebung erwägen, sind auch die RUVCLOUD-Mietoptionen relevant. Wer dauerhaft hohe Auslastung oder direkten Zugriff auf lokale Hardware benötigt, sollte stattdessen auch einen eigenen Mac als Alternative kalkulieren.