Sparkle-Abhängigkeit einbinden, damit das Selbst-Update aktiv wird

[trsdn]

Der Selbst-Update-Pfad ist vollständig vorbereitet, aber die Sparkle-Binärabhängigkeit ist noch nicht eingebunden.

Stand

• Sources/OpenFreshrCore/Update/SelfUpdate.swift — UI-freier SelfUpdateChecker, nutzt die vorhandene Appcast- und Versionslogik wieder, 8 Tests.
• Sources/OpenFreshrApp/SelfUpdateController.swift — #if canImport(Sparkle) schaltet auf den echten Updater; ohne Sparkle öffnet ein Fallback nur die Releases-Seite.
• Menüpunkt „Nach OpenFreshr-Updates suchen …" vorhanden, klar getrennt von den Updates fremder Apps.
• docs/appcast.xml als leeres Gerüst, SUPublicEDKey als Platzhalter.

Das Hindernis

swift package resolve scheitert auf dieser Maschine an der globalen Git-Einstellung safe.bareRepository=explicit. Ein kaputter Build wäre schlechter als ein verschobenes Feature, deshalb hält die canImport-Guard alles grün.

Zu tun

• Ursache der SwiftPM-Auflösung klären (Git-Einstellung, oder Sparkle als XCFramework einbinden)
• Sparkle als Abhängigkeit aufnehmen, sodass canImport(Sparkle) im Release-Build greift
• Prüfen, dass der Updater keine unsignierten Updates akzeptiert
• Verifizieren, dass make app und make run weiterhin ohne Signing-Secrets laufen

[trsdn]

Vorschlag, bevor Sparkle eingebunden wird: dieselbe Lösung wie in den anderen trsdn-Apps verwenden, also mxcl/AppUpdater statt Sparkle. OpenLens, OpenDefendrWatchr, OpenZombr und OpenConnct nutzen es seit dem 16.09.2026.

Gründe:

• Broker: Sparkle ist ein eingebettetes .framework mit XPC-Services. Der Notarisierungs-Broker lehnt beides ab, solange das Profil es nicht einzeln deklariert.
• Kein zusätzliches Schlüsselmaterial: Sparkle braucht einen EdDSA-Schlüssel und eine gehostete Appcast. AppUpdater liest direkt die GitHub Releases und prüft die Developer-ID-Signatur (Team ID, Signing-Identifier, Bundle-ID) gegen die installierte App.
• Die SwiftPM-Auflösung aus diesem Issue entfällt teilweise: AppUpdater ist reiner Quellcode, ohne Binär-Artefakt. Die Git-Einstellung safe.bareRepository=explicit betrifft SwiftPM aber generell.

Voraussetzungen:

• Öffentliche Releases: AppUpdater liest Releases über die nicht authentifizierte GitHub-API. Bei einem privaten Repository brauchen die Releases also einen öffentlichen Ort.
• Asset-Name: es braucht ein Release-Asset OpenFreshr-<semver>.dmg. Im Broker ist das ein copy_of-Artefakt (feat: AppUpdater support for openlens, with release publishing macos-notarization-broker#43), und scripts/request.sh <profil> vX.Y.Z --publish lädt es hoch.
• Kein GitHubAttestationPolicy: bei swift build-Produkten endet die Prüfung in fatalError (In-app update verification will reject tag-triggered releases (attested ref is refs/tags/…, policy expects refs/heads/main) OpenWritr#31).

Vorlage: Sources/OpenLens/Update/UpdateManager.swift in trsdn/OpenLens bzw. Sources/OpenDefendrWatchr/Update/UpdateManager.swift in trsdn/OpenDefendrWatchr. Der vorhandene SelfUpdateController mit canImport-Weiche ließe sich auf AppUpdater umstellen.

🤖 Generated with Claude Code

[trsdn]

Entschieden und umgesetzt in #14: Selbst-Update läuft über AppUpdater 4.1.2 aus den eigenen GitHub-Releases, wie bei OpenWritr und OpenSwitchr, nicht über Sparkle. Damit entfällt die SwiftPM-Blockade (swift package resolve und xcodebuild -resolvePackageDependencies laufen), der EdDSA-Schlüssel und der Appcast. Offen bleibt nur die Prüfung mit einem echten notarisierten Release: Update von einer älteren Version aus einem normalen Ordner installieren (kein Symlink im Pfad).