🔐 Implémentation d’une stratégie de signature GPG + vérification supply-chain multi-plateforme

[Akmot9]

Labels: security, ci/cd, release, backlog

---

🎯 Objectif

Mettre en place une stratégie de signature cryptographique des artifacts de release (Windows / Linux / macOS) afin de :

• Garantir l’intégrité des binaires publiés
• Permettre la vérification indépendante par les utilisateurs
• Réduire le risque supply-chain (compromission CI / altération des assets GitHub)
• Standardiser la procédure de release sécurisée

Build réalisé sur GitLab local → publication sur GitHub Releases.

---

📦 Périmètre

Artifacts concernés (Tauri) :

• NSIS (.exe)
• DEB (.deb)
• RPM (.rpm)
• DMG (.dmg)

---

🧱 Architecture cible

1️⃣ Build sécurisé

• Compilation sur GitLab local (runner contrôlé)
• Build taggé (ex: app-v3.10.8)

2️⃣ Génération des checksums

sha256sum * > SHA256SUMS

3️⃣ Signature GPG détachée

gpg --armor --detach-sign SHA256SUMS

Artifacts publiés :

• binaires
• SHA256SUMS
• SHA256SUMS.asc

---

🔎 Vérification côté utilisateur

gpg --verify SHA256SUMS.asc SHA256SUMS
sha256sum -c SHA256SUMS

---

🔐 Sécurité clé GPG

À définir :

• Génération d’une clé dédiée “Sonar Release Signing”
• Publication de la clé publique dans le repository
• Stockage sécurisé de la clé privée (runner GitLab / machine offline / smartcard ?)
• Protection variable CI (masked + protected)

---

📑 Améliorations futures (optionnel)

• Signature des tags Git (git tag -s)
• Génération SBOM (CycloneDX)
• Signature SBOM
• Fichier provenance.json signé
• Étude Sigstore / cosign

---

📋 Tâches

• Générer clé GPG dédiée
• Ajouter étape signature dans pipeline GitLab
• Ajouter publication automatique vers GitHub Releases
• Documenter procédure de vérification dans README
• Documenter procédure de rotation de clé

---

💡 Motivation

SONAR est open-source et distribué publiquement.
L’objectif est d’apporter une garantie cryptographique forte sur les releases, indépendamment de la confiance dans GitHub.