Auditer les chemins absolus présents dans les artefacts Xcode sur un Mac cloud

Une chaîne d’archivage peut fonctionner de manière stable pendant des mois tout en inscrivant dans ses artefacts le compte de build, le répertoire du dépôt ou même le nom d’un espace de travail temporaire. Les traces les plus courantes incluent /Users/runner/, DerivedData, les chemins de volumes montés et l’emplacement complet des fichiers sources. Elles ne modifient généralement pas directement le comportement de l’app, mais révèlent la structure interne à toute personne ayant accès au paquet d’installation, aux fichiers de symboles ou aux journaux. Comme un Mac cloud est réutilisé par de nombreuses tâches, la vérification des chemins doit devenir une étape systématique avant publication, et non une simple recherche de chaînes effectuée occasionnellement.

Définir précisément le périmètre des artefacts à contrôler

Une archive Xcode comprend au moins trois catégories d’objets à distinguer : l’app .app destinée à la distribution, le fichier .dSYM conservé en interne par l’équipe et les journaux de la chaîne de build. Leurs risques ne doivent pas être évalués de la même manière.

La présence d’un véritable répertoire utilisateur dans une app distribuable doit être traitée comme un problème hautement prioritaire. Dans un dSYM, les chemins des sources font partie des informations de débogage : il ne faut donc pas les supprimer dès qu’ils apparaissent. Le véritable problème survient lorsque le fichier est rendu public par erreur ou que ses chemins contiennent des identifiants de tâche qui ne devraient pas être diffusés. L’exposition des journaux dépend de leurs droits d’accès et de leur durée de conservation, mais ils ne doivent pas pour autant conserver durablement des répertoires d’identifiants temporaires ou des noms d’utilisateur personnels.

L’objectif d’un audit des chemins n’est pas d’éliminer toutes les informations de débogage, mais d’éviter que la structure réelle des répertoires de la machine de build ne franchisse une frontière de distribution où elle n’est pas nécessaire.

Lancer l’analyse à partir d’une archive propre

Commencez par fixer le chemin de l’archive afin que le script d’analyse ne crée pas lui-même de répertoire aléatoire. La configuration Release doit être transmise explicitement par la chaîne de build, sans dépendre du dernier Scheme sélectionné sur la machine de développement.

set -euo pipefail

ARCHIVE="$PWD/output/App.xcarchive"

rm -rf "$ARCHIVE"
xcodebuild archive \
  -workspace App.xcworkspace \
  -scheme App \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  -archivePath "$ARCHIVE"

Après avoir localisé l’exécutable principal de l’app, utilisez la commande système strings pour rechercher les motifs les plus révélateurs. Outre /Users/, contrôlez également /Volumes/, DerivedData, .xcworkspace et les préfixes des répertoires temporaires réellement utilisés par l’équipe.

APP="$ARCHIVE/Products/Applications/App.app"
EXEC=$(/usr/libexec/PlistBuddy -c 'Print :CFBundleExecutable' "$APP/Info.plist")
BIN="$APP/$EXEC"
REPORT="$PWD/output/app-paths.txt"

strings -a "$BIN" |
  grep -E '/Users/|/Volumes/|DerivedData|\.xcworkspace|\.xcodeproj' \
  > "$REPORT" || true

if [ -s "$REPORT" ]; then
  cat "$REPORT"
  exit 1
fi

Le fait que l’exécutable principal passe le contrôle ne garantit pas que l’ensemble du paquet soit propre. Il faut également parcourir les frameworks intégrés, les extensions et les fichiers de ressources. Le rapport d’analyse doit indiquer « chemin du fichier, contenu correspondant, type d’artefact », sans téléverser directement dans les journaux l’intégralité d’un binaire ou des variables d’environnement.

Contrôler le dSYM séparément

Pour un dSYM, le contrôle doit porter en priorité sur DW_AT_comp_dir et les enregistrements des fichiers sources, et non sur le nombre de chaînes ordinaires. Commencez par localiser le fichier DWARF, puis affichez les entrées susceptibles de pointer vers le véritable espace de travail.

DSYM="$ARCHIVE/dSYMs/App.app.dSYM"
DWARF="$DSYM/Contents/Resources/DWARF/App"

xcrun dwarfdump --debug-info "$DWARF" |
  grep -E 'DW_AT_(comp_dir|decl_file).*("/Users/|"/Volumes/)' \
  > "$PWD/output/dsym-paths.txt" || true

xcrun dwarfdump --uuid "$DWARF"

L’UUID doit correspondre à celui de l’exécutable présent dans l’archive. S’ils diffèrent, les adresses de plantage ne pourront pas être résolues de manière fiable par la suite, même si les chemins ont été correctement traités.

Réduire l’exposition des répertoires réels avec le mappage des préfixes de compilation

Le compilateur Swift permet de remplacer le préfixe de l’espace de travail par un répertoire logique stable à l’aide de -debug-prefix-map. Clang utilise -fdebug-prefix-map. Dans la configuration Release de Xcode, ajoutez respectivement :

OTHER_SWIFT_FLAGS = $(inherited) -debug-prefix-map $(SRCROOT)=/src
OTHER_CFLAGS = $(inherited) -fdebug-prefix-map=$(SRCROOT)=/src
OTHER_CPLUSPLUSFLAGS = $(inherited) -fdebug-prefix-map=$(SRCROOT)=/src

Ne mappez pas directement l’intégralité de /Users. Une règle trop large peut masquer l’origine de dépendances externes et faire converger par erreur plusieurs répertoires vers le même chemin logique. Mappez en priorité $(SRCROOT) ; si le répertoire d’extraction des dépendances est fixe, ajoutez une règle distincte pour celui-ci.

Après le mappage, vous devez recréer l’archive. Il ne suffit pas de modifier les réglages de build puis de réutiliser l’ancien DerivedData. Vérifiez également que les options sont bien présentes dans les commandes de compilation, car certains scripts personnalisés appellent directement le compilateur en contournant les réglages du projet.

Classer les faux positifs plutôt que de tous les autoriser

L’analyse détecte souvent des exemples de chemins dans des ressources, des fixtures de test ou des textes de débogage tiers. Le traitement doit dépendre de leur emplacement et de leur accessibilité, plutôt que d’une liste globale de termes ignorés qui ne cesse de s’allonger.

Il est recommandé d’utiliser trois niveaux de résultat :

1. Si l’app distribuée ou un composant intégré contient le véritable préfixe de la machine de build actuelle, le contrôle échoue immédiatement.
2. Si le dSYM contient un préfixe de source non mappé, le contrôle échoue, mais le fichier est conservé à des fins de diagnostic.
3. Si des chemins apparaissent dans des journaux internes ou des paquets de résultats de test, une alerte est générée et le périmètre d’accès est vérifié.

Chaque entrée de liste blanche doit préciser « fichier + expression régulière + justification ». Par exemple, si une ressource de test doit réellement afficher /Users/example/, limitez l’exception à cette ressource ; n’ajoutez pas l’ensemble de /Users/ à la liste des motifs ignorés. La chaîne de build doit aussi traiter le chemin de l’espace de travail actuel comme une valeur interdite dynamique, ce qui est plus fiable que d’essayer de deviner tous les noms d’utilisateur possibles.

Éviter que le script d’analyse ne divulgue davantage d’informations

Dans le rapport, le préfixe réel peut être remplacé par $WORKSPACE, en ne conservant que le chemin relatif et le type de correspondance. Même lorsqu’une commande échoue, n’affichez pas l’environnement complet. Si le rapport brut doit être conservé, stockez-le comme pièce jointe de build à accès restreint plutôt que de le développer directement dans une sortie de console lisible par tous les membres.

Revérifier la symbolisation avant publication

Un mappage de chemins peut réussir l’analyse sans garantir que la chaîne de débogage reste complète. Avant publication, conservez au minimum l’app, le dSYM, la liste des UUID et l’identifiant du commit de build, puis effectuez un test de symbolisation à partir d’une véritable adresse d’instruction. Le résultat doit fournir le nom de la fonction et un chemin source logique de la forme /src/..., et non une simple adresse hexadécimale.

Le contrôle final peut se résumer à quatre conditions : aucun préfixe réel de l’espace de travail dans l’app ; UUID du dSYM identique à celui du binaire ; chemins des sources toujours identifiables après mappage ; aucun contenu brut d’analyse développé dans les journaux. Cette approche réduit l’exposition des informations sur les répertoires tout en conservant les éléments nécessaires pour diagnostiquer les incidents en production.

L’audit des chemins peut être exécuté immédiatement après une tâche d’archivage sur un Mac cloud VMOrbit. Il ne dépend pas d’un nom d’utilisateur fixe et n’impose aucune modification de la structure des répertoires sources. Dès lors que la racine de l’espace de travail est fournie de manière uniforme par la chaîne de build, les mêmes règles peuvent couvrir à la fois les tâches temporaires et les nœuds de build permanents.

Questions fréquentes