[gull] Sigstore
Frederic Dumas
f.dumas at ellis.siteparc.fr
Sat Jan 10 21:21:48 CET 2026
Bonsoir à tous,
sigstore.dev permet de signer très facilement un fichier, par exemple un bout de code source, pour garantir au destinataire qu'il n'a pas été altéré. L'avez-vous déjà utilisé ?
> sigstore sign *.ipynb
Et hop, un petit fichier *.sigstore.json est créé, en compagnon et pour chaque fichier signé. L'authentification de l'auteur se fait par un opérateur OpenID Connect (à ce jour, le choix est donné entre Github, Google et Microsoft), auprès duquel il faut donc au préalable avoir un compte. Concrètement, la commande 'sigstore sign' saisie dans le terminal va provoquer l'ouverture d'une fenêtre dans le navigateur web par défaut de la machine. On est ensuite redirigé vers l'opérateur OpenID Connect choisi, auprès duquel il faut se connecter alors avec les moyens habituels (mots de passe, OTP, U2F ou keypass, chacun fait comme il veut).
Mais contrairement à une PKI classique (X.509 ou GPG), ce n'est pas vraiment la signature qui est stockée dans le fichier sigstore.json, plutôt des meta-données qui permettent plus tard d'interroger le registre "rekor" de sigstore, qui lui saura confirmer que la signature est authentique. Si on veut donc permettre à quelqu'un de vérifier l'intégrité du fichier signé, il faudra donc bien joindre le fichier sigstore.json l'accompagnant.
Mais il y a un choix ergonomique pas très compréhensible à première vue. Quand on veut vérifier l'authenticité d'un fichier en interrogeant rekor sur sa signature, il semble obligatoire alors de spécifier manuellement dans la commande:
(1) l'auteur de la signature, et
(20 l'opérateur OpenID Connect auprès duquel il s'est authentifié:
> % sigstore verify identity --cert-identity "f.dumas at ellis.siteparc.fr" --cert-oidc-issuer "https://github.com/login/oauth" *.ipynb
> OK: notebook_1.2.1.ipynb
> OK: notebook_1.2.2.ipynb
> OK: notebook_1.2.3.ipynb
Cette longue commande est tout sauf facilement mémorisable. Et non, un simple sigstore verify *.ipynb ne marche pas. Surtout, si on ne sait pas qui est l'auteur du fichier compagnon .sigstore.json (et attention aux coquilles dans son identifiant !), on est juste incapable de fournir à la commande les bons arguments --cert-identity et --cert-oidc-issuer. Autant dire que c'est peu utilisable en usage manuel ponctuel. C'est un peu décevant.
Gemini répond qu'il n'est pas possible de vérifier une signature sigstore "keyless" autrement, et prétend que sigstore n'est pas vraiment destiné à l'utilisateur final, mais plutôt au worklow d'un serveur CI/CD, pour certifier alors que le code mis à jour est authentique. Pourquoi pas, mais qui peut le plus devrait pouvoir le moins aussi. J'ai un peu bataillé avec Gemini pour comprendre le pourquoi du comment, sans parvenir à le faire changer d'avis, mais sans non plus que m'aient convaincu les raisons théoriques qu'il invoque pour justifier l'obligation d'une déclaration explicite de l'auteur à chaque vérification de signature.
Est-ce que certains du Gull ont eu à utiliser sigstore, et pourraient confirmer ou infirmer ce que j'ai cru comprendre des contraintes de la méthode ? Suis-je passé à coté de quelque chose ?
--
Frédéric Dumas
f.dumas at ellis.siteparc.fr
More information about the gull
mailing list