2026 Exklusiver Fern-Mac-CI: Schlüsselbund-Konkurrenz und codesign-Sitzungssperre bei parallelen Jobs — Benutzer-/Schlüsselbund-Partitionierung und reproduzierbare security/codesign-SSH-Entscheidungsmatrix + FAQ

1. TL;DR — was zuerst tun

• Parallelität begrenzen, wenn alle Jobs dieselbe Login-Schlüsselbund-Identität und dieselben Signing-Assets nutzen — oder getrennte CI-Benutzer mit eigenen Schlüsselbünden und Profilen einführen.
• Kein GUI-Prompt über SSH: Headless-codesign und security müssen mit importierten Zertifikaten, korrekt gesetzter Schlüsselbund-ACL und ggf. codesign --timestamp reproduzierbar sein.
• Symptom unterscheiden: Timeout beim Schlüsselbund vs. „resource busy“ vs. fehlgeschlagene Notarisierung — jeweils andere erste Hilfe (siehe Matrix unten).

2. Warum parallele Jobs den Schlüsselbund treffen

Der macOS-Schlüsselbund serialisiert viele sicherheitsrelevante Operationen. Wenn mehrere Prozesse gleichzeitig auf dieselbe Identität (Developer-ID-Zertifikat, Provisioning-Profil-Hashes, API-Schlüssel im Schlüsselbund) zugreifen, wirkt das wie Konkurrenz: Wartezeiten, intermittierende Fehler oder scheinbar zufällige errSecDuplicateItem-/Lock-Meldungen.

codesign hängt nicht nur an Dateien, sondern an der Kryptografie-Sitzung und daran, ob der Signaturdienst die Identität ohne Dialog freigibt. Unter SSH ohne Benutzer-Sitzung fehlen oft die gleichen Kontexte wie bei lokalem Xcode-Klick — daher ist Reproduzierbarkeit wichtiger als maximale Parallelität.

3. Partitionierung: Benutzer und Schlüsselbund

3.1 Pro CI-Job-Benutzer (empfohlen bei harter Parallelität)

Ein dedizierter macOS-Benutzer pro Runner-Instanz oder pro isolierter Pipeline bringt eigene ~/Library/Keychains, eigene Xcode-Derivate und klare TCC-Grenzen. Der Preis: mehr Setup, mehr Speicher für Duplikate — der Gewinn: weniger „geisterhafte“ Schlüsselbund-Kollisionen.

3.2 Ein Benutzer, mehrere Schlüsselbünde

Statt alles in login.keychain zu stapeln, können Sie projekt- oder team-spezifische Schlüsselbünde anlegen und in Skripten explizit mit security list-keychains / security default-keychain (pro Job-Subshell) auswählen. So bleiben Importe und ACLs namensräumlich getrennt.

3.3 Parallelität vs. ein Schlüsselbund

Wenn Sie absichtlich einen Schlüsselbund teilen, setzen Sie Job-Parallelität niedriger als die CPU-Kerne — typisch 1–2 gleichzeitige Signatur-Phasen — und serialisieren xcodebuild archive + Export, wo die Identität stark beansprucht wird.

4. security / codesign: reproduzierbare SSH-Baseline

Über SSH sollten dieselben Befehle wie in einem sauberen nicht-interaktiven Terminal laufen. Checkliste:

• security find-identity -v -p codesigning liefert konsistente Einträge für den CI-Benutzer.
• codesign --verify --deep --strict auf Zwischenartefakten vor dem Upload.
• Keine Abhängigkeit von GUI-Keychain-Prompts; stattdessen vorab importierte Zertifikate und dokumentierte Passphrasen-Strategie (HSM/Secret-Manager statt Klartext in Logs).

5. Entscheidungsmatrix (SSH / Headless)

6. FAQ

F1: Reicht ein Runner-Konto für 8 parallele Xcode-Archive?

Oft nein, wenn alle Archive dieselbe Signing-Identität unter Zeitdruck ansprechen. Entweder weniger parallele Archive oder mehrere Konten mit getrennten Assets.

F2: Soll ich den Schlüsselbund per GUI entsperren?

In Headless-CI sollten Entsperrungen automatisierbar und auditierbar sein — nicht von einem Menschen abhängen, der per VNC klickt. Langfristig: Secret-Store + klare ACLs.

F3: Hilft sudo?

Selten sinnvoll fürs Signieren; es verschiebt oft nur das Problem (andere Umgebung, andere Keychain). Besser: richtiger CI-Benutzer ohne unnötige Rechte-Eskalation.

F4: Wie dokumentiere ich reproduzierbare Befehle?

Runbook mit security- und codesign-Einzeilern, erwarteter Exit-Code und keine Geheimnisse in der Ausgabe — dieselbe Reihenfolge per SSH und lokal.

F5: Ist VNC nötig?

Nur für einmalige GUI-Wizards oder TCC-Freigaben; Dauerbetrieb sollte auf SSH + Automatisierung laufen. Siehe auch die oben verlinkte VNC/SSH-Matrix.

Warum macOS-Hardware diesen CI-Stack trägt

Schlüsselbund, codesign und Xcode sind auf macOS eng mit dem System verzahnt — Gatekeeper, SIP und die Signaturketten sind dort am stabilsten zu automatisieren. Apple Silicon (z. B. M4 im Mac mini) liefert hohe Speicherbandbreite für parallele Builds und geringe Leerlaufleistung (oft nur etwa 4 W), was für 24/7-Runner wichtig ist. Gegenüber zusammengebastelten Windows-VMs entfallen viele Reibungsverluste bei Toolchains und Berechtigungen.

Wenn Sie Schlüsselbund-Partitionierung und reproduzierbare Signatur ohne Rätselraten betreiben wollen, lohnt sich ein klar dimensionierter Mac mini M4 als dedizierter Knoten — die Gesamtkosten bleiben oft unter dem Daueraufwand für Workarounds auf Fremdplattformen. Jetzt einsteigen und die Signatur-CI-Baseline auf passender Hardware ausrollen.