Politique de signature de code

1. Ce que cette politique détermine

Cette page indique quels artefacts de publication de KalderaShield sont signés, par qui, sous quel mode de conservation des clés et qui est responsable de l'approbation de chaque signature. La version source du même document dans le dépôt : CODE_SIGNING_POLICY.md

2. Windows

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

Statut : candidature pas encore déposée. KalderaShield a l'intention de candidater auprès de la SignPath Foundation et a préparé cette politique en amont, car leurs conditions exigent qu'elle existe avant toute candidature. La candidature n'a pas été déposée et aucune décision n'est en attente. Rien dans cette section ne doit être lu comme une affirmation selon laquelle un artefact Windows serait actuellement signé. Il ne l'est pas. Tant que la première version signée n'a pas été effectivement publiée, la formulation honnête est le tableau d'état ci-dessous, et cette section sera mise à jour avant cette version, pas après.

Les fichiers à signer sont l'installeur NSIS (KalderaShield_<version>_x64-setup.exe), le paquet MSI pour déploiement géré (KalderaShield_<version>_x64.msi) et l'exécutable portable qui ne nécessite aucune installation (KalderaShield_<version>_x64-portable.exe). Les trois sont construits depuis ce dépôt et publiés sur la page des versions. Aucun artefact qui n'est pas construit depuis ce dépôt n'est signé avec le certificat de ce projet, et aucun binaire tiers n'est resigné avec lui.

Conservation des clés : la clé privée est générée et conservée dans le HSM de SignPath. Ce projet ne la détient jamais, ne l'exporte jamais et ne la transmet jamais à un agent de build ni à une machine de développeur. La signature a lieu du côté de SignPath, en réponse à une demande de signature soumise par la CI de ce dépôt et approuvée par une personne.

Chaîne : une étiquette de version est poussée → GitHub Actions construit les fichiers (workflows publics, actions tierces épinglées par SHA de commit, permissions de jeton en lecture seule) → le build les envoie à SignPath et ouvre une demande de signature sans signer → un approbateur approuve ou refuse → SignPath signe avec le certificat de la Foundation → le fichier signé est publié avec SHA256SUMS.txt. Chaque version exige une approbation manuelle ; il n'existe aucun chemin de signature non supervisé et il n'en sera pas ajouté.

Une signature SignPath Foundation valide signifie que le binaire est un build automatisable et vérifiable du code source de ce dépôt au commit indiqué par la version. Cela ne signifie pas que le logiciel a été audité, et ce n'est pas une approbation de sécurité de l'application. Ce projet publie un modèle de menace et une documentation de qualité, mais ne dispose d'aucun audit de sécurité indépendant réalisé par un tiers :

3. Rôles dans l'équipe

KalderaShield est maintenu par une seule personne. Cela est indiqué ici plutôt que présenté comme une équipe, car les rôles ci-dessous sont ceux exigés par SignPath et une personne seule ne peut honnêtement les occuper qu'elle-même. Tous les comptes disposant d'un accès en écriture à ce dépôt utilisent l'authentification multifacteur.

Auteurs — personnes pouvant modifier le code source sans revue supplémentaire :

hafgit99 — github.com/hafgit99

C'est le seul compte disposant d'un accès en écriture. Le dépôt appartient à un compte personnel et non à une organisation : le chemin d'écriture est donc une identité unique assortie de l'authentification multifacteur.

Relecteurs — personnes qui examinent chaque modification proposée par quelqu'un sans droit de commit avant sa fusion :

hafgit99

Il n'y a actuellement aucun contributeur sans droit de commit ; ce rôle est donc, en pratique, non pas seulement mince mais vacant.

Approbateurs — personnes qui approuvent chaque demande de signature avant que l'artefact ne soit signé :

hafgit99

Faiblesse connue : une seule personne détenant les trois rôles, la personne qui écrit le code approuve aussi sa signature. Le modèle de SignPath suppose qu'un approbateur est « digne de confiance pour toute l'équipe », ce qui présuppose plus d'un membre d'équipe. L'ajout d'un second approbateur est prévu mais pas encore fait. Qui considère cela comme un motif d'exclusion devrait le dire maintenant plutôt qu'après l'approbation.

4. Politique de confidentialité

Dans les termes demandés par SignPath : ce programme ne transfère aucune information vers d'autres systèmes connectés à moins que l'utilisateur ou la personne qui l'installe ou l'exploite ne le demande expressément.

KalderaShield est un gestionnaire de mots de passe hors ligne et à connaissance nulle. Le contenu du coffre est chiffré sur l'appareil avec des clés dérivées du mot de passe principal et n'est jamais transmis. Il n'y a ni compte, ni service de synchronisation, ni télémétrie, ni analyse. Les binaires Windows ne contiennent aucun client réseau, hormis les composants du système d'exploitation lui-même. Texte complet : Politique de confidentialité. Le comportement des composants tiers qui affecte les utilisateurs est couvert par LICENSE-3RD-PARTY.md.

5. Autres plateformes

macOS — les artefacts sont signés avec un Apple Developer ID et notariés par Apple. Le certificat n'a pas encore été délivré, aucun artefact macOS n'est donc signé et aucun n'est publié. Linux — .deb, .rpm et .AppImage sont publiés avec des signatures GPG détachées (.sig) ; SBOM et paquets d'extensions de navigateur avec des signatures Sigstore sans clé (.sigstore.json). Android — les APK de version sont signés avec un keystore de release conservé dans les secrets GitHub Actions ; la signature Android est distincte d'Authenticode. Aucune plateforme n'est décrite comme signée tant qu'elle ne l'est pas.

État actuel : Linux, Android et l'extension de navigateur sont publiés et signés. Windows n'est publié que comme aperçu non signé : une préversion, pas une version stable, et latest ne pointe pas dessus. Les fichiers non signés déclenchent l'avertissement SmartScreen « Votre PC est protégé », et vous devez cliquer sur « Informations » → « Exécuter quand même » pour lancer l'installeur ; c'est attendu. Vérifiez la somme SHA-256 dans SHA256SUMS.txt avant de l'exécuter. La candidature auprès de la SignPath Foundation n'a pas encore été déposée. macOS n'est ni publié ni signé (certificat pas encore délivré).

Les artefacts Windows ne sont pas publiés comme une version : la chaîne de publication traite une version de bureau non signée comme un échec, et aucun workflow de .github/workflows/ n'est en mesure d'en publier une. L'aperçu est assemblé et téléversé à la main, depuis la machine de la personne qui maintient le projet via le formulaire de version de GitHub, et marqué comme préversion : il est donc visiblement provisoire, latest ne pointe jamais dessus, et la prochaine version signée le remplace. Ce chemin est délibéré et non un contournement. Le dépôt contient un contrôle de sécurité (npm run security:release-signing) qui rejette tout workflow capable de transformer une build non signée en publication ; son affirmation finale est qu'en l'absence des secrets de signature, une version de bureau publique est impossible par conception. Ajouter une exception pour un workflow aurait rendu cette affirmation fausse au prix d'une commodité. Garder le téléversement dans un navigateur préserve la garantie. Le contrôle est documenté dans le Guide de signature du code et des artefacts ; la procédure détaillée figure dans le Plan : le site, puis l'aperçu Windows non signé.

6. Signaler un problème

Si vous pensez qu'un artefact signé avec un certificat SignPath Foundation enfreint cette politique, signalez-le à support@signpath.io avec le hash de l'artefact et le motif. Pour tout autre sujet concernant ces artefacts, utilisez security@kalderashield.com ; le processus de divulgation se trouve dans SECURITY.md.

En cas de divergence, le texte turc de cette politique fait foi.