sigstore/root-signingMaintient le dépôt TUF qui fournit de manière sécurisée la racine de confiance Sigstore (trusted_root.json) aux clients, en utilisant la signature par seuil des détenteurs de clés, la signature en ligne via KMS et la publication automatisée.
Le projet root-signing maintient le dépôt TUF utilisé pour livrer de manière sécurisée la racine de confiance Sigstore (trusted_root.json) aux clients Sigstore.
Le dépôt est publié pour la consommation des clients sigstore à l'adresse https://tuf-repo-cdn.sigstore.dev/.
Les sources de métadonnées se trouvent dans le dossier metadata/, les artefacts (comme trusted_root.json) dans le dossier targets/. Voir Fonctionnement pour plus de détails sur la façon de modifier ces sources.
La sécurité de root-signing repose sur les détenteurs de clés : ils doivent être des membres de la communauté de confiance disposés et capables d'accomplir les tâches de détenteur de clé comme vérifier le nouveau contenu de trusted_root.json et signer lors des événements de signature.
Toutes les modifications apportées aux artefacts ou aux métadonnées nécessitent des signatures cryptographiques de la part des détenteurs de clés Sigstore. Les détenteurs de clés actuels, les exigences de signature et le calendrier de signature sont documentés dans le dépôt publié
| Détenteurs de clés | Mandat |
|---|---|
| Lance Ball | Juillet 2025 - |
| Joshua Lock | Juillet 2022 - |
| Bob Callaway | Juin 2021 - |
| Marina Moore | Juin 2021 - |
| Santiago Torres-Arias | Juin 2021 - |
| Détenteurs de clés émérites | Mandat |
|---|---|
| Luke Hinds | Juin 2021 - Juillet 2022 |
| Dan Lorenc | Juin 2021 - Juillet 2025 |
Le dépôt TUF est modifié de deux manières :
Les événements de signature sont des pull requests créées et gérées par root-signing où les détenteurs de clés signent les modifications proposées. Les événements de signature se produisent pour plusieurs raisons :
Dans tous les cas, le déclencheur de la création d'une PR d'événement de signature est un push vers une branche "sign/*" (soit par un mainteneur, soit par un workflow).
Il existe un dépôt distinct root-signing-staging : toute modification non triviale (des métadonnées ou des artefacts) doit être testée dans root-signing-staging avant d'être introduite dans un événement de signature root-signing.
La signature en ligne se produit dans deux situations :
En pratique, la signature en ligne se produit au moins tous les trois jours en raison de l'expiration des signatures en ligne.
La signature en ligne conduit à un déploiement de "préproduction" à l'adresse https://sigstore.github.io/root-signing/. Il s'agit d'un dépôt TUF entièrement fonctionnel utilisé pour exécuter à la fois les tests génériques de clients TUF et les tests de clients spécifiques à Sigstore (avec cosign et d'autres clients sigstore). Des tests réussis conduisent au déploiement en production à l'adresse https://tuf-repo-cdn.sigstore.dev/.
Les workflows importants dans root-signing sont :
create-signing-events crée des branches pour les événements de signature lorsque les signatures approchent de leur expiration.
S'exécute selon une planificationsigning-event crée et gère les pull requests des événements de signature. S'exécute lorsque les branches "sign/*"
sont pousséesonline-sign valide et fusionne les signatures en ligne, et déclenche également publish. S'exécute lorsque
"main" est poussé (mais peut être déclenché manuellement à tout moment)publish publie un dépôt de test sur GitHub Pages, exécute les tests clients, et enfin publie
le dépôt. S'exécute sur déclenchement depuis online-signRemerciements particuliers à Dan Lorenc, Trishank Kuppusamy, Marina Moore, Santiago Torres-Arias, et à toute la communauté SigStore !
Un enregistrement de la cérémonie de signature est disponible ici.