KalderaShield
Rechtliches

Richtlinie zur Code-Signierung

Zuletzt aktualisiert: Oktober 2026 · In 12 Sprachen verfügbar.

1. Was diese Richtlinie festlegt

Diese Seite legt fest, welche Release-Artefakte von KalderaShield signiert werden, von wem, unter welcher Schlüsselverwahrung und wer für die Freigabe jeder Signatur verantwortlich ist. Die Quellfassung desselben Dokuments im Repository: CODE_SIGNING_POLICY.md

2. Windows

Free code signing provided by SignPath.io, certificate by SignPath Foundation.

Status: noch nicht beantragt. KalderaShield beabsichtigt, sich beim SignPath Foundation zu bewerben, und hat diese Richtlinie vorab erstellt, weil deren Bedingungen verlangen, dass sie vor einer Bewerbung existiert. Die Bewerbung wurde nicht eingereicht und es steht keine Entscheidung aus. Aus diesem Abschnitt darf nicht abgeleitet werden, dass ein Windows-Artefakt derzeit signiert sei. Es ist nicht signiert. Bis die erste signierte Version tatsächlich ausgeliefert ist, gilt die Statustabelle unten, und dieser Abschnitt wird vor dieser Version aktualisiert, nicht danach.

Signiert werden das NSIS-Installationsprogramm (KalderaShield_<version>_x64-setup.exe), das MSI-Paket für verwaltete Bereitstellung (KalderaShield_<version>_x64.msi) und die portable Programmdatei ohne Installation (KalderaShield_<version>_x64-portable.exe). Alle drei werden aus diesem Repository gebaut und auf der Release-Seite veröffentlicht. Kein Artefakt, das nicht aus diesem Repository gebaut wurde, wird mit dem Zertifikat dieses Projekts signiert, und keine Binärdatei Dritter wird darunter neu signiert.

Schlüsselverwahrung: der private Schlüssel wird auf der HSM von SignPath erzeugt und gespeichert. Dieses Projekt hält ihn nie, exportiert ihn nie und übermittelt ihn weder an einen Build-Runner noch an einen Entwicklerrechner. Die Signierung erfolgt auf Seite von SignPath, als Antwort auf eine Signaturanforderung, die die CI dieses Repositorys einreicht und ein Mensch genehmigt.

Kette: ein Version-Tag wird gepusht → GitHub Actions baut die Dateien (Workflows sind öffentlich, Aktionen Dritter sind per Commit-SHA gepinnt, Token-Berechtigungen sind lesend) → der Build lädt sie zu SignPath hoch und stellt eine Signaturanforderung, ohne zu signieren → ein Freigeber genehmigt oder lehnt ab → SignPath signiert mit dem Foundation-Zertifikat → die signierte Datei wird zusammen mit SHA256SUMS.txt veröffentlicht. Jedes Release erfordert eine manuelle Freigabe; es gibt keinen unbeaufsichtigten Signaturpfad und es wird keinen geben.

Eine gültige SignPath-Foundation-Signatur bedeutet, dass die Binärdatei ein überprüfbarer, automatisierter Build des Quellcodes in diesem Repository zum vom Release genannten Commit ist. Sie bedeutet nicht, dass die Software auditiert wurde, und ist keine Sicherheitsempfehlung für die Anwendung. Dieses Projekt veröffentlicht ein Bedrohungsmodell und Qualitätssicherungs-Dokumentation, hat aber kein abgeschlossenes unabhängiges Sicherheitsaudit durch Dritte:

3. Rollen im Team

KalderaShield wird von einer einzigen Person gepflegt. Das wird hier festgestellt, statt als Team dargestellt zu werden, weil die Rollen unten diejenigen sind, die SignPath verlangt und eine einzelne pflegende Person sie nur ehrlicherweise allein ausfüllen kann. Alle Konten mit Schreibzugriff auf dieses Repository verwenden Multi-Faktor-Authentifizierung.

Autoren — Personen, die den Quellcode ohne zusätzliche Prüfung ändern dürfen:

Dies ist das einzige Konto mit Schreibzugriff. Das Repository gehört einem persönlichen Konto und nicht einer Organisation, der Schreibpfad ist also eine einzelne Identität mit MFA darauf.

Prüfer — Personen, die jede von einer Person ohne Commit-Recht vorgeschlagene Änderung vor dem Zusammenführen prüfen:

  • hafgit99

Derzeit gibt es keine Beitragenden ohne Commit-Recht, diese Rolle ist also praktisch nicht nur dünn, sondern leer.

Freigeber — Personen, die jede Signaturanforderung genehmigen, bevor das Artefakt signiert wird:

  • hafgit99

Bekannte Lücke: Da eine Person alle drei Rollen innehat, genehmigt die Person, die den Code schreibt, auch die Signatur. Das Modell von SignPath setzt voraus, dass ein Freigeber "vom gesamten Team vertraut" ist, was mehr als ein Teammitglied voraussetzt. Ein zweiter Freigeber ist geplant und noch nicht eingerichtet. Wer dies für einen Ausschlussgrund hält, sollte es jetzt sagen und nicht erst nach der Freigabe.

4. Datenschutzrichtlinie

In den Worten, die SignPath verlangt: Dieses Programm übermittelt keine Informationen an andere vernetzte Systeme, sofern dies nicht vom Benutzer oder von der Person, die es installiert oder betreibt, ausdrücklich verlangt wird.

KalderaShield ist ein Offline-First-Passwortmanager nach dem Prinzip des Nullwissens. Tresorinhalte werden auf dem Gerät mit aus dem Master-Passwort abgeleiteten Schlüsseln verschlüsselt und niemals übermittelt. Es gibt kein Konto, keinen Synchronisationsdienst, keine Telemetrie und keine Analyse. Die Windows-Binärdateien enthalten über die Komponenten des Betriebssystems hinaus keinerlei Netzwerk-Client. Vollständiger Text: Datenschutzrichtlinie. Das Verhalten Dritter, das Nutzer betrifft, ist in LICENSE-3RD-PARTY.md geregelt.

5. Andere Plattformen

macOS — Artefakte werden mit einer Apple Developer ID signiert und von Apple notarisiert. Das Zertifikat wurde noch nicht ausgestellt, daher ist kein macOS-Artefakt signiert und keines veröffentlicht. Linux — .deb, .rpm und .AppImage werden mit abgetrennten GPG-Signaturen (.sig) veröffentlicht, SBOMs und Browser-Erweiterungspakete mit schlüssellosen Sigstore-Signaturen (.sigstore.json). Android — Release-APKs werden mit einem Release-Keystore aus GitHub-Actions-Secrets signiert; die Android-Signatur ist von Authenticode getrennt. Keine Plattform wird als signiert bezeichnet, bevor sie es ist.

Aktueller Stand: Linux, Android und die Browser-Erweiterung sind veröffentlicht und signiert. Windows wird ausschließlich als unsignierte Vorschau veröffentlicht: eine Vorabversion, keine stabile Version, und latest zeigt nicht darauf. Unsignierte Dateien lösen die SmartScreen-Warnung "Der PC ist geschützt" aus, und Sie müssen auf "Weitere Informationen" → "Trotzdem ausführen" klicken; das ist erwartet. Prüfen Sie vor dem Start die SHA-256-Prüfsumme gegen SHA256SUMS.txt. Die Bewerbung beim SignPath Foundation wurde noch nicht eingereicht. macOS ist nicht veröffentlicht und unsigniert (Zertifikat noch nicht ausgestellt).

Windows-Artefakte werden nicht als Release veröffentlicht: Die Release-Pipeline behandelt ein unsigniertes Desktop-Release als Fehler, und kein Workflow in .github/workflows/ kann eines veröffentlichen. Die Vorschau wird von Hand zusammengestellt und hochgeladen — vom Rechner der betreuenden Person über das Release-Formular von GitHub — und als Vorabversion markiert; sie ist damit sichtbar vorläufig, latest zeigt nie darauf, und die nächste signierte Version ersetzt sie. Dieser Weg ist Absicht und kein Umweg. Das Repository enthält ein Sicherheits-Gate (npm run security:release-signing), das jeden Workflow ablehnt, der einen unsignierten Build in eine Veröffentlichung überführen könnte; dessen abschließende Aussage lautet, dass ohne die Signatur-Secrets ein öffentliches Desktop-Release konstruktionsbedingt unmöglich ist. Eine Ausnahme für einen Workflow hätte diese Aussage um den Preis einer Bequemlichkeit falsch gemacht. Das Hochladen im Browser zu belassen erhält die Zusage. Das Gate ist in der Richtlinie zur Code- und Artefaktsignierung dokumentiert; das schrittweise Vorgehen steht im Plan: Website, dann die unsignierte Windows-Vorschau.

6. Ein Problem melden

Wenn Sie der Meinung sind, dass ein mit einem SignPath-Foundation-Zertifikat signiertes Artefakt diese Richtlinie verletzt, melden Sie es mit dem Hash des Artefakts und dem Grund an support@signpath.io. Für alles andere zu diesen Artefakten nutzen Sie security@kalderashield.com; der Offenlegungsprozess steht in SECURITY.md.

Bei Abweichungen ist der türkische Text dieser Richtlinie maßgeblich.