OSXBuild stellt dir eine komplette physische Maschine exklusiv zur Verfügung – keine virtuelle Maschine. CPU, Arbeitsspeicher und Festplatte werden nicht mit anderen Kunden geteilt. Du entscheidest, wo deine Signaturzertifikate, dein Quellcode und deine Build-Artefakte gespeichert werden und wer darauf zugreifen und sie exportieren darf.
Kläre zuerst die Isolation und richte danach Signaturen und Zugriffsrechte ein. Private Schlüssel und Passwörter gehören nicht in Support-Tickets.
Du bekommst einen eigenen physischen Server, keinen Task-Slot auf einem gemeinsam genutzten Host. Während der Mietzeit arbeitet der gesamte Mac mini für deine Workloads.
Andere Kunden führen auf deiner Maschine keine Build-, Test- oder Inferenzaufgaben aus. Deine Build-Prozesse nutzen die Ressourcen des Rechners, ohne CPU oder Arbeitsspeicher mit anderen Kunden teilen zu müssen.
Wie viele parallele Aufgaben auf dem Server laufen, steuerst du weiterhin über deinen Runner und deine Build-Skripte.
Quellcode, DerivedData, Dependency-Caches und exportierte IPAs liegen auf deinem Server. Sie werden nicht überschrieben, wenn ein anderer Kunde einen Job startet. Signaturdateien musst du auch nicht an eine gemeinsame Build-Warteschlange übergeben.
Ein Cache ist kein Backup. Sichere wichtige Artefakte und Wiederherstellungsdaten zusätzlich an einem anderen Ort.
Eine komplette Maschine für dich allein trennt die Ressourcen der Kunden. Die Zugriffsrechte innerhalb deines Teams solltest du weiterhin projektbezogen vergeben. Nutze für Builds eigene Benutzer und Schlüssel, statt Admin-Zugangsdaten in Pipelines zu hinterlegen.
Die macOS-Oberfläche und die Kommandozeile stehen vollständig zur Verfügung. Du legst fest, wer worauf zugreifen kann.
Der Code und die Build-Artefakte auf der Maschine gehören dir. Wir lesen diese geschäftlichen Daten nicht aus. Stelle uns zur Fehleranalyse nur die nötigen Ausschnitte zur Verfügung und entferne vor dem Versand Tokens, Signaturmaterial und vertrauliche Projektdaten.
Das Arbeitsverzeichnis des vorherigen Kunden wird nicht einfach an den nächsten weitergegeben. Zur Rückgabe gehören das sichere Löschen der Festplatte und eine Neuinstallation des Systems.
Exportiere vor Mietende den Quellcode, die IPAs, Konfigurationen und Signaturdaten, die du behalten möchtest. Prüfe, ob sich die Dateien in einer anderen Umgebung öffnen lassen – die Meldung „Kopieren abgeschlossen“ allein reicht nicht.
Nach Mietende und Rückgabe wird die Festplatte sicher gelöscht. Die Rückgabe ist kein Archivierungsservice. Verlasse dich nicht darauf, nach Ablauf der Mietzeit noch einmal Dateien vom Server abrufen zu können.
Erst nach der Neuinstallation wird der Server an den nächsten Kunden übergeben. Deine Projektverzeichnisse, Build-Caches und Signaturdaten bleiben nicht als Ausgangsumgebung für den nächsten Kunden erhalten.
Nimm die Backup-Prüfung in deine Projekt-Checkliste auf und widerrufe Zugriffe auf Repositories, Runner-Registrierungen und Verteilungstokens, die der Server nicht mehr benötigt. Das Löschen der lokalen Festplatte widerruft keine Berechtigungen, die in externen Systemen weiterhin gültig sind.
Gib Build-Jobs nur die Berechtigungen, die sie für eine Veröffentlichung benötigen. Diese drei Maßnahmen sind wirksamer, als Dateien einfach in einem schwer auffindbaren Verzeichnis abzulegen.
Richte für den Build-Benutzer einen eigenen Schlüsselbund ein. Entsperre ihn erst unmittelbar vor dem Signieren und sperre ihn nach Ende der Pipeline wieder. Auch bei fehlgeschlagenen Jobs sollte die Bereinigung ausgeführt werden, damit der Schlüsselbund nicht nach einem unerwarteten Abbruch offen bleibt.
Lies das Entsperrpasswort aus einem geschützten Credential Store aus und gib es nicht als Befehlsparameter aus.
Verwende für Uploads zu App Store Connect einen API-Schlüssel mit den für den Job erforderlichen Berechtigungen, statt ein Kontopasswort in Automatisierungsskripten zu speichern. Bewahre die Schlüsseldatei getrennt vom Projektcode auf und aktualisiere beim Wechsel des Schlüssels auch die Build-Konfiguration.
Schlüssel gehören weder in Logs noch in Build-Artefakte oder Fehler-Screenshots.
Committe keine .p12-Dateien mit privaten Schlüsseln und lege das Exportpasswort nicht im selben Repository ab. Wenn du Fastlane match verwendest, verwalte verschlüsselte Dateien und Entschlüsselungsdaten getrennt und beschränke den Lesezugriff auf das Signatur-Repository.
Bei einer versehentlichen Veröffentlichung solltest du Widerruf und Austausch prüfen. Die aktuelle Datei zu löschen, entfernt sie nicht aus der Versionshistorie.
Der folgende Befehl verwendet einen Beispielpfad für den Schlüsselbund. Ersetze ihn durch den tatsächlichen Namen und führe dieselbe Bereinigung am Ende der Pipeline aus.
security lock-keychain "$HOME/Library/Keychains/build.keychain-db"Die Zugangsdaten für dein Kundenkonto und die Schlüssel für den Server erfüllen unterschiedliche Aufgaben. Verwende sie nicht mehrfach und gib sie keinen Jobs, die diese Berechtigungen nicht benötigen.
Verwende für dein Kundenkonto ein eigenes Passwort und sichere das E-Mail-Konto, über das du Anmelde- und Bestätigungsmails erhältst. Melde dich nur auf vertrauenswürdigen Geräten an und gib deine Zugangsdaten nicht auf Seiten ein, die dir andere weitergeleitet haben.
Prüfe Übergabedaten, Bestellstatus und zugehörige Vorgänge in deinem Kundenkonto. Wenn eine Änderung nicht deinen Erwartungen entspricht, notiere Bestellnummer und Zeitpunkt und eröffne ein Support-Ticket. Füge darin niemals vollständige Zugangsdaten bei.
Melde dich mit einem öffentlichen SSH-Schlüssel an. Bewahre den privaten Schlüssel auf einem geschützten lokalen Gerät oder in einem CI-Credential Store auf. Nutze für jedes Teammitglied und jede Pipeline einen eigenen Schlüssel, damit du Berechtigungen einzeln widerrufen kannst und keine gemeinsam genutzten, nicht nachvollziehbaren Schlüssel entstehen.
Prüfe, ob die Verbindung mit dem Schlüssel funktioniert, und stelle einen Wiederherstellungszugang sicher, bevor du Passwortanmeldung oder Portregeln änderst. Entferne die Berechtigungen ausgeschiedener Teammitglieder und stillgelegter Runner umgehend.
Verknüpfe jede Veröffentlichung mit Commit, Pipeline-Nummer und Artefaktversion und beschränke den Zugriff auf Build-Logs. Wenn du Unterstützung benötigst, notiere den Fehlerzeitpunkt und die relevanten letzten Logzeilen. Entferne Umgebungsvariablen, Zugriffstokens und Repository-Adressen mit Zugangsdaten.
Alle Bestellungen werden in US-Dollar (USD) abgerechnet. Es gibt ausschließlich die beiden folgenden Zahlungsmethoden. Welche Zahlungsoptionen verfügbar sind, richtet sich nach der Rückmeldung des Zahlungssystems.
Kreditkartenzahlungen werden über Stripe abgewickelt. OSXBuild speichert keine Kartennummern. Bestelldaten enthalten nur den für Bereitstellung und Abrechnung erforderlichen Zahlungsstatus. Kartennummern werden nicht als Support-Unterlagen erfasst.
Bei Zahlungsproblemen genügen Bestellnummer, Zahlungszeitpunkt und die angezeigte Fehlermeldung.
Verwende ausschließlich die aktuellen Zahlungsdaten auf der Checkout-Seite. Prüfe vor der Überweisung Netzwerk, Betrag und Empfänger. Verlasse dich nicht auf ältere Screenshots oder Adressen aus E-Mails anderer Personen.
Für einen Zahlungsabgleich genügt die Transaktions-ID. Gib niemals private Wallet-Schlüssel oder Wiederherstellungsdaten weiter.
Rechnungen, Verlängerungen und Zahlungsergebnisse findest du in deinem Kundenkonto. Wer zur Fehleranalyse nach der vollständigen Kartennummer, dem Sicherheitscode oder einem privaten Schlüssel fragt, sollte diese Daten nicht erhalten.
Sicherheitsmeldungen, ungewöhnliche Berechtigungen und mögliche Zugangsdaten-Lecks meldest du über die Support-E-Mail-Adresse oder ein Ticket in deinem Kundenkonto. Es gibt keine separate E-Mail-Adresse für Sicherheitsmeldungen.
Wenn du noch keine Bestellung aufgegeben hast oder dich nicht anmelden kannst, nutze die E-Mail-Adresse. Bei Fragen zu einer bestehenden Bestellung ist ein Support-Ticket am besten, da es sich mit Server und Übergabedaten verknüpfen lässt.
support@osxbuild.com
Wenn ein Schlüssel möglicherweise kompromittiert wurde, widerrufe zuerst die zugehörigen Berechtigungen und tausche die Zugangsdaten aus. Melde den Vorfall anschließend. Prüfe nur Ressourcen, auf die du zugreifen darfst. Lies keine Daten anderer Kunden aus und führe keine destruktiven Tests durch.
Du nutzt den gesamten Server exklusiv und verwaltest deine Signaturdaten selbst. Wähle deine Konfiguration und integriere Schlüssel, Backups und Rückgabe-Checkliste in deinen Build-Prozess.