Aller au contenu

Compatibilité des formats

Les discriminants de Payload et l’encodage canonique sont gelés. Les changer invalide tout journal déjà scellé. Un nouveau type de payload prend le prochain entier libre ; rien n’est jamais renuméroté.

La règle a déjà été exercée plusieurs fois : Actor (tag 7) a été ajouté après coup pour la chaîne d’acteurs, plutôt que d’ajouter un champ à Delegation, puis ConfigReload (tag 8), SessionCert (tag 9) et McpAccess (tag 10) de la même manière. Le test record_format_is_frozen porte des empreintes de référence pour les payloads existants ; aucune n’a bougé. Le jour où ce test échoue, la question à se poser est : « quels journaux scellés viennent d’être invalidés ? »

La chaîne de format d’un bundle fait partie des octets signés : une révision est donc une nouvelle chaîne, et chaque révision sous laquelle un artefact a été publié continue de se vérifier avec les octets de signature de son époque.

Exercé deux fois :

  • obsign-identity/2 a étendu les octets signés avec les marqueurs machine ;
  • obsign-policy/2 les a étendus avec les déclarations d’arguments.

Les deux suivent les deux mêmes règles :

  1. un bundle /1 conserve son empreinte et sa signature ;
  2. un fichier /1 portant des champs que seul /2 signe est refusé plutôt que cru : sans quoi ces champs constitueraient une autorité non signée.

Le plan de contrôle n’émet /2 que lorsqu’un déploiement utilise réellement la nouvelle fonctionnalité, si bien qu’une flotte qui ne le fait jamais n’est jamais forcée de mettre une passerelle à niveau.

JSON autorise trop de liberté (ordre des clés, espaces, nombres) : deux sérialiseurs peuvent produire deux empreintes pour la même donnée. Dans l’encodage canonique, chaque champ est préfixé par sa longueur et la concaténation est injective. JSON reste le format de transport et de lecture ; obsign-audit-core est le seul endroit où un hachage est calculé, partagé indifféremment par la passerelle, le ledger, le plan de contrôle et le vérificateur.