La compatibilité d’OpenSSL 4 avec la CI macOS ne signifie pas que tous les travaux échoueront : commencez par comparer une exécution réelle avant et après le changement, puis adaptez les dépendances ou fixez explicitement OpenSSL 3 si vos tests démontrent que c’est nécessaire. Cette méthode s’applique surtout aux flux qui appellent OpenSSL depuis des scripts, compilent des dépendances natives ou produisent et vérifient des certificats.

Cet article s’adresse aux responsables de workflows GitHub Actions sur macOS qui veulent repérer les scripts et builds sensibles au changement de valeur par défaut.
Il concerne aussi les développeurs chargés de dépendances natives ou d’intégrations Ruby et Python, ainsi que les responsables DevOps qui doivent choisir entre adaptation, version fixée et report de migration.

Dernière vérification : 23 octobre 2026. À cette date, l’annonce des images Runner prévoit un déploiement progressif, et non un changement déjà achevé. La fenêtre annoncée et son périmètre sont à revérifier dans l’annonce officielle des images Runner avant toute décision de mise en production.

Statut du changement et périmètre des Runner

L’annonce concerne la commande OpenSSL par défaut sur les images macOS 26 et Xcode 27 : son choix doit passer de la version 3.x à la version 4.x. Elle prévoit un déploiement progressif du 2 au 8 novembre 2026 et précise que la version OpenSSL 3 restera disponible. Ces éléments décrivent un changement planifié, pas la preuve qu’il est déjà appliqué à tous les travaux. Consultez l’annonce des mainteneurs pour vérifier les mises à jour de calendrier et de périmètre.

Cette distinction détermine la démarche à suivre. Si le travail s’exécute déjà sur une image concernée, relevez sa version réellement installée et le chemin du binaire appelé ; s’il ne s’y exécute pas encore, préparez une comparaison sans présumer du résultat futur. Pour connaître le contenu documenté de l’image macOS 26, consultez également son inventaire logiciel officiel. Un inventaire décrit une image donnée : il ne remplace pas le relevé de l’environnement dans le travail qui a échoué.

La différence entre « commande par défaut modifiée » et « OpenSSL 3 supprimé » est essentielle. Un script qui lance openssl sans chemin explicite peut recevoir une autre version, tandis qu’un script qui appelle déjà un binaire déterminé peut ne pas être touché de la même manière. Cela ne garantit pas pour autant que ses bibliothèques, ses en-têtes ou ses dépendances s’exécuteront sans changement. Pour le choix du Runner, vérifiez aussi le système demandé par le travail dans la documentation GitHub Actions sur la sélection du Runner.

OpenSSL qualifie la version 4.0 de changement majeur et indique que les programmes utilisant des API dépréciées peuvent nécessiter des ajustements. C’est un motif pour vérifier les composants concernés, mais pas pour déclarer tout projet incompatible : le résultat dépend du code, de la bibliothèque effectivement utilisée et du chemin de construction. La documentation officielle de migration OpenSSL 4.0 délimite les changements à examiner.

Relevé de la commande réellement exécutée

Avant de modifier le workflow, faites produire au même travail quelques lignes de diagnostic au début de l’étape de construction. Une étape temporaire de ce type aide à distinguer le binaire trouvé dans le PATH de celui que l’équipe croyait utiliser :

command -v openssl
which -a openssl
openssl version -a
printf '%s\n' "$PATH"

La commande openssl version affiche la version du programme ; ses options et son comportement sont décrits dans la référence officielle de cette commande. Conservez ensemble le résultat, le nom de l’image sélectionnée, le commit testé et les étapes qui suivent. Sans ce contexte, une ligne indiquant seulement une version ne permet pas de savoir si elle correspond au travail en échec.

Inspectez ensuite les scripts de construction, tests et déploiement pour trouver les usages qui peuvent transformer une différence de version en erreur. Les points à rechercher comprennent un chemin absolu vers un ancien binaire, une comparaison textuelle qui attend un numéro majeur déterminé, l’analyse d’une sortie destinée à une autre version, ou une option omise parce que le script supposait un comportement par défaut particulier. Ne corrigez pas un contrôle simplement parce qu’il voit une version nouvelle : établissez d’abord si le contrôle exprime une exigence de sécurité ou une hypothèse devenue obsolète.

Pour les étapes GitHub Actions, ajoutez le diagnostic au même job que celui qui construit ou teste le projet. Une étape séparée, avec un autre Runner ou un environnement modifié, peut résoudre openssl autrement. En outre, les commandes d’annotation et de journalisation propres aux workflows peuvent influencer la manière dont une sortie est lue ou présentée ; la documentation GitHub sur les commandes de workflow permet de distinguer les messages du journal des résultats produits par le programme.

Analyse distincte des échecs de compilation, de liaison et de chargement

Un message contenant « OpenSSL » ne révèle pas à lui seul la couche fautive. Il faut classer l’échec selon le moment où il apparaît, puis examiner le journal complet et non uniquement la dernière ligne.

  • Compilation : une erreur d’en-tête ou de symbole peut signaler un code qui s’appuie sur une API absente, modifiée ou déclarée obsolète. Vérifiez le composant qui fournit les en-têtes et la version explicitement choisie pendant la compilation.
  • Liaison : si les fichiers sont compilés mais que l’éditeur de liens ne trouve pas une bibliothèque ou un symbole, relevez les chemins de recherche et les dépendances utilisées à cette étape. Cela ne prouve pas que le programme échouera aussi à l’exécution.
  • Chargement à l’exécution : si la compilation aboutit mais que le lancement signale une bibliothèque introuvable ou une incompatibilité de symbole, examinez les bibliothèques réellement chargées et les chemins de recherche du processus. Apple décrit le rôle des chemins d’exécution des bibliothèques dynamiques dans sa documentation sur les bibliothèques dépendantes du chemin d’exécution.

Cette séparation évite deux corrections inutiles : changer un script alors que le problème vient d’une dépendance liée, ou réinstaller une bibliothèque alors que le binaire a été compilé contre des en-têtes incompatibles. Pour Ruby, Python ou une autre chaîne native, relevez quel composant apporte OpenSSL et comment le projet le sélectionne. Ensuite, consultez la documentation de compatibilité du composant concerné, puis reconstruisez le projet dans l’environnement cible. La présence d’une API attendue dans un en-tête ne suffit pas à prouver qu’elle est disponible dans la bibliothèque chargée.

Dans le rapport de diagnostic, notez le nom de la cible, l’étape fautive, l’outil appelé et le chemin de bibliothèque observé. Si l’échec n’est reproductible qu’avec une dépendance mise en cache, refaites une exécution contrôlée avec le cache désactivé ou renouvelé selon la procédure du projet. Le but n’est pas de vider tous les caches par réflexe, mais de savoir si la tâche utilise bien les artefacts que l’équipe croit tester.

Vérification des tâches TLS, certificats et sorties

Les workflows qui manipulent des clés, génèrent des certificats, vérifient une chaîne ou testent une connexion TLS doivent être contrôlés avec leurs commandes réelles. Rejouez chaque étape critique en conservant ses entrées, options, codes de sortie et sorties attendues. Si une étape compare le texte affiché par une commande à une valeur figée, vérifiez que la comparaison porte sur une propriété stable et nécessaire, plutôt que sur un format de sortie supposé immuable.

Pour les opérations sur les certificats X.509, confrontez les options employées à la référence officielle de la commande openssl x509. Réalisez les essais avec des fichiers de test adaptés, sans exposer de clés privées ni de secrets dans les journaux. Une commande de génération ou de vérification qui réussit démontre seulement que cette commande précise a fonctionné dans cet environnement ; elle ne prouve pas que l’application liée à une autre bibliothèque TLS, ou le binaire livré, utilisera le même OpenSSL.

Il faut donc séparer les tests du programme en ligne de commande de ceux de l’application. Pour cette dernière, vérifiez l’intégration réelle : compilation, lancement, négociation TLS dans un environnement de test et validation des certificats selon le comportement attendu. Si le projet utilise une bibliothèque embarquée ou une autre implémentation, ne déduisez pas sa compatibilité de la seule version affichée par openssl.

Comparaison entre poste local et Runner

Un succès local opposé à un échec CI indique une différence d’environnement à mesurer, pas encore une régression attribuable à OpenSSL. Comparez les éléments suivants dans les deux contextes :

  • image système et outils disponibles ;
  • architecture processeur sélectionnée ;
  • valeur et ordre du PATH ;
  • provenance des en-têtes et bibliothèques ;
  • version affichée et chemin du binaire résolu ;
  • dépendances restaurées, caches et étapes de compilation.

Pour attribuer le problème au changement de version, exécutez le même commit avec la même suite de tâches dans deux configurations comparables, puis archivez les journaux de diagnostic et les résultats de tests. Une comparaison où le Runner, les dépendances ou les caches changent simultanément ne permet pas d’isoler la cause. Si l’équipe maintient plusieurs workflows, commencez par les tâches qui appellent réellement OpenSSL ou construisent des dépendances natives ; étendre les essais à toutes les variantes n’est utile qu’après avoir identifié ce périmètre.

Une source de divergence fréquente est la résolution d’une bibliothèque à l’exécution : le terminal peut afficher un binaire, tandis qu’un processus charge une bibliothèque depuis un autre chemin. Inspectez la configuration de liaison et les chemins de chargement associés au programme qui échoue ; l’explication Apple sur les bibliothèques dépendantes du chemin d’exécution aide à comprendre cette différence. Faites également figurer le résultat de command -v openssl dans les journaux de la CI, plutôt que de vous fier à la configuration du poste d’un développeur.

Choix après la comparaison

Le tableau ci-dessous relie les preuves observées à une action possible. Il ne remplace pas la documentation de vos dépendances : il sert à décider quel essai exécuter ensuite.

Situation observée Décision à privilégier Validation avant généralisation
Le projet réussit avec la nouvelle valeur par défaut et ses dépendances confirment la compatibilité Adapter les scripts qui imposent une version ou analysent une sortie fragile Rejouer compilation, tests applicatifs et tâches TLS
Une dépendance exige explicitement OpenSSL 3 ou échoue avec la version 4 dans un test reproductible Sélectionner explicitement OpenSSL 3 selon la méthode prise en charge par l’image et le projet Confirmer le binaire, les bibliothèques chargées et l’absence de dépendance implicite au défaut
Le diagnostic montre un échec de liaison ou de chargement malgré une compilation réussie Corriger la provenance ou les chemins des bibliothèques avant de changer la logique applicative Recompiler puis lancer le binaire dans le Runner cible
Le résultat varie entre poste local et CI sans différence isolée Ne pas conclure encore à une incompatibilité OpenSSL Refaire une comparaison contrôlée avec le même commit, les mêmes dépendances et des journaux conservés

Le maintien explicite d’OpenSSL 3 est une mesure de contrôle lorsqu’une dépendance l’exige ou qu’un test reproductible révèle une régression. Ce n’est pas une raison pour compter durablement sur la version que le Runner choisit par défaut. L’annonce officielle indique qu’OpenSSL 3 restera présent et mentionne la sélection explicite comme moyen d’atténuation ; vérifiez les détails et mises à jour de l’annonce avant d’encoder une procédure de provisionnement.

Liste de vérification avant généralisation

  • [ ] Confirmer que le Runner utilisé est dans le périmètre annoncé et relever sa version réelle.
  • [ ] Enregistrer le chemin de openssl, sa sortie de version et le PATH dans le job concerné.
  • [ ] Repérer les contrôles de version, chemins absolus, options omises et analyses de sortie dans les scripts.
  • [ ] Classer chaque incident comme erreur de compilation, de liaison, de chargement ou de commande.
  • [ ] Vérifier la compatibilité déclarée des dépendances natives avec la version effectivement sélectionnée.
  • [ ] Rejouer les tâches de certificats et TLS réellement présentes dans le workflow, puis tester l’application concernée.
  • [ ] Comparer les résultats sur un même commit, avec les mêmes dépendances et des journaux conservés.
  • [ ] Définir une condition de retour arrière explicite : échec reproductible d’une tâche nécessaire, dépendance non compatible ou résultat TLS incorrect.
  • [ ] Élargir le changement uniquement après validation des cas représentatifs de chaque famille de travaux.

Cette liste doit conduire à une décision opérationnelle. Si les essais réussissent, adaptez les scripts et retirez progressivement les hypothèses devenues inutiles. Si une dépendance indispensable reste incompatible, fixez explicitement la version connue pour fonctionner, documentez qui la met à jour et conservez un test qui permettra de réévaluer ce choix. En cas de résultat contradictoire, différez le basculement pour le workflow concerné jusqu’à ce que l’environnement ou la cause soit isolé.

Pour tester un nœud macOS distinct de la CI existante, l’équipe peut examiner les options de développement Mac à distance proposées par RUVCLOUD et les modalités de location. Un Mac distant apporte un environnement macOS réel pour rejouer les étapes qui en dépendent ; il ne dispense pas de reproduire les Runner, dépendances et scripts de production. Une machine achetée peut mieux convenir à une charge permanente exigeant un accès physique, tandis qu’un Runner hébergé peut être préférable si l’équipe veut éviter d’administrer un nœud dédié. À l’inverse, un poste local ne reproduit pas nécessairement l’environnement exact de la CI. Si ces limites justifient un nœud de test séparé, RUVCLOUD peut être évalué pour exécuter une comparaison contrôlée avant la généralisation.