GitSign : signer vos commits Git avec Sigstore

Vous contribuez à un projet open source. Un jour, quelqu’un pousse un commit malveillant en utilisant votre adresse email dans git config. Sans signature, impossible de prouver que ce n’était pas vous.

GitSign résout ce problème avec la signature keyless : vous signez vos commits avec votre identité (compte GitHub, Google, Microsoft) au lieu d’une clé GPG à gérer. Le tout est enregistré dans un log de transparence public pour garantir l’auditabilité.

L'analogie

Signer un commit avec GPG, c’est comme utiliser un tampon personnel que vous devez protéger et renouveler. Signer avec GitSign, c’est comme présenter votre carte d’identité à un notaire qui enregistre l’acte dans un registre public.

Qu’est-ce que GitSign ?

GitSign est un outil développé par le projet Sigstore qui permet de signer vos commits Git sans gérer de clés cryptographiques.

Comment ça fonctionne :

1. Vous faites un commit
2. GitSign ouvre un navigateur pour vous authentifier (GitHub, Google, etc.)
3. Fulcio délivre un certificat éphémère (valable 10 minutes)
4. Votre commit est signé avec ce certificat
5. La signature est enregistrée dans Rekor, le log de transparence public

Le certificat expire rapidement, mais la signature reste vérifiable grâce à Rekor qui prouve qu’elle a été créée pendant la période de validité.

Pour comprendre en détail le fonctionnement de la signature keyless, consultez le guide Sigstore.

Pourquoi signer ses commits ?

La signature de commits répond à un problème fondamental : Git ne vérifie pas l’identité de l’auteur. N’importe qui peut configurer git config user.email avec votre adresse et pousser des commits en votre nom.

Sans signature	Avec signature
N’importe qui peut usurper votre email	Identité vérifiée cryptographiquement
Compromission de compte → commits frauduleux	Signature invalide sans votre authentification
Aucune preuve d’intégrité	Modification du commit = signature cassée
Historique falsifiable	Chaîne de confiance auditable

Quand c'est indispensable

La signature de commits devient critique pour :

• Mainteneurs open source : prouvez que c’est bien vous qui avez approuvé une PR
• Projets sensibles : code d’infrastructure, gestion de secrets, applications financières
• Conformité : SOC 2, ISO 27001 exigent souvent la traçabilité des modifications
• Supply chain security : contribue aux niveaux SLSA

Prérequis

Avant de commencer, assurez-vous d’avoir :

• Git 2.34+ (pour le support du format de signature x509)
• Un compte OIDC : GitHub, Google, ou Microsoft
• Connexion Internet (nécessaire pour l’authentification et Rekor)

Pour vérifier votre version de Git :

git --version
# Doit afficher 2.34 ou supérieur

Environnements air-gapped

GitSign nécessite une connexion à Fulcio (certificats) et Rekor (log de transparence). Pour les environnements sans accès Internet, utilisez plutôt GPG ou SSH.

GitSign vs GPG vs SSH

Trois méthodes existent pour signer vos commits. Voici comment choisir :

Critère	GPG	SSH (Git 2.34+)	GitSign
Gestion de clés	Clé longue durée à protéger	Clé SSH existante	Aucune (OIDC)
Rotation	Manuelle, complexe	Manuelle	Automatique (certificat éphémère)
Vérification	Web of trust ou clé uploadée	Clé uploadée sur forge	Log de transparence Rekor
Badge “Verified”	✅ GitHub/GitLab natif	✅ GitHub/GitLab natif	❌ Vérification CI requise
Air-gapped	✅ Compatible	✅ Compatible	❌ Internet requis
Auditabilité	Limitée	Limitée	Totale (Rekor public)

Quand choisir GitSign

Choisissez GitSign si :

• Vous ne voulez pas gérer de clés
• L’auditabilité est importante (log public)
• Vous travaillez sur des projets open source avec Sigstore

Gardez GPG/SSH si :

• Vous avez besoin du badge “Verified” natif sur GitHub/GitLab
• Vous travaillez dans un environnement sans Internet

Installation

macOS

# Avec Homebrew
brew install sigstore/tap/GitSign

# Vérifier l'installation
GitSign version

Linux (Debian/Ubuntu)

# Télécharger la dernière version
GitSign_VERSION=$(curl -s https://api.github.com/repos/sigstore/GitSign/releases/latest | grep tag_name | cut -d '"' -f 4)
curl -LO "https://github.com/sigstore/GitSign/releases/download/${GitSign_VERSION}/GitSign_${GitSign_VERSION#v}_linux_amd64"

# Installer
chmod +x GitSign_*_linux_amd64
sudo mv GitSign_*_linux_amd64 /usr/local/bin/GitSign

# Vérifier l'installation
GitSign version

Vérification attendue : La commande affiche la version installée (ex: GitSign version v0.10.2).

Linux (Arch)

# Depuis les dépôts communautaires
pacman -S GitSign

# Vérifier l'installation
GitSign version

Windows

# Avec Scoop
scoop bucket add sigstore https://github.com/sigstore/scoop-bucket
scoop install GitSign

# Vérifier l'installation
GitSign version

Configuration

Vous pouvez configurer GitSign globalement (tous vos projets) ou par projet.

Configuration globale (recommandée pour démarrer)

Ces commandes configurent Git pour utiliser GitSign sur tous vos dépôts :

# Activer la signature automatique des commits
git config --global commit.gpgsign true

# Indiquer à Git d'utiliser le format x509 (requis pour GitSign)
git config --global gpg.format x509

# Spécifier GitSign comme programme de signature
git config --global gpg.x509.program GitSign

Pourquoi ces trois lignes ?

• commit.gpgsign true : Git signera automatiquement chaque commit
• gpg.format x509 : utilise des certificats X.509 au lieu de GPG
• gpg.x509.program GitSign : délègue la signature à GitSign

Configuration par projet

Si vous ne voulez utiliser GitSign que sur certains projets :

# Dans le répertoire du projet
cd mon-projet

git config --local commit.gpgsign true
git config --local gpg.format x509
git config --local gpg.x509.program GitSign

Vérifier la configuration

git config --list | grep -E "(commit.gpgsign|gpg.format|gpg.x509)"

Sortie attendue :

commit.gpgsign=true
gpg.format=x509
gpg.x509.program=GitSign

Premier commit signé

C’est le moment de tester ! Voici ce qui va se passer lors de votre premier commit signé.

1. Créer ou modifier un fichier

   echo "# Mon projet" > README.md
   git add README.md

2. Faire un commit

   git commit -m "feat: initialisation du projet"

   Comme commit.gpgsign est activé, Git appelle automatiquement GitSign.

3. S’authentifier via OIDC

   Un navigateur s’ouvre avec une page Sigstore. Choisissez votre provider (GitHub, Google, Microsoft) et connectez-vous.

   Ce qui se passe en coulisses

   • GitSign envoie une demande à Fulcio (l’autorité de certification)
   • Fulcio vérifie votre identité OIDC
   • Fulcio délivre un certificat éphémère (valable ~10 minutes)
   • GitSign signe le commit avec ce certificat
   • La signature est enregistrée dans Rekor (log de transparence)

4. Vérifier la signature

   git log --show-signature -1

   Sortie attendue :

   commit abc123... (HEAD -> main)
   tlog index: 12345678
   GitSign: Signature made using certificate ID 0xabc...
   GitSign: Good signature from "votre-email@example.com"

Erreur 'could not find a connector'

Si vous voyez cette erreur, votre navigateur n’a pas pu s’ouvrir. Vérifiez que xdg-open (Linux) ou open (macOS) fonctionne, ou utilisez le mode non-interactif (voir section CI/CD).

Vérification des signatures

Vérifier en ligne de commande

# Vérifier le dernier commit
GitSign verify HEAD

# Vérifier une plage de commits
GitSign verify HEAD~5..HEAD

# Vérifier avec plus de détails
GitSign verify --verbose HEAD

Sortie d’une vérification réussie :

tlog index: 12345678
GitSign: Signature verified OK
GitSign: Certificate subject: votre-email@example.com
GitSign: Certificate issuer: https://github.com/login/oauth

Vérifier l’entrée dans Rekor

Chaque signature est enregistrée dans le log de transparence public. Pour retrouver une entrée :

# Rechercher par email
rekor-cli search --email votre@email.com

# Voir les détails d'une entrée
rekor-cli get --uuid <entry-uuid>

Vous pouvez aussi explorer Rekor via l’interface web : search.sigstore.dev ↗

Intégration GitHub

GitHub ne reconnaît pas encore nativement les signatures GitSign. Vos commits n’auront pas le badge “Verified” automatiquement.

Pourquoi GitHub affiche « Unverified » ?

GitHub valide uniquement trois types de signatures :

1. GPG (signatures OpenPGP classiques)
2. SSH (signatures avec clés SSH)
3. S/MIME (signatures X.509 avec certificats corporatifs)

GitSign utilise une approche keyless avec Sigstore :

• Authentification OIDC (GitHub, Google, Microsoft…)
• Certificat éphémère délivré par Fulcio (validité ~10 minutes)
• Signature enregistrée dans Rekor (log de transparence public)

Pourquoi ça ne fonctionne pas ?

Le certificat racine (root CA) de Fulcio n’est pas dans le trust store de GitHub (qui utilise les CA standards comme Debian ca-certificates ou la liste Mozilla).

Solutions pragmatiques :

1. Badge uniquement : utiliser SSH ou GPG pour les commits (badge GitHub) et GitSign pour les releases/tags
2. Vérification CI : garder GitSign partout + job CI qui vérifie les signatures + badge personnalisé
3. Attestations GitHub : utiliser gh attestation ↗ pour lier commits et artefacts signés

Solutions :

1. Vérification CI : ajoutez un job qui vérifie les signatures (voir section GitHub Actions)
2. Documentation : indiquez dans votre README que les commits sont vérifiables via GitSign verify

Intégration GitLab

Même situation que GitHub. Créez un job CI pour la vérification :

.gitlab-ci.yml

verify-signatures:
  image: ghcr.io/sigstore/GitSign:latest
  script:
    - GitSign verify $CI_COMMIT_SHA
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"

Configuration avancée

Choisir le provider OIDC

Par défaut, GitSign propose tous les providers. Pour forcer un provider spécifique :

# Utiliser GitHub uniquement
export GitSign_CONNECTOR_ID=https://github.com/login/oauth

# Utiliser Google uniquement
export GitSign_CONNECTOR_ID=https://accounts.google.com

# Utiliser Microsoft (Azure AD)
export GitSign_CONNECTOR_ID=https://login.microsoftonline.com

Pour rendre permanent, ajoutez à votre ~/.bashrc ou ~/.zshrc.

Signer des tags

GitSign fonctionne aussi pour les tags annotés :

# Créer un tag signé
git tag -s v1.0.0 -m "Release 1.0.0"

# Vérifier le tag
GitSign verify v1.0.0

Mode non-interactif (CI/CD)

Dans un pipeline CI, il n’y a pas de navigateur pour l’authentification OIDC. Utilisez un token OIDC fourni par la plateforme.

GitHub Actions :

name: Signed Commits

on: [push]

jobs:
  verify:
    runs-on: ubuntu-24.04
    permissions:
      id-token: write  # Nécessaire pour obtenir un token OIDC
      contents: read
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # Historique complet pour vérification

      - name: Install GitSign
        run: |
          GitSign_VERSION=$(curl -s https://api.github.com/repos/sigstore/GitSign/releases/latest | grep tag_name | cut -d '"' -f 4)
          curl -LO "https://github.com/sigstore/GitSign/releases/download/${GitSign_VERSION}/GitSign_${GitSign_VERSION#v}_linux_amd64"
          chmod +x GitSign_*_linux_amd64
          sudo mv GitSign_*_linux_amd64 /usr/local/bin/GitSign

      - name: Verify commit signatures
        run: GitSign verify HEAD

GitLab CI avec OIDC :

verify-signatures:
  image: ubuntu:latest
  id_tokens:
    SIGSTORE_ID_TOKEN:
      aud: sigstore
  script:
    - |
      GitSign_VERSION=$(curl -s https://api.github.com/repos/sigstore/GitSign/releases/latest | grep tag_name | cut -d '"' -f 4)
      curl -LO "https://github.com/sigstore/GitSign/releases/download/${GitSign_VERSION}/GitSign_${GitSign_VERSION#v}_linux_amd64"
      chmod +x GitSign_*_linux_amd64 && mv GitSign_*_linux_amd64 /usr/local/bin/GitSign
    - GitSign verify $CI_COMMIT_SHA

Sécurité et vie privée

Ce qui est public

Vie privée

Votre adresse email (issue du provider OIDC) est enregistrée dans Rekor, un log public et immuable. Toute personne peut rechercher vos signatures.

Si l’anonymat est important pour votre projet, utilisez GPG avec une clé pseudonyme.

Ce qui est protégé

• Votre clé privée n’existe pas : le certificat est éphémère
• Vos credentials OIDC ne sont jamais stockés par GitSign
• La signature prouve l’authenticité au moment de la création

Bonnes pratiques

Pratique	Pourquoi
Utilisez un compte dédié au code	Sépare identité pro/perso
Activez 2FA sur le provider OIDC	Protège contre le vol de compte
Vérifiez les signatures en CI	Détecte les commits non signés
Documentez votre politique	Les contributeurs savent quoi faire

Dépannage

Problèmes courants

Symptôme	Cause probable	Solution
Navigateur ne s’ouvre pas	xdg-open manquant ou WSL	Installer xdg-utils ou configurer BROWSER
error: gpg failed to sign	Format x509 non configuré	Vérifier git config gpg.format
certificate has expired	Commit après expiration du cert	Refaire le commit (certificat = 10 min)
could not find tlog entry	Problème réseau avec Rekor	Vérifier connexion Internet
unsupported signature type	Git < 2.34	Mettre à jour Git

Logs de débogage

Pour voir ce que fait GitSign en détail :

export GitSign_LOG=debug
git commit -m "test"

Réinitialiser la configuration

Si vous voulez revenir à GPG ou désactiver la signature :

# Désactiver la signature automatique
git config --global --unset commit.gpgsign

# Revenir au format GPG
git config --global gpg.format openpgp
git config --global --unset gpg.x509.program

Limites connues

Limitation	Détail	Alternative
Internet requis	Fulcio + Rekor nécessaires	GPG/SSH pour air-gapped
Pas de badge GitHub	Vérification manuelle	Job CI + badge personnalisé
Email public	Visible dans Rekor	GPG avec pseudonyme
Certificat court	10 minutes de validité	Pas de problème si commit immédiat

À retenir

1. GitSign = signature keyless : votre identité OIDC remplace les clés GPG
2. Certificat éphémère : valide ~10 minutes, mais signature vérifiable indéfiniment grâce à Rekor
3. Transparence totale : toutes les signatures sont dans un log public
4. Vérification CI : pas de badge GitHub natif, mais vérifiable par GitSign verify
5. Email public : attention si anonymat requis

Liens utiles

Sigstore Vue d'ensemble de l'écosystème

Fulcio L'autorité de certification qui délivre les certificats

Rekor Le log de transparence où sont enregistrées les signatures

Cosign Signature keyless pour images conteneur

Ressources externes

• GitSign sur GitHub ↗ — Code source et documentation officielle
• Documentation Sigstore ↗ — Guide complet de l’écosystème
• Rekor Search ↗ — Explorer le log de transparence public
• Sigstore blog ↗ — Annonces et cas d’usage