OSXBuild vous fournit une machine physique entière, pas une machine virtuelle. Le processeur, la mémoire et le stockage ne sont pas partagés avec d’autres clients. Vous choisissez où stocker vos certificats de signature, votre code source et vos artefacts de build, qui peut y accéder et comment les exporter.
Vérifiez d’abord le mode d’isolation, puis configurez la signature et les accès. Ne mettez jamais de clé privée ni de mot de passe dans un ticket.
Vous disposez d’un nœud physique dédié, pas d’un créneau sur un hôte partagé. Pendant toute la durée de la location, le Mac mini est réservé à vos charges de travail.
Aucun autre client n’exécute de compilation, de tests ou d’inférence sur cette machine. Vos processus de build utilisent ses ressources sans partager le processeur ni la mémoire avec d’autres clients.
Le nombre de tâches exécutées en parallèle sur un même nœud reste déterminé par votre runner et vos scripts de build.
Votre code source, DerivedData, les caches de dépendances et les fichiers IPA exportés restent sur votre nœud. Ils ne risquent pas d’être écrasés par les tâches d’un autre client, et vous n’avez pas à confier vos fichiers de signature à une file de build partagée.
Un cache n’est pas une sauvegarde. Conservez ailleurs une copie de vos artefacts importants et des éléments nécessaires à leur restauration.
Une machine dédiée isole les ressources entre clients. Au sein de votre équipe, attribuez les droits par projet. Utilisez un compte et des clés dédiés pour les builds courants, et ne stockez pas d’identifiants administrateur dans vos pipelines.
L’interface graphique macOS et la ligne de commande sont entièrement disponibles ; vous définissez les accès.
Le code et les artefacts de build présents sur la machine vous appartiennent ; nous ne consultons pas ces contenus métier. Pour obtenir de l’aide au dépannage, transmettez uniquement les extraits d’erreur nécessaires. Avant l’envoi, supprimez les jetons, les éléments de signature et les secrets du projet.
Le répertoire de travail du client précédent n’est jamais remis tel quel au suivant. La récupération comprend l’effacement sécurisé du disque et la réinstallation du système.
Avant la fin de la location, exportez le code source, les fichiers IPA, la configuration et les éléments nécessaires à la restauration de la signature que vous souhaitez conserver. Vérifiez que les fichiers s’ouvrent dans un autre environnement ; ne vous contentez pas de constater que la commande de copie a été exécutée.
À la fin de la location, une fois le nœud récupéré, le disque est effacé de manière sécurisée. La récupération n’est pas un service de stockage temporaire : ne comptez pas sur le nœud pour retrouver vos fichiers après l’échéance.
Le nœud n’est remis à un autre client qu’après la réinstallation du système. Le répertoire de votre projet, les caches de build et les actifs de signature ne sont pas conservés dans l’environnement du nouveau client.
Ajoutez la vérification des sauvegardes à la checklist de passation du projet. Révoquez aussi les accès aux dépôts, les enregistrements de runners et les jetons de distribution dont le nœud n’aura plus besoin. L’effacement du disque local ne révoque pas les autorisations encore valides dans les systèmes externes.
Accordez à vos tâches de build uniquement les droits indispensables à la publication. Ces trois mesures sont bien plus efficaces que de cacher des fichiers dans un dossier discret.
Créez un trousseau dédié au compte de build. Déverrouillez-le uniquement avant l’étape de signature, puis verrouillez-le à nouveau à la fin du pipeline. Prévoyez aussi un nettoyage en cas d’échec afin qu’une sortie inattendue ne laisse pas le trousseau accessible.
Récupérez le mot de passe de déverrouillage dans un coffre de secrets contrôlé ; ne l’affichez pas comme paramètre de commande.
Pour charger des artefacts sur App Store Connect, utilisez une clé API dont les droits correspondent à la tâche, plutôt que d’enregistrer le mot de passe du compte dans un script d’automatisation. Stockez le fichier de clé séparément du code du projet et mettez à jour la configuration de build lors de sa rotation.
Ne placez pas le contenu de la clé dans les journaux, les artefacts de build ou les captures d’écran d’erreur.
Ne validez pas de fichier .p12 contenant une clé privée et ne stockez pas le mot de passe d’exportation dans le même dépôt. Avec Fastlane match, gérez séparément les éléments chiffrés et les identifiants de déchiffrement, et limitez l’accès en lecture au dépôt de signature.
En cas de commit accidentel, évaluez la révocation et la rotation des clés : supprimer le fichier actuel ne suffit pas à effacer son historique.
La commande ci-dessous utilise un chemin de trousseau donné en exemple. Remplacez-le par le nom réel et ajoutez la même opération de nettoyage à la procédure de fin de pipeline.
security lock-keychain "$HOME/Library/Keychains/build.keychain-db"Les identifiants du portail et les clés de connexion au nœud ont des rôles différents. Ne les réutilisez pas et ne les confiez pas à une tâche qui n’a pas besoin de ces droits.
Définissez un mot de passe propre au portail et sécurisez la boîte e-mail qui reçoit les messages de connexion et de vérification. Connectez-vous uniquement depuis un appareil de confiance et ne saisissez pas vos identifiants sur une page transmise par quelqu’un d’autre.
Vérifiez les informations de livraison, l’état de la commande et l’historique des opérations dans le portail. Si vous constatez un changement inattendu, notez le numéro de commande et l’heure, puis ouvrez un ticket. N’ajoutez pas d’identifiants complets à votre message.
Connectez-vous avec une clé publique SSH et gardez la clé privée sur un appareil local sécurisé ou dans le coffre d’identifiants de votre CI. Utilisez une clé distincte pour chaque membre et chaque pipeline afin de pouvoir la révoquer individuellement ; ne partagez pas une clé privée impossible à attribuer.
Vérifiez que la connexion par clé fonctionne et qu’une méthode d’accès de secours est disponible avant de modifier les paramètres de connexion par mot de passe et de port. Retirez rapidement les autorisations d’un membre qui quitte l’équipe ou d’un runner retiré du service.
Associez chaque publication à une révision du code, à un numéro de pipeline et à une version de l’artefact, et limitez l’accès aux journaux de build. Si vous demandez de l’aide, indiquez l’heure de l’erreur et joignez les extraits pertinents de fin de journal ; supprimez les variables d’environnement, les jetons d’accès et les URL de dépôt contenant des identifiants.
Toutes les commandes sont facturées en dollars américains (USD). Seuls les deux modes de paiement ci-dessous sont acceptés. Les options effectivement disponibles sont celles indiquées par l’interface de paiement au moment du règlement.
Les paiements par carte sont traités par Stripe ; OSXBuild ne stocke pas les numéros de carte. Les commandes conservent les informations de paiement nécessaires à la livraison et au rapprochement, sans collecter de numéro de carte pour l’assistance technique.
En cas de problème de paiement, indiquez simplement le numéro de commande, l’heure du paiement et le message d’erreur affiché.
Utilisez uniquement les informations de paiement affichées en temps réel sur la page de règlement. Avant le transfert, vérifiez le réseau, le montant et les coordonnées du bénéficiaire. Ne remplacez pas les informations de la commande en cours par celles d’une ancienne capture d’écran ou d’un e-mail reçu d’un tiers.
Pour nous aider à rapprocher une transaction, fournissez son identifiant ; ne transmettez ni clé privée de portefeuille ni élément de récupération.
Consultez les factures, les renouvellements et l’état des paiements dans le portail. Ne communiquez jamais votre numéro de carte complet, son cryptogramme ni une clé privée à quiconque prétend en avoir besoin pour résoudre un problème de paiement.
Pour signaler un problème de sécurité, un accès anormal ou une fuite présumée d’identifiants, utilisez l’adresse e-mail du support ou un ticket dans le portail après connexion. Il n’existe pas d’adresse e-mail dédiée aux signalements de sécurité.
Si vous n’avez pas encore passé commande ou ne pouvez pas vous connecter, contactez-nous par e-mail. Pour une commande existante, privilégiez un ticket afin de le relier au nœud et aux informations de livraison.
support@osxbuild.com
Si vous pensez qu’une clé a été compromise, révoquez les autorisations concernées et remplacez les identifiants avant d’envoyer votre signalement. Pour vérifier le problème, n’utilisez que des ressources auxquelles vous êtes autorisé à accéder. Ne consultez pas les données d’autres clients et n’effectuez pas de tests destructifs.
Une machine entière vous est réservée et vous gérez vos actifs de signature. Choisissez votre configuration, puis intégrez les clés, les sauvegardes et la checklist de récupération à votre processus de build.