Was ist vor der OpenSSL-4-Änderung in GitHub Actions macOS zu prüfen? Checkliste 2026

Symptom: Ein macOS-Build ruft openssl ohne Versionspfad auf, und das Team weiß nicht, welches Programm der Runner künftig ausführt.
Schnellste Lösung: Prüfen Sie zuerst alle nicht versionierten PATH-Aufrufe, testen Sie anschließend Zertifikats-, Signatur-, TLS- und native Build-Aufgaben. Aufgaben, die OpenSSL 3 benötigen, sollten die Version ausdrücklich auswählen.

Dieser Leitfaden richtet sich an IT- und Plattformverantwortliche, die macOS-CI-Runner und Toolchain-Änderungen betreuen.
Wenn Sie Signatur- oder TLS-Skripte pflegen, konzentrieren Sie sich auf deren Versionsannahmen und Ergebnisprüfungen.
Für iOS- und macOS-Teams mit nativen Abhängigkeiten ist ein isolierter Build wichtiger als eine pauschale Kompatibilitätsannahme.

Zuletzt aktualisiert am 23.10.2026; geprüft anhand der GitHub-Ankündigung zur OpenSSL-Änderung und der Dokumentation zu GitHub-Runnern.

Kurzentscheidung und betroffene Runner

Die OpenSSL-4-Migration in GitHub-Actions-macOS-CI ist eine angekündigte Änderung, kein bereits abgeschlossener Rollout. GitHub plant, zwischen dem 02.11.2026 und dem 08.11.2026 bei macOS-26-Runnern mit Intel und Arm64 sowie bei Xcode-27-Runnern mit Arm64 den nicht versionierten Befehl openssl standardmäßig auf OpenSSL 4 umzustellen. OpenSSL 3 soll weiterhin über einen versionierten Homebrew-Präfix verfügbar sein. Der Termin kann sich laut Ankündigung abhängig von Kompatibilitätsprüfungen ändern. Prüfen Sie den aktuellen Stand direkt in der Ankündigung.

Daraus folgt keine allgemeine Änderung für sämtliche macOS-, Linux- und Windows-Runner. Erfassen Sie zuerst, welche konkreten Images Ihre Workflows verwenden und ob sie zur angekündigten Gruppe gehören. Die Bezeichnung eines Runner-Labels oder die erfolgreiche Ausführung eines früheren Builds ist kein Beleg dafür, welches Programm ein neuer Job aus PATH auflöst.

GitHub dokumentiert die verfügbaren gehosteten Runner und die jeweiligen Image-Informationen in seiner Referenz zu GitHub-Runnern. Für den Abgleich sollten Sie nicht nur die Workflow-YAML-Datei heranziehen: Auch wiederverwendete Aktionen, Skripte und Build-Schritte können das Programm aufrufen.

PATH-Aufrufe und Versionsnachweise

Der erste Fehlerhinweis ist oft unscheinbar: Ein Skript ruft openssl direkt auf, nimmt aber an, dass damit weiterhin OpenSSL 3 gemeint ist. Der Befehl benennt keine Version; welche ausführbare Datei tatsächlich startet, hängt davon ab, wie PATH im jeweiligen Job gesetzt und aufgelöst wird.

Suchen Sie daher nicht nur im Hauptworkflow. Prüfen Sie Shell-Skripte, Build-Konfigurationen, Makefiles, Hilfsprogramme und wiederverwendete Aktionen. Achten Sie besonders auf Aufrufe, die in einem anderen Verzeichnis oder in einem späteren Job erfolgen. Ein PATH-Eintrag, der in einem Job ergänzt wird, ist nicht automatisch eine dauerhafte Festlegung für sämtliche anderen Jobs.

Lassen Sie in repräsentativen Jobs mindestens den tatsächlichen Pfad und die Versionsinformation protokollieren, beispielsweise mit command -v openssl und openssl version -a. Halten Sie fest, zu welchem Workflow, Runner-Image und Build-Schritt die Ausgabe gehört. Diese Protokolle sind aussagekräftiger als ein Schluss aus dem Namen des Runner-Labels. GitHub beschreibt sowohl das Prüfen installierter Image-Software als auch das Ergänzen von Pfaden über Workflow-Befehle und PATH-Änderungen in Workflows.

Hinweis: Eine Versionsausgabe im allgemeinen Diagnosejob reicht nicht, wenn die produktive Aktion ihre Umgebung später verändert. Erfassen Sie Pfad und Version möglichst unmittelbar vor den Schritten, die Zertifikate, Schlüssel, TLS oder native Bibliotheken verarbeiten.

Versionsannahmen in Skripten und Abhängigkeiten

Ein Workflow kann auch dann betroffen sein, wenn sein Quelltext keinen offensichtlichen Versionsvergleich enthält. Skripte können bestimmte Optionen, Standardwerte oder Textausgaben erwarten. Eine Änderung des Standardprogramms macht solche Stellen zu Prüfhinweisen, aber nicht automatisch zu einem Fehlernachweis. Ob ein Projekt scheitert, hängt von den tatsächlich verwendeten Befehlen und deren nachgelagerter Verarbeitung ab.

Achten Sie auf Versionsvergleiche, bedingte Zweige, festgelegte Kommandooptionen und die Auswertung von OpenSSL-Ausgaben. Wenn ein Skript beispielsweise eine bestimmte Zeile parst oder eine Option als stets vorhanden voraussetzt, führen Sie genau diesen Schritt mit der für den Test vorgesehenen Version aus. Vergleichen Sie Rückgabestatus, erzeugte Dateien und die Verarbeitung durch den nächsten Job. Die Dokumentation zu OpenSSL-Kommandoformaten hilft dabei, verwendete Optionen einzuordnen; sie ersetzt jedoch keinen Test Ihrer konkreten Aufrufkette.

Nehmen Sie native Abhängigkeiten separat in den Prüfplan auf. Untersuchen Sie Installationsskripte und Compilerprotokolle auf explizite Versions- oder Bibliothekspfadbindungen. Wenn ein Paket gegen eine bestimmte OpenSSL-Installation gebaut werden soll, kann eine Abweichung zwischen Installationspfad, Header-Dateien und verlinkter Bibliothek relevant sein. Führen Sie einen isolierten Build aus, statt aus einem einzelnen öffentlichen Beispiel auf die Kompatibilität aller Projekte zu schließen.

Bei einer Abhängigkeit von OpenSSL 3 sollten Sie die Version ausdrücklich auswählen und die Auswahl im Job-Protokoll nachweisen. Die Ankündigung verweist auf einen versionierten Homebrew-Präfix; die Formelinformationen zu openssl@3 sind ein geeigneter Ausgangspunkt, um die verfügbare Formel zu prüfen. Ermitteln Sie den konkreten Präfix zur Laufzeit, statt einen Pfad als universell gültig vorauszusetzen. Für die Übergabe eines Pfads an spätere Schritte nutzen Sie den von GitHub dokumentierten Workflow-Befehl und kontrollieren anschließend erneut, welche ausführbare Datei tatsächlich aufgerufen wird.

Zertifikate, Schlüssel, Signaturen und TLS

Bei sicherheitsrelevanten Build-Schritten sollten Sie nicht bei der Frage stehen bleiben, ob openssl startet. Entscheidend ist, ob der gesamte Ablauf weiterhin das erwartete Ergebnis erzeugt und ob dieses Ergebnis vom nächsten Verarbeitungsschritt korrekt geprüft wird. Erstellen Sie eine Liste der Workflows, in denen OpenSSL Zertifikate erzeugt, Schlüssel bearbeitet, Signaturmaterial prüft oder TLS-bezogene Aufgaben übernimmt.

Für jede Aufgabe sollten Sie drei Dinge festhalten: den konkreten Aufruf und seine Version, die erwartete Ausgabe beziehungsweise das erzeugte Artefakt und die Prüfung, mit der ein Folgeprozess das Ergebnis akzeptiert. Bei Signaturen gehört dazu nicht nur der erfolgreiche Aufruf, sondern auch die Validierung des signierten Produkts. Apple erläutert die Rolle von Zertifikaten in Technotes zu Code-Signing-Zertifikaten und beschreibt den Ablauf zum Erstellen signierten macOS-Distributionscodes. Diese Unterlagen erklären die Apple-seitigen Anforderungen; die konkrete CI-Kompatibilität müssen Sie mit Ihren eigenen Jobs belegen.

Für TLS-Aufgaben reicht eine allgemeine Verbindungsmessung nicht aus, wenn der produktive Workflow zusätzliche Zertifikatsketten, Schlüsseldateien oder Prüfregeln verwendet. Testen Sie die real genutzte Konfiguration und bewahren Sie die Ergebnisse entsprechend Ihren internen Sicherheits- und Audit-Anforderungen auf. Ändern Sie nicht gleichzeitig OpenSSL-Version, Zertifikatsmaterial und mehrere Skripte, wenn Sie einen Fehler später noch einer Ursache zuordnen müssen.

Prüfpfad und Entscheidungsmatrix

Verwenden Sie für die Freigabe einen begrenzten, repräsentativen Testlauf. So können Sie die tatsächliche Abhängigkeit prüfen, ohne eine ungeprüfte Änderung direkt auf alle Produktionsjobs auszurollen.

Runner erfassen: Notieren Sie die verwendeten macOS- und Xcode-Runner-Images und gleichen Sie sie mit der angekündigten Gruppe ab. Prüfen Sie die aktuelle GitHub-Ankündigung erneut, da das geplante Zeitfenster veränderlich ist.
Aufrufe finden: Durchsuchen Sie Workflow-Dateien, Shell- und Build-Skripte sowie wiederverwendete Aktionen nach openssl. Markieren Sie Aufrufe ohne expliziten Versionspfad oder geprüfte Versionsauswahl.
Ist-Zustand protokollieren: Lassen Sie in den betroffenen Jobs den aufgelösten Pfad und die Versionsausgabe unmittelbar vor den relevanten Schritten erfassen. Ordnen Sie die Protokolle dem Runner-Image und dem Build zu.
Kritische Abläufe auswählen: Nehmen Sie repräsentative Zertifikats-, Schlüssel-, Signatur-, TLS- und native Build-Aufgaben auf. Wählen Sie nicht nur einen einfachen Smoke-Test, sondern Schritte, deren Ergebnis tatsächlich in nachgelagerten Prozessen verwendet wird.
Isoliert vergleichen: Führen Sie denselben geeigneten Test mit der bestehenden Auswahl und mit der vorgesehenen OpenSSL-Version aus. Vergleichen Sie Rückgabestatus, Protokolle, erzeugte Artefakte und deren Validierung. Kennzeichnen Sie Abweichungen als reproduzierbare Beobachtung oder noch ungeklärten Verdacht.
Freigabe oder Rückfall festlegen: Wenn ein Workflow OpenSSL 3 benötigt, wählen Sie diese Version explizit. Wenn ein Test fehlschlägt, isolieren Sie zunächst den betroffenen Job und folgen Sie dem bestehenden Rückfallverfahren. Erweitern Sie die Änderung erst, wenn Ursache und Behebung durch Teamtests belegt sind.

Die folgende Bewertung ist ein internes Priorisierungsraster, keine Messung der Leistung oder Stabilität. Vergeben Sie je Dimension 0 Punkte für „nicht nachgewiesen“, 1 Punkt für „teilweise geprüft“ und 2 Punkte für „im repräsentativen Job belegt“. Bewerten Sie PATH-Nachweis, kritische Aufgaben und Rückfallweg getrennt. Ein niedriger Wert ist ein Grund für weitere Prüfung, aber kein Beleg für einen Ausfall.

Vorgehen	Versionskontrolle	Beleg für kritische Aufgaben	Rückfallmöglichkeit	Entscheidung
Nicht versioniertes `openssl` unverändert lassen	Niedrig, solange Pfad und Version nicht protokolliert sind	Nicht nachgewiesen	Abhängig von der vorhandenen Workflow-Konfiguration	Nur nach Klärung der tatsächlichen Auflösung freigeben
OpenSSL 3 gezielt über den versionierten Präfix auswählen	Hoch, wenn Präfix und Laufzeitversion protokolliert werden	Durch projektspezifische Tests nachzuweisen	Gut, sofern die Auswahl im Workflow kontrolliert geändert werden kann	Für nachgewiesene OpenSSL-3-Abhängigkeiten geeignet
OpenSSL 4 in isolierten repräsentativen Jobs prüfen	Hoch, wenn der aufgelöste Pfad dokumentiert wird	Durch Vergleich von Artefakten und Prüfungen nachzuweisen	Gut, wenn Produktionsjobs bis zur Freigabe unverändert bleiben	Als kontrollierter Kompatibilitätstest geeignet
Ohne Nachweis auf den angekündigten Standardwechsel warten	Niedrig	Offen	Reaktiv und vom Fehlerbild abhängig	Für kritische Signatur- oder Build-Aufgaben nicht als Freigabestrategie verwenden

Prüfen Sie auch die Verteilung Ihrer Tests: Wenn ausschließlich ein ungefährlicher Diagnosejob erfolgreich ist, fehlen weiterhin Nachweise für Signaturen, TLS und native Abhängigkeiten. Umgekehrt ist ein einzelner Fehler in einem nicht repräsentativen Hilfsskript noch kein Beleg dafür, dass sämtliche macOS-Builds betroffen sind. Halten Sie deshalb pro Workflow fest, was getestet wurde, welche Version im Job aufgelöst wurde und wer die Freigabe verantwortet.

Häufige Fragen

Geplanter Wechselzeitraum

GitHub nennt den Zeitraum vom 02.11.2026 bis zum 08.11.2026 als Plan für die schrittweise Bereitstellung. Behandeln Sie diesen Zeitraum als angekündigten Rollout, nicht als Zusicherung, dass jeder passende Runner am selben Tag umgestellt wird. Prüfen Sie vor der Freigabe erneut die Ankündigung und kontrollieren Sie in Ihren eigenen Job-Protokollen, welche Version tatsächlich aufgelöst wurde.

Nachweis eines PATH-Aufrufs

Ein nicht versionierter Aufruf ist ein Aufruf wie openssl, bei dem der Workflow nicht direkt einen geprüften Versionspfad verwendet. Suchen Sie über die YAML-Datei hinaus in den Skripten und Aktionen, die der Job startet. Protokollieren Sie anschließend direkt vor dem relevanten Arbeitsschritt command -v openssl und die Versionsausgabe. Ein Runner-Label allein beantwortet diese Frage nicht.

Festlegung auf OpenSSL 3

Wenn ein konkreter Workflow von OpenSSL 3 abhängt, wählen Sie die Version ausdrücklich aus, anstatt die Standardauflösung von PATH vorauszusetzen. GitHub nennt dafür einen versionierten Homebrew-Präfix. Ermitteln Sie den Präfix im Job, ergänzen Sie gezielt dessen bin-Verzeichnis für die benötigten Schritte und prüfen Sie die tatsächliche Auflösung erneut. So bleibt die Festlegung überprüfbar und auf betroffene Jobs begrenzt.

Prüfungen für Signatur und Zertifikate

Testen Sie die tatsächlich eingesetzten Schritte zur Zertifikatserzeugung, Schlüsselverarbeitung, Codesignierung und TLS-Prüfung. Bewerten Sie sowohl den Erfolg des OpenSSL-Aufrufs als auch das erzeugte Artefakt und dessen Akzeptanz durch nachgelagerte Jobs. Dokumentieren Sie Abweichungen und Validierungsergebnisse im Teamprozess. Ein allgemeines Kommando-Beispiel oder ein erfolgreicher Diagnoseaufruf ist kein Nachweis für die Produktionskompatibilität.

Wenn Ihre Tests in einer getrennten Umgebung laufen sollen, ohne die bestehende Produktionspipeline zu verändern, vergleichen Sie zunächst die passenden Optionen in unserem Überblick zu Mac-Umgebungen. Eine gemietete Mac-Umgebung kann für einen isolierten Probelauf oder vorübergehende Build-Kapazität sinnvoll sein; sie ersetzt jedoch weder Ihre OpenSSL-Prüfungen noch ist sie automatisch die richtige Wahl für dauerhaft ausgelastete Aufgaben oder Anforderungen an lokale physische Schnittstellen. Klären Sie offene Fragen zu Nutzung und Bereitstellung vorab über die zshmac-FAQ.

Häufig gestellte Fragen

Wann soll GitHub Actions den Standard für OpenSSL auf macOS umstellen?

Laut GitHub-Ankündigung ist die schrittweise Bereitstellung vom 02.11.2026 bis zum 08.11.2026 für macOS-26-Runner mit Intel und Arm64 sowie für Xcode-27-Runner mit Arm64 geplant. Das ist ein angekündigtes Zeitfenster, kein Nachweis, dass die Änderung bereits auf jedem Runner angekommen ist. Prüfen Sie die Ankündigung und das konkrete Job-Protokoll erneut, bevor Sie einen Rollout-Termin festlegen.

Wie erkennen Sie, ob ein macOS-Workflow OpenSSL über PATH aufruft?

Suchen Sie in Workflow-Dateien, Shell-Skripten, Build-Skripten und aufgerufenen Aktionen nach openssl-Aufrufen ohne Versionspfad. Lassen Sie im betreffenden Job sowohl den aufgelösten Programmpfad als auch die Versionsausgabe protokollieren. Ein Runner-Label allein belegt nicht, welches Programm ein konkreter Job aus PATH verwendet; entscheidend sind die Ausgaben des tatsächlich ausgeführten Jobs.

Wie lässt sich OpenSSL 3 für einen Workflow gezielt beibehalten?

Die Ankündigung nennt OpenSSL 3 weiterhin über einen versionierten Homebrew-Präfix als verfügbar. Ermitteln Sie den Präfix im Job mit brew --prefix openssl@3 und ergänzen Sie dessen bin-Verzeichnis gezielt für die betroffenen Schritte über PATH. Prüfen Sie danach den aufgelösten Pfad und die Version im Protokoll; verlassen Sie sich nicht auf eine lediglich installierte Formel.

Welche Signatur- und Zertifikatsaufgaben sollten vor der Änderung getestet werden?

Testen Sie die tatsächlich verwendeten Abläufe für Zertifikatserzeugung, Schlüsselverarbeitung, Signierung und TLS-Verbindungen, einschließlich der Prüfung ihrer Ergebnisse durch nachgelagerte Jobs. Vergleichen Sie Artefakte und Validierung mit den Erwartungen Ihres Teams. Ein erfolgreicher Aufruf von openssl allein beweist nicht, dass ein Produktionspaket korrekt signiert oder von Ihrem nächsten Verarbeitungsschritt akzeptiert wird.