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é.

Ce que vous allez apprendre

Comprendre la signature keyless : certificat éphémère Fulcio, preuve Rekor
Installer Gitsign avec vérification de la somme de contrôle publiée
Configurer Git pour signer avec le format x509 au lieu d'OpenPGP
Vérifier une signature avec l'identité et l'émetteur OIDC attendus
Arbitrer entre Gitsign, GPG et SSH selon votre contexte (badge, air-gap, audit)

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 :

Vous faites un commit
Gitsign ouvre un navigateur pour vous authentifier (GitHub, Google, etc.)
Fulcio délivre un certificat éphémère (valable 10 minutes)
Votre commit est signé avec ce certificat
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

Prérequis

Avant de commencer, assurez-vous d'avoir :

Git 2.19+ : c'est la version qui a introduit gpg.format = x509 et gpg.x509.program, les deux réglages sur lesquels Gitsign se branche
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.19 ou supérieur

Toutes les distributions maintenues livrent aujourd'hui une version très supérieure à ce plancher, la vérification sert surtout sur un serveur ancien ou une image de build figée.

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"	Oui, GitHub/GitLab natif	Oui, GitHub/GitLab natif	Non, vérification CI requise
Air-gapped	Compatible	Compatible	Internet requis
Auditabilité	Limitée	Limitée	Totale (Rekor public)

La colonne SSH porte la mention « Git 2.34+ » parce que c'est la version qui a ajouté la valeur ssh à gpg.format. Le format x509 utilisé par Gitsign est disponible depuis Git 2.19, les deux plancher de version ne se confondent pas.

Installation

Gitsign est distribué en binaire statique, en paquet .deb/.rpm/.apk, et dans plusieurs gestionnaires de paquets. Sur Linux, préférez le paquet ou le binaire accompagné de sa vérification de somme de contrôle : le projet publie un fichier checksums.txt à chaque release, c'est lui qui prouve que l'archive téléchargée est bien celle publiée par les mainteneurs.

# Avec Homebrew (formule officielle, dans homebrew-core)
brew install gitsign

# Vérifier l'installation
gitsign version

Le paquet .deb et le fichier de sommes sont publiés côte à côte sur la page de release. On télécharge les deux, on contrôle, puis seulement on installe.

GITSIGN_VERSION=0.16.1
BASE="https://github.com/sigstore/gitsign/releases/download/v${GITSIGN_VERSION}"

curl -sSLO "${BASE}/gitsign_${GITSIGN_VERSION}_linux_amd64.deb"
curl -sSLO "${BASE}/checksums.txt"

# Refuse d'aller plus loin si l'empreinte ne correspond pas
grep " gitsign_${GITSIGN_VERSION}_linux_amd64.deb$" checksums.txt | sha256sum --check

sudo apt install "./gitsign_${GITSIGN_VERSION}_linux_amd64.deb"

# Vérifier l'installation
gitsign version

Vérification attendue : sha256sum --check affiche gitsign_0.16.1_linux_amd64.deb: OK, puis gitsign version affiche gitsign version v0.16.1 suivi de la configuration effective (URL de Fulcio, de Rekor, mode Rekor).

Sur une distribution sans apt, remplacez le .deb par le binaire statique gitsign_${GITSIGN_VERSION}_linux_amd64 : le contrôle est identique, il reste à faire chmod +x puis à le déplacer dans /usr/local/bin/gitsign.

# Paquet du dépôt extra
sudo pacman -S gitsign

# Vérifier l'installation
gitsign version

Le dépôt Arch suit la version amont avec un léger décalage : contrôlez la version obtenue si vous avez besoin d'une fonctionnalité récente.

# Le paquet est dans le bucket "main" de Scoop, aucun bucket à ajouter
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é.

Créer ou modifier un fichier

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

Faire un commit
Fenêtre de terminal
```
git commit -m "feat: initialisation du projet"
```
Comme commit.gpgsign est activé, Git appelle automatiquement Gitsign.
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)

Vérifier la signature

git log --show-signature -1

Sortie attendue :

tlog index: 16072348
gitsign: Signature made using certificate ID 0xa6c178d9292f70eb5c4ad9e274ead0158e75e484 | CN=sigstore-intermediate,O=sigstore.dev
gitsign: Good signature from [vous@example.org](https://accounts.google.com)
Validated Git signature: true
Validated Rekor entry: true
Validated Certificate claims: false
commit abc123... (HEAD -> main)

La dernière ligne de validation est à false volontairement : git log ne transmet aucune identité attendue au programme de signature, il ne peut donc pas contrôler qui a signé. C'est le rôle de gitsign verify.

Vérification des signatures

Vérifier en ligne de commande

Une signature Gitsign valide prouve deux choses distinctes : que le commit n'a pas été modifié, et que l'identité inscrite dans le certificat est bien celle que vous attendiez. Le second contrôle n'a lieu que si vous passez l'identité et l'émetteur OIDC attendus, sinon gitsign valide la cryptographie sans vérifier au nom de qui elle a été produite.

# Vérifier le dernier commit en exigeant une identité et un émetteur précis
gitsign verify \
  --certificate-identity=vous@example.org \
  --certificate-oidc-issuer=https://accounts.google.com \
  HEAD

# Une expression régulière quand plusieurs identités sont acceptables
gitsign verify \
  --certificate-identity-regexp='.*@example\.org$' \
  --certificate-oidc-issuer=https://accounts.google.com \
  HEAD

Sortie d'une vérification réussie :

tlog index: 16072348
gitsign: Signature made using certificate ID 0xa6c178d9292f70eb5c4ad9e274ead0158e75e484 | CN=sigstore-intermediate,O=sigstore.dev
gitsign: Good signature from [vous@example.org](https://accounts.google.com)
Validated Git signature: true
Validated Rekor entry: true
Validated Certificate claims: true

gitsign verify HEAD~5..HEAD échoue avec error resolving commit object: Revision invalid. La commande accepte un identifiant de révision Git (HEAD, un SHA, une branche, un tag). Pour couvrir plusieurs commits, bouclez :

for c in $(git rev-list HEAD~5..HEAD); do
  gitsign verify \
    --certificate-identity=vous@example.org \
    --certificate-oidc-issuer=https://accounts.google.com \
    "$c"
done

Vérifier l'entrée dans Rekor

Chaque signature est enregistrée dans le log de transparence public. Cette étape sert quand la vérification locale échoue et que vous cherchez à savoir si l'entrée existe réellement côté log, ou quand vous auditez a posteriori ce qu'un compte a signé.

# Rechercher par email
rekor-cli search --email vous@example.org

# 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 nativement les signatures Gitsign. Vos commits n'auront pas le badge "Verified" automatiquement.

GitHub valide uniquement trois types de signatures :

GPG (signatures OpenPGP classiques)
SSH (signatures avec clés SSH)
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 ?

Deux obstacles se cumulent. Le certificat racine (root CA) de Fulcio n'est pas dans le trust store de GitHub (qui s'appuie sur les CA standards de la liste Mozilla). Et surtout, le certificat étant expiré au bout de dix minutes, une validation X.509 classique le rejetterait : il faut interroger Rekor pour établir qu'il était valide au moment de la signature. Le sujet est suivi publiquement dans l'issue sigstore/gitsign#40.

Solutions pragmatiques :

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

Solutions :

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

Intégration GitLab

Même situation que GitHub : le badge natif ne couvre pas Sigstore. Un job CI prend le relais et fait échouer le pipeline si la signature ne correspond pas à l'identité attendue. L'image officielle est épinglée par digest pour que le job exécute demain exactement le même binaire qu'aujourd'hui.

verify-signatures:
  image: ghcr.io/sigstore/gitsign@sha256:052e78ddafc32fe9da4de01e06ff1e41efb1e94c852a10da14f00e5686a5ea5b  # v0.16.1
  script:
    - gitsign verify
        --certificate-identity=vous@example.org
        --certificate-oidc-issuer=https://accounts.google.com
        "$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. Chaque variable GITSIGN_* a un équivalent SIGSTORE_* ; quand les deux sont définies, c'est le préfixe GITSIGN_ qui l'emporte.

Signer des tags

Gitsign fonctionne aussi pour les tags annotés. Attention, la vérification passe par une sous-commande dédiée : gitsign verify ne sait lire que des objets commit.

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

# Vérifier le tag
gitsign verify-tag \
  --certificate-identity=vous@example.org \
  --certificate-oidc-issuer=https://accounts.google.com \
  v1.0.0

Mode non-interactif (CI/CD)

Dans un pipeline CI, il n'y a pas de navigateur pour l'authentification OIDC. Le runner obtient un token OIDC de la plateforme, et Gitsign le consomme via GITSIGN_TOKEN_PROVIDER=github-actions. Pour la vérification seule, comme dans l'exemple ci-dessous, aucun token n'est nécessaire : on lit une signature existante.

GitHub Actions :

name: Signed Commits

on: [push]

# Aucun droit par défaut, chaque job demande le strict nécessaire
permissions: {}

jobs:
  verify:
    runs-on: ubuntu-24.04
    timeout-minutes: 10
    permissions:
      contents: read
    steps:
      - name: Checkout
        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
        with:
          fetch-depth: 0            # Historique complet pour la vérification
          persist-credentials: false

      - name: Install gitsign
        env:
          GITSIGN_VERSION: "0.16.1"
        run: |
          set -euo pipefail
          base="https://github.com/sigstore/gitsign/releases/download/v${GITSIGN_VERSION}"
          curl -sSLO "${base}/gitsign_${GITSIGN_VERSION}_linux_amd64"
          curl -sSLO "${base}/checksums.txt"
          grep " gitsign_${GITSIGN_VERSION}_linux_amd64$" checksums.txt | sha256sum --check
          chmod +x "gitsign_${GITSIGN_VERSION}_linux_amd64"
          sudo mv "gitsign_${GITSIGN_VERSION}_linux_amd64" /usr/local/bin/gitsign

      - name: Verify commit signature
        run: |
          gitsign verify \
            --certificate-identity-regexp='.*@example\.org$' \
            --certificate-oidc-issuer=https://accounts.google.com \
            HEAD

GitLab CI avec OIDC : l'image officielle embarque déjà le binaire, il n'y a donc rien à télécharger. Le bloc id_tokens sert dès que le job signe des objets ; pour une simple vérification il peut être retiré.

verify-signatures:
  image: ghcr.io/sigstore/gitsign@sha256:052e78ddafc32fe9da4de01e06ff1e41efb1e94c852a10da14f00e5686a5ea5b  # v0.16.1
  id_tokens:
    SIGSTORE_ID_TOKEN:
      aud: sigstore
  script:
    - gitsign verify
        --certificate-identity=vous@example.org
        --certificate-oidc-issuer=https://accounts.google.com
        "$CI_COMMIT_SHA"

Sécurité et vie privée

Ce qui est public

Ce qui est protégé

Le modèle keyless déplace le risque plutôt qu'il ne le supprime : il n'y a plus de clé privée longue durée à voler sur votre poste, mais votre compte OIDC devient la cible. Trois garanties tiennent, à condition que ce compte reste sous votre contrôle.

Votre clé privée n'existe pas durablement : 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, grâce à l'horodatage inscrit dans Rekor

Bonnes pratiques

Ces quatre réflexes traitent le point faible réel du modèle : quiconque prend la main sur votre compte OIDC peut signer à votre place, et le log de transparence enregistrera cette signature comme légitime. Les deux premières lignes réduisent cette surface, les deux dernières permettent de détecter une dérive.

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

La quasi-totalité des échecs relèvent de trois familles : le navigateur qui ne s'ouvre pas, la configuration Git incomplète, ou le réseau qui coupe l'accès à Fulcio et Rekor. Repérez d'abord à quelle famille appartient votre message d'erreur, la colonne « Cause probable » vous y aide.

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.19, ou commit signé avec OpenPGP	Mettre à jour Git, ou vérifier avec `gpg`
`Revision invalid`	Une plage (`A..B`) passée à `gitsign verify`	Passer une seule révision, boucler sur `git rev-list`

Logs de débogage

Git capture la sortie standard et la sortie d'erreur des programmes de signature : quand quelque chose échoue, vous ne voyez souvent rien d'utile. GITSIGN_LOG contourne ce masquage en écrivant l'état dans un fichier.

export GITSIGN_LOG=/tmp/gitsign.log
git commit -m "test"
cat /tmp/gitsign.log

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

Aucune de ces limites n'est un défaut d'implémentation : elles découlent toutes du choix keyless lui-même. Les connaître avant de standardiser Gitsign sur une équipe évite la mauvaise surprise du premier audit ou du premier déplacement hors ligne.

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

Gitsign = signature keyless : votre identité OIDC remplace les clés GPG
Certificat éphémère : valide ~10 minutes, mais signature vérifiable indéfiniment grâce à Rekor
Transparence totale : toutes les signatures sont dans un log public
Vérification utile = identité exigée : sans --certificate-identity (ou sa variante -regexp) et --certificate-oidc-issuer, vous validez la cryptographie sans contrôler qui a signé
Email public : attention si anonymat requis
Preuve attendue : un job CI qui exécute gitsign verify avec l'identité et l'émetteur attendus, et dont l'échec bloque la merge request

Prochaines étapes

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