Que vérifier avant le changement OpenSSL 4 de GitHub Actions macOS ? Liste 2026

Symptôme : un job macOS appelle openssl sans version explicite et pourrait obtenir un autre comportement après le changement annoncé.
Solution rapide : vérifiez d’abord les appels résolus par le PATH, puis testez certificats, clés, signatures, TLS et dépendances natives ; fixez OpenSSL 3 uniquement pour les tâches dont la compatibilité est établie.

Cette démarche concerne les équipes qui gèrent des images macOS CI, des workflows iOS ou macOS et des scripts de sécurité. L’annonce vise certains runners, pas l’ensemble des systèmes GitHub Actions.

Dernière vérification : 23 octobre 2026, à partir de l’annonce runner-images de GitHub et de sa documentation sur les runners hébergés. Le déploiement annoncé reste susceptible d’être ajusté.

Périmètre annoncé pour les runners macOS

La migration OpenSSL 4 de GitHub Actions CI macOS n’est pas une bascule générale de tous les runners. Au 23 octobre 2026, GitHub prévoit de modifier progressivement, du 2 au 8 novembre 2026, la commande openssl par défaut sur les images macOS 26 Intel et Arm64, ainsi que sur l’image Xcode 27 Arm64. L’annonce précise qu’OpenSSL 3 doit rester disponible sous un préfixe Homebrew versionné. Le calendrier demeure prévisionnel et peut changer selon les résultats de validation.

Les dates et images de ce tableau reprennent l’annonce officielle de changement des images macOS. Elle ne permet pas de conclure que vos projets échoueront : le risque dépend des commandes réellement exécutées et des résultats attendus par votre code. Pour une vue distincte des environnements pris en charge, consultez la référence des runners hébergés par GitHub.

Un libellé de runner indique une famille d’environnement, pas l’état vérifié de chaque outil au moment où votre job s’exécute. Les images évoluent ; gardez donc une preuve issue du job lui-même plutôt qu’une déduction fondée uniquement sur runs-on.

Appels indirects et hypothèses de version

Le premier point à rechercher n’est pas seulement la chaîne openssl dans le fichier YAML. Un workflow peut déléguer une commande à un script shell, un script de construction, une action réutilisable ou un outil de génération de certificats. Une recherche limitée aux étapes visibles dans le YAML peut ainsi manquer un appel indirect.

Examinez les fichiers de workflow, les scripts versionnés, les scripts installés par le dépôt et les actions internes appelées par les jobs concernés. Pour chaque occurrence, distinguez la commande explicite (openssl3, un chemin complet ou une variable de chemin contrôlée) de la commande générique openssl. Cette dernière laisse la résolution dépendre du PATH effectif.

Dans un job de diagnostic, consignez au minimum :

• le résultat de command -v openssl ;
• la sortie de openssl version ;
• les variables ou étapes qui modifient le PATH ;
• l’image et le type de runner consignés dans les journaux du job ;
• l’étape qui consomme les fichiers produits par la commande.

La documentation GitHub explique comment examiner les logiciels présents dans une image hébergée, mais les journaux de votre exécution restent la preuve la plus proche du comportement observé dans votre workflow. Le guide GitHub sur les images et leur inventaire logiciel vous aide à compléter cette vérification.

Ne comparez pas seulement les étiquettes d’environnement. Conservez, pour chaque exécution, le chemin du binaire et sa version : sans ces deux éléments, une différence de résultat peut être difficile à attribuer à OpenSSL, à l’image ou à une autre modification du job.

Cette échelle est une aide de triage, pas une mesure de compatibilité ni un résultat de test. Une invocation non repérée dans votre dépôt ne prouve pas à elle seule qu’aucun outil appelé par le workflow n’utilise OpenSSL.

Options, sorties et comportements dépendants de la version

Une commande peut être présente sans que le script paraisse lié à une version : l’hypothèse se trouve parfois dans un test, une option, une valeur par défaut ou un analyseur de sortie. Recherchez notamment les conditions qui comparent une chaîne de version, les expressions régulières qui extraient une sortie, et les traitements qui supposent un ordre précis des champs.

Contrôlez aussi les options passées à openssl. L’aide de référence OpenSSL sur les options de format fournit un point de comparaison pour les usages concernés. Elle ne démontre pas qu’un script donné est incompatible : vous devez confronter les options de votre dépôt à la documentation et au résultat de vos propres essais.

Un test pertinent produit une trace exploitable, par exemple la commande, le code de sortie, les fichiers générés et les contrôles effectués ensuite. Si un script analyse du texte retourné par une commande, comparez cette sortie avant et après dans un environnement de test. Ne transformez pas une différence observée dans une commande isolée en panne générale du projet.

Pour les dépendances natives, remontez également les scripts d’installation, les fichiers de configuration et les journaux de compilation. Recherchez les chemins de bibliothèques et les références explicites à une version d’OpenSSL. Lorsqu’une dépendance reste suspecte, construisez-la dans un job isolé : cela sépare un problème de liaison ou d’en-têtes d’une régression dans les étapes de signature.

Certificats, signatures, TLS et constructions natives

Les tâches sensibles ne se limitent pas à la création d’un certificat. Dans votre inventaire, reliez chaque commande OpenSSL au fichier produit, à l’étape qui le vérifie et au système qui le consomme. Un certificat généré avec succès peut encore échouer plus tard lors d’une vérification, d’une signature ou d’un échange TLS.

Pour les certificats et la signature de code, testez les opérations qui existent réellement dans votre chaîne : génération ou conversion de fichiers, traitement de clés, contrôles de signature, puis acceptation du résultat par les étapes de distribution. La documentation Apple décrit le rôle des certificats de signature de code et les étapes de création de code macOS signé pour la distribution. Ces références cadrent les contrôles ; elles ne certifient pas votre workflow.

Côté TLS, vérifiez le comportement attendu par l’application ou le service appelé, pas seulement le code de sortie d’une commande de diagnostic. Conservez les certificats de test, les journaux et les résultats d’intégration conformément aux règles internes de votre équipe. Évitez d’introduire de vraies clés de production dans un essai exploratoire : utilisez un environnement et des secrets prévus pour la validation.

Ces critères sont des preuves à recueillir, pas des garanties de compatibilité universelles. Si l’équipe possède déjà des tests de signature ou des contrôles de livraison, partez de ceux-là : ils mesurent votre contrat réel, contrairement à une commande générique copiée dans un job.

Parcours de validation et choix de retour

Pour organiser les essais sans transformer la production en banc de test, procédez par périmètre fonctionnel. Commencez par un workflow représentatif, puis ajoutez les tâches qui utilisent effectivement certificats, clés, TLS ou dépendances compilées.

1. Repérez les images concernées. Comparez la configuration des workflows aux environnements mentionnés par GitHub et inscrivez séparément les images macOS 26 Intel, macOS 26 Arm64 et Xcode 27 Arm64 lorsqu’elles sont utilisées.
2. Inventoriez les commandes. Recherchez les appels directs et indirects dans le YAML, les scripts, les actions réutilisables et les tâches de compilation. Marquez les usages génériques qui laissent le PATH choisir.
3. Établissez une référence. Avant le changement, archivez les versions observées, les journaux, les artefacts de test et les résultats fonctionnels pertinents. Sans état de référence, une différence après changement sera plus difficile à isoler.
4. Préparez un essai séparé. Dupliquez ou isolez le job représentatif afin de comparer les résultats sans modifier immédiatement la chaîne de production. Gardez les secrets et les permissions conformes aux règles habituelles de l’équipe.
5. Validez les fonctions sensibles. Exécutez les tests qui couvrent certificats, clés, signature, TLS et construction native ; vérifiez également l’acceptation des artefacts par leurs consommateurs.
6. Fixez la version uniquement si nécessaire. Si un job doit conserver OpenSSL 3, utilisez la formule versionnée disponible sur l’image et contrôlez ensuite le chemin effectivement résolu. La fiche Homebrew de openssl@3 documente la formule ; sa présence ne garantit pas que votre job l’utilise automatiquement.
7. Décidez à partir des preuves. Conservez le nouveau comportement si les tâches représentatives satisfont les critères d’acceptation. En cas d’échec, isolez les jobs affectés et appliquez votre procédure de retour arrière existante, puis documentez la cause avant d’élargir le changement.

Si vous ajoutez un chemin versionné à l’environnement du job, utilisez la commande de workflow prévue pour modifier le PATH et vérifiez sa prise en compte dans une étape suivante. La documentation GitHub sur les commandes de workflow et l’ajout au PATH décrit ce mécanisme. Ne présumez pas qu’un réglage fait dans un processus shell restera automatiquement valable dans les étapes suivantes : testez-le dans le contexte exact du workflow.

Pour limiter les surprises, ajoutez aux journaux du job les informations de version qui permettent de reconstruire le diagnostic. La comparaison doit porter sur le même type de tâche, avec les mêmes critères de validation, plutôt que sur une mesure de performance ou une impression générale. Rien dans l’annonce ne permet de déduire un gain ou une perte de vitesse pour votre pipeline.

Questions fréquentes sur la migration

Les réponses ci-dessous portent sur le calendrier publié, la détection des appels par PATH, la conservation d’OpenSSL 3 et les preuves à recueillir pour les opérations de signature. Comme le calendrier annoncé peut évoluer, vérifiez l’annonce avant chaque décision de déploiement.

Capacité Mac temporaire pour un essai séparé

Un runner hébergé est souvent le choix le plus simple lorsque vos tests s’exécutent déjà correctement dans ce modèle. Un Mac acheté en interne peut mieux convenir si votre charge est durable, prévisible et nécessite des interfaces physiques ou un contrôle matériel local ; en contrepartie, vous gérez l’acquisition, le remplacement et l’entretien de la machine.

Pour un essai macOS isolé ou une capacité de construction temporaire, un Mac accessible à distance peut éviter de modifier trop tôt la machine ou le pipeline de production. Si vous comparez les approches, la page de comparaison des solutions Mac peut aider à cadrer les critères ; n’en déduisez pas une compatibilité OpenSSL sans tester votre workflow. Si vous avez besoin de clarifier les contraintes d’un environnement de test temporaire, vous pouvez contacter l’équipe zshmac pour poser vos questions avant de décider. Ce choix ne remplace ni la validation de vos scripts ni votre procédure de retour arrière. Pour une charge stable à long terme ou un besoin d’interface physique, l’achat et l’exploitation interne peuvent rester plus adaptés.

Questions fréquentes