Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

ADR-034 — Discipline des dépendances cryptographiques

Statut : Accepté (2026-06-13). Companion d’ADR-024 (workflow de dépendances / règle des 80 %) ; précise une exemption et une discipline propres à la crypto, sans amender ADR-024. Décline le Principe 6 (dépendances) et la posture « très sérieux sur la crypto » du projet.

Catégorie : Méthode (gouvernance des dépendances).

Contexte

air-crypto (couche 1) n’écrit aucune crypto maison : il enrobe des crates amont auditées et massivement adoptées. Ces crates proviennent de trois upstreams distincts, tous purs Rust, sans dépendance C, sous licences permissives (Apache-2.0 / MIT / BSD-3-Clause ; blake3 en dual CC0-1.0 OR Apache-2.0) :

  • RustCrypto : hachages (sha2, sha3, blake2), AEAD (aes-gcm, chacha20poly1305), hmac, hkdf, argon2, les trait-crates (digest, aead, signature, crypto-common…), et zeroize. MSRV courant des traits : rustc 1.85+ (bumpé par version mineure) — bien en dessous du toolchain pinné d’Air (ADR-025), donc aucune contrainte de toolchain.
  • dalek-cryptography : ed25519-dalek, x25519-dalek, curve25519-dalek, et subtle (constant-time). (À ne pas attribuer à RustCrypto.)
  • équipe BLAKE3 : blake3.

Deux tensions à arbitrer. (1) La règle des 80 % (ADR-024) impose de vendorer une dépendance dont moins de 80 % de l’API est utilisée : appliquée à la crypto, elle conduirait à copier du code cryptographique dans l’arbre Air — ce qui transfère à Air la charge de back-porter les correctifs amont, exactement ce qu’il ne faut jamais faire en crypto. (2) Les builds pinnés/reproductibles (ADR-025) sont indispensables, mais pinner ne doit jamais faire traîner Air derrière un correctif de sécurité crypto.

Décision

Les dépendances cryptographiques d’Air sont suivies au plus près de l’amont, jamais vendorées, et tout correctif de sécurité crypto est appliqué en priorité — sous filet des vecteurs de test connus.

  1. Exemption de vendoring. Les crates crypto des trois upstreams (RustCrypto, dalek-cryptography, BLAKE3) et leurs crates de support (zeroize, subtle, curve25519-dalek, traits…) sont exemptées de l’obligation de vendoring du Principe 6 / ADR-024. On dépend de l’upstream directement, jamais d’une copie vendorée. Exceptions nommées dans docs/EXCEPTIONS.md (comme icu4x, ADR-016).

  2. Trois upstreams suivis nommément. docs/DEPENDENCIES.md documente qui fournit quoi (RustCrypto vs dalek vs BLAKE3) et la veille associée. Ne pas confondre les origines (p. ex. subtle/25519 = dalek, pas RustCrypto).

  3. Tripwire CI (déjà en place, bloquant). cargo audit (base RustSec) et cargo deny check advisories font partie de la barrière : une version vulnérable connue casse le build.

  4. Veille proactive. Au-delà des avis publiés, surveiller les GitHub Security Advisories + releases des trois upstreams (candidat : tâche planifiée périodique). Objectif : ne pas découvrir un correctif crypto avec retard.

  5. Fast-lane sécurité. Les builds restent pinnés (Cargo.lock, ADR-025) pour la reproductibilité, mais un correctif de sécurité crypto est fast-tracké : relèvement prompt du pin hors cadence normale, dès publication amont.

  6. KAT-gated. Tout bump d’une dépendance crypto re-passe les vecteurs de test connus (RFC/NIST — obligatoires en spec air-crypto) avant merge : filet anti-régression qui autorise la mise à jour rapide sans crainte.

  7. Rapide sur la sécurité, pas bleeding-edge sur tout. Release de sécurité → fast-track ; release de feature → cadence normale (éviter les régressions du suivi systématique de chaque mineure).

  8. Licences. Apache-2.0 / MIT / BSD-3-Clause (allowlist deny.toml) ; pour blake3 (dual CC0-1.0 OR Apache-2.0), sélectionner l’option Apache-2.0 dans deny.toml (CC0 hors allowlist).

Conséquences

  • La spec air-crypto renvoie à cet ADR pour la discipline de dépendances et ne la redétaille pas.
  • docs/EXCEPTIONS.md (exemption vendoring + 80 %) et docs/DEPENDENCIES.md (3 upstreams + veille) sont tenus à jour à l’implémentation d’air-crypto.
  • La CI est inchangée (cargo audit/cargo deny déjà présents) ; s’ajoute la veille (manuelle ou planifiée) et le KAT-gating des bumps crypto.
  • Articulation : companion d’ADR-024 (ne l’amende pas — précise une exemption pour la crypto) ; cohérent ADR-025 (repro) et ADR-016 (précédent d’exception nommée, icu4x).

Alternatives rejetées

  • Vendorer la crypto (application stricte d’ADR-024) : transfère la charge des correctifs de sécurité à Air → dangereux, rejeté.
  • Tout pinner sans fast-lane : reproductible mais expose à un retard sur les correctifs → rejeté (la sécurité prime).
  • Suivre systématiquement chaque release amont : risque de régressions → rejeté au profit du fast-track sécurité + cadence normale features, KAT-gated.

Licence du document : MPL 2.0 Statut : Accepté. Édition directe autorisée en phase de design pré-ouverture publique ; après ouverture publique, toute évolution passe par RFC (ADR-015).