Comment configurer le proxy d’entreprise de Swift Package Manager ? Guide Mac CI 2026

Apple documente des exigences réseau distinctes pour ses services d’entreprise, tandis que Swift Package Manager décrit séparément l’usage des registres de paquets et Git conserve sa propre logique de configuration. Cette séparation de quatre familles de flux est le premier fait opérationnel à retenir : dépôts source, Swift Package Registry, artefacts binaires et services Apple ne doivent pas être traités avec une seule variable HTTP_PROXY documentation Apple sur les exigences réseau des mises à jour logicielles et documentation Swift Package Manager sur les registres.

Notre recommandation pour cette semaine est donc précise : cartographiez ces flux, reproduisez le test avec le véritable compte de service CI et un espace de travail vierge, puis ne placez en pool de Mac distant que les tâches dont le proxy, les certificats et la reprise après redémarrage ont été prouvés.

Cet article s’adresse aux responsables IT qui gèrent le proxy, le pare-feu et les autorités de certification internes d’un parc de build macOS. Il concerne aussi les équipes plateforme confrontées à un écart entre un poste local fonctionnel et un Runner CI en échec, ainsi que les décideurs qui évaluent un parc interne face à des Mac distants pour les équipes de développement.

Le premier diagnostic ne consiste pas à ajouter une adresse de proxy dans le profil du Runner. Il consiste à répondre, pour chaque dépendance, à cinq questions : quelle est la destination, quel protocole est utilisé, quel outil ouvre la connexion, quel compte l’exécute et quelle identité l’authentifie ?

Nous séparons les flux de la manière suivante :

• Dépôts source Git : dépendances référencées par une URL HTTPS ou SSH, avec des réglages qui relèvent de Git ou de SSH.
• Swift Package Registry : paquets distribués par l’API de registre, avec une configuration et des identifiants qui ne se confondent pas nécessairement avec ceux d’un dépôt Git. Le format et les commandes de registre sont décrits dans la documentation officielle de Swift Package Manager.
• Artefacts binaires : archives ou produits téléchargés par une dépendance, avec une chaîne TLS et une autorisation propres.
• Services Apple : services utilisés par Xcode, les mises à jour, la signature ou d’autres opérations Apple. Leurs exigences réseau doivent rester séparées des règles appliquées à un dépôt interne, comme le rappelle la documentation de déploiement Apple.

Pour chaque ligne, nous notons également la résolution DNS observée, la décision du proxy, la chaîne de certificats et le processus réellement impliqué. Le but n’est pas de constituer une liste permanente de domaines et de ports non vérifiée : les destinations évoluent, et une liste copiée depuis un ancien ticket peut donner une fausse impression de couverture.

Avant toute modification, nous réalisons une exécution de référence sur un espace de travail propre. Le journal doit montrer l’étape de résolution, l’outil lancé, le compte utilisé et l’erreur complète. Un simple message « téléchargement impossible » ne permet pas de distinguer une absence de route, un refus du proxy, une erreur TLS ou une authentification applicative.

Point de contrôle : une résolution réussie depuis le Terminal d’un administrateur ne prouve ni que le compte du Runner possède le même environnement, ni que xcodebuild utilise le même fournisseur SCM, ni que le trousseau accessible au service contient l’autorité attendue.

La première heure de configuration doit se dérouler sous l’identité qui exécutera réellement les tâches. Il peut s’agir d’un compte de service Jenkins, d’un Runner GitHub Actions, d’un agent GitLab ou d’un autre exécuteur. La méthode varie selon la plateforme ; nous vérifions donc sa documentation officielle avant de conclure qu’une variable est héritée.

Sur macOS, plusieurs couches peuvent coexister sans se synchroniser :

• les réglages réseau du système ou de la session graphique ;
• les variables HTTP_PROXY, HTTPS_PROXY et NO_PROXY du processus CI ;
• la configuration Git, notamment pour les connexions HTTP ;
• la configuration SSH et ses règles d’hôte ;
• le trousseau et les certificats approuvés par le compte de service ;
• les paramètres propres à Xcode et à xcodebuild.

Git documente ses propres mécanismes de proxy et de transport dans sa FAQ officielle sur les problèmes réseau. Nous inspectons la provenance des valeurs avec une commande de lecture telle que git config --show-origin --get-regexp 'http\..*proxy|url\..*insteadOf', sans écrire de secret dans le journal. La documentation Git sur la configuration HTTP doit être consultée pour les options effectivement disponibles dans l’environnement déployé.

Le principe de moindre privilège est déterminant. Nous n’importons pas le trousseau personnel d’un développeur, nous ne copions pas les identifiants d’un administrateur et nous ne réutilisons pas une clé privée individuelle sur un nœud partagé. Un compte de service doit avoir uniquement les accès nécessaires aux dépôts, au registre et aux artefacts autorisés.

Cette séparation réduit aussi les coûts d’exploitation : lorsqu’un certificat ou un jeton doit être renouvelé, l’équipe peut identifier sa portée sans modifier une session interactive inconnue.

La première configuration fonctionnelle doit rester minimale. Nous traitons d’abord un dépôt Git en HTTPS, puis un dépôt Git en SSH si le projet en dépend, ensuite le Registry et enfin le téléchargement d’un artefact binaire. Une réussite sur le premier canal ne valide pas les trois autres.

Pour HTTPS Git, nous vérifions l’origine de la configuration, la variable héritée par le processus et l’autorisation présentée au dépôt. Pour SSH, nous contrôlons la configuration du compte de service, la clé utilisée et la résolution de l’hôte, sans supposer qu’un proxy HTTP sera pris en compte par SSH. Les règles de réécriture d’URL doivent également être examinées, car elles peuvent rediriger une dépendance vers une destination qui ne figure pas dans la politique réseau prévue.

Pour le Registry, nous suivons la configuration propre à Swift Package Manager et confirmons que l’identité du Runner peut lire le paquet concerné. La documentation officielle décrit les conventions du registre ; elle ne transforme pas automatiquement un dépôt Git privé en registre compatible. Cette distinction évite de corriger un mauvais composant, par exemple en ajoutant une exception proxy alors que le problème vient d’un identifiant absent.

Pour un artefact binaire, nous observons l’URL, la négociation TLS et la réponse d’autorisation. Une autorité interne peut être nécessaire, mais son installation ne doit pas être effectuée par une commande de contournement dans le script de build. Nous passons par le profil de gestion macOS, la politique de sécurité et la procédure de révocation de l’entreprise.

Enfin, nous verrouillons Package.resolved lorsque le projet le permet et nous contrôlons le comportement d’auto-résolution dans la chaîne CI. Apple recommande de concevoir les workflows de construction des paquets et des applications Swift avec une logique reproductible ; les principes sont détaillés dans le guide Apple consacré à l’intégration continue. L’objectif est qu’un même commit ne récupère pas silencieusement un graphe de dépendances différent selon le nœud.

La question « xcodebuild utilise-t-il le proxy Git du système ? » ne reçoit pas une réponse universelle indépendante de la version de Xcode, du fournisseur SCM sélectionné et du type de dépendance. Nous vérifions donc le comportement dans l’environnement cible, au lieu de considérer une option ou une variable comme une garantie générale.

Lorsque le workflow doit déléguer la récupération SCM à Git du système, nous évaluons le réglage correspondant du fournisseur SCM de xcodebuild, puis nous vérifions dans les journaux que le processus attendu est bien employé. La référence Apple sur la construction de paquets en CI constitue le point de départ approprié ; toute option présentée dans un script doit être comparée à la version de Xcode réellement installée, et non à un exemple ancien.

La couche TLS nécessite un diagnostic distinct. Nous classons l’échec selon trois preuves :

• Proxy : la requête atteint-elle le relais, et celui-ci autorise-t-il la destination ?
• Certificat : la chaîne présentée correspond-elle à l’autorité approuvée par le compte de service ?
• Application : la connexion TLS réussit-elle mais l’API refuse-t-elle l’identité ou le chemin demandé ?

Les services Apple soumis à des exigences particulières ne doivent pas être inspectés de la même façon qu’un dépôt interne. La politique d’inspection HTTPS de l’entreprise doit intégrer les exceptions Apple documentées, tandis que les dépôts, registres et artefacts internes doivent suivre leur propre stratégie de certificat. Désactiver la vérification TLS pour « faire passer » une dépendance est exclu : cela transforme une panne visible en exposition durable des identifiants et du code source.

Pourquoi Swift Package Manager échoue-t-il derrière un proxy ?

Parce que le projet peut appeler plusieurs services avec des chemins d’exécution différents. HTTP_PROXY peut être présent dans le processus CI sans être utilisé par SSH, par un trousseau ou par un mécanisme de registre. Nous comparons donc le flux en échec avec la carte initiale et le compte réel, plutôt que de modifier toutes les couches simultanément.

Comment faire utiliser la configuration Git du système par xcodebuild ?

Nous lisons d’abord la configuration avec son origine, sous le compte du Runner, puis nous testons le comportement du fournisseur SCM choisi par xcodebuild. Le résultat doit être confirmé avec une dépendance HTTPS réelle et un espace vierge. La présence d’un proxy dans le Git d’un administrateur ne prouve pas que le service CI le voit.

L’inspection HTTPS peut-elle bloquer la résolution des paquets ?

Oui, si elle remplace la chaîne de certificats attendue ou si elle s’applique à un service qui doit rester hors inspection. Nous séparons les exceptions Apple des autorités internes et nous vérifions la chaîne avec le processus réel. Aucun script de build ne doit neutraliser la validation TLS pour masquer une erreur de déploiement.

Comment un compte de service récupère-t-il les certificats ?

Il ne les récupère pas automatiquement depuis la session d’un administrateur. Nous déployons l’autorité par le mécanisme de gestion approuvé, vérifions sa visibilité pour le compte concerné et testons la rotation. Les secrets et certificats doivent être associés à l’identité du Runner, avec une durée et une révocation contrôlées.

Comment un Mac distant accède-t-il au Git et au Registry internes ?

Nous lui appliquons une politique réseau dédiée, une identité de service limitée et les exceptions nécessaires, puis nous testons séparément les quatre familles de flux. Un nœud distant ne doit rejoindre la production que si la résolution, l’authentification, la construction et la reprise après incident sont démontrées.

Une chaîne réellement validée commence sans cache utile et sans session interactive ouverte. Nous lançons successivement la résolution des dépendances, la construction avec xcodebuild, les tests et la génération de l’artefact attendu. Chaque étape doit conserver son journal, son identité d’exécution et la destination réseau observée.

Notre contrôle d’acceptation distingue quatre résultats :

• Réseau accessible : les destinations nécessaires sont atteignables selon la politique approuvée.
• Dépendances résolues : Git, Registry et artefacts binaires fonctionnent chacun sur leur chemin réel.
• Construction reproductible : le commit et le fichier de résolution produisent le graphe attendu.
• Tâche récupérable : le service reprend après redémarrage, reconnexion et renouvellement des secrets.

La documentation Apple sur les workflows CI pour les paquets Swift sert de référence pour le scénario de construction, mais l’acceptation doit rester propre à l’entreprise : dépôt interne, autorité interne, proxy, règles d’accès et procédure de signature.

Nous ajoutons ensuite les tests de redémarrage du Mac, de reconnexion du compte de service, de rotation d’un certificat et d’indisponibilité temporaire du proxy. Un résultat « téléchargement réussi » obtenu une seule fois ne suffit pas à autoriser une chaîne de production.

Checklist d’acceptation

• [ ] La carte distingue les dépôts Git, le Registry, les artefacts binaires et les services Apple.
• [ ] Le test est exécuté avec le compte réel du Runner, et non avec un administrateur.
• [ ] Les réglages système, variables d’environnement, Git, SSH et trousseau sont vérifiés séparément.
• [ ] Les secrets personnels ne sont pas présents sur le nœud partagé.
• [ ] HTTPS Git et SSH Git ont été testés indépendamment.
• [ ] Le Registry et les téléchargements binaires ont chacun une preuve de fonctionnement.
• [ ] Les exceptions d’inspection HTTPS sont justifiées par la politique Apple ou l’architecture interne.
• [ ] Aucun script ne désactive la vérification des certificats.
• [ ] Package.resolved et le comportement d’auto-résolution sont contrôlés.
• [ ] Une construction avec xcodebuild a été réalisée depuis un espace vierge.
• [ ] Le redémarrage du nœud et la reconnexion du service CI ont été vérifiés.
• [ ] La rotation des certificats ou des jetons possède une procédure documentée.
• [ ] La récupération après indisponibilité du proxy a été observée avant le passage en production.

Après la première chaîne complète, nous plaçons le nœud dans une phase de grisage limitée aux tâches non productives. Cette étape permet de comparer les journaux, les dépendances réellement utilisées et les incidents de reprise sans exposer immédiatement les signatures de production.

Les nœuds qui doivent atteindre le réseau interne ne doivent pas forcément partager la même politique que les nœuds consommant uniquement des dépendances publiques. Nous recommandons une séparation logique entre ces usages, ainsi qu’une frontière de confiance indépendante pour les tâches de signature. L’extension du pool ne se décide pas à partir d’un seul succès, mais à partir de preuves accumulées dans les journaux d’exécution et de récupération.

Si un Mac existant ne sait pas appliquer proprement les exceptions du proxy, si le compte CI perd ses réglages après redémarrage ou si aucune reprise distante n’est possible, trois choix restent ouverts : corriger l’équipement actuel, ajouter un nœud dédié ou utiliser un pool de Mac distants. Pour une équipe qui veut tester cette dernière option, les modalités de location de Mac distants pour une validation d’entreprise permettent de comparer un nœud isolé avec la même carte de flux et la même checklist, sans confondre un problème de réseau avec un problème de matériel local.

Notre méthode de décision est conditionnelle :

• si le nœud applique les règles réseau, conserve l’identité du service et reprend après redémarrage, il peut entrer dans un pool contrôlé ;
• si seuls les flux publics fonctionnent, il reste adapté aux tâches publiques mais pas aux dépendances internes ;
• si les dépendances internes fonctionnent mais que la reprise distante échoue, il ne doit pas porter une tâche de production sans remédiation ;
• si la politique d’inspection ou le routage ne peut pas être appliqué de manière vérifiable, le nœud doit rester hors production.

Cette approche est également pertinente pour des équipes audio, vidéo ou design qui construisent des outils macOS avec des dépendances binaires lourdes : l’important n’est pas seulement le téléchargement initial, mais la continuité du compte de service, la reproductibilité du projet et la possibilité de récupérer le nœud sans intervention physique.

Un Mac interne peut sembler plus simple, mais il concentre souvent les responsabilités : réseau, alimentation, accès physique, certificats, compte CI et récupération après incident. Un poste configuré pour un développeur peut fonctionner en session interactive tout en échouant dès qu’un service sans interface graphique doit récupérer une dépendance ou accéder au trousseau.

Un pool de Mac distants n’élimine pas la nécessité de concevoir la politique réseau. Il permet en revanche de tester séparément la livraison du nœud, l’accès distant, la continuité du service et l’extension de capacité. La décision reste défavorable à la location lorsque l’équipe exige un périphérique physique local, une charge soutenue et parfaitement stable pendant une longue période, ou une intégration réseau impossible à exposer selon les règles de sécurité internes.

Pour les autres cas, nous conseillons d’utiliser exactement le même scénario d’acceptation sur un nœud distant : carte des flux, compte CI, certificats, dépendances privées, construction propre et redémarrage. Les options de nœuds Mac distants par région peuvent servir à isoler cette validation avant de décider une capacité partagée ou un pool dédié.

Le proxy d’entreprise de Swift Package Manager n’est donc pas un réglage unique à copier dans chaque Runner. En séparant les flux, en vérifiant les portées et en refusant les contournements TLS, nous obtenons une preuve exploitable pour l’audit et pour l’exploitation quotidienne. Une fois la première chaîne acceptée, le choix entre équipement interne et Mac distant peut être fondé sur la récupération réelle, l’accès aux dépendances et la capacité à appliquer la même politique à plusieurs nœuds.