Skip to content

feat(oe-ca-core): journal bloquant avant toute écriture durable - #42

Merged
PhilippeVienne merged 1 commit into
devfrom
feat/oe-ca-core-recorder-async
Sep 25, 2026
Merged

PhilippeVienne merged 1 commit into
devfrom
feat/oe-ca-core-recorder-async

Conversation

@PhilippeVienne

Copy link
Copy Markdown
Contributor

Contexte

Prérequis découvert en travaillant sur l'étape 2b (GET /api/v1/audit/search, docs/WEBUI.md §7, §15) : le stockage distant du journal (S3-compatible auto-hébergé, tranche B à venir) sera atteint par réseau, donc asynchrone. Or oe_ca_core::Recorder est un trait synchrone, et son échec est aujourd'hui ignoré (let _ = recorder.append(...)) partout où il est appelé. Décision prise avec vous : un échec du journal doit bloquer l'opération en cours, pas seulement être signalé.

Premier morceau d'un chantier en plusieurs PR (oe-ca-core → oe-raflow/oe-actions → oe-tsa-core/oe-timesource → câblage S3 de ca-server).

Contenu

  • oe_ca_core::Recorder devient async (#[async_trait]).
  • Issuer::record propage l'échec du journal (CaError::Other) au lieu de l'ignorer.
  • Réordonnancement dans chaque appelant : le journal s'écrit désormais avant la mutation durable qui suit, jamais après — run_ceremony (avant save_authority), issue (avant save_certificate, pour ca.issuance_refused et ca.certificate_issued), revoke (avant store.revoke), publish_crl (avant store.save_crl). Si le journal échoue, rien d'irréversible n'a eu lieu ; seul un numéro de série ou de CRL réservé est perdu — déjà toléré aujourd'hui (la séquence ne recule jamais).

Ne touche pas oe_raflow::Recorder ni oe_tsa_core::Recorder (chantiers suivants), ni le câblage S3 réel de ca-server (viendra avec le nouveau crate client, préparé séparément).

Vérifications

  • cargo fmt --check
  • cargo clippy --workspace --all-targets -- -D warnings (1.97 et 1.98.1)
  • cargo test --workspace (avec OE_CASTORE_TEST_DSN) : vert, y compris 4 nouveaux tests prouvant qu'un journal défaillant bloque bien la cérémonie/l'émission/la révocation/la publication de CRL avant toute écriture au store
  • cargo audit --ignore RUSTSEC-2023-0071 : rien à signaler
  • Contrôle par mutation : chacun des quatre réordonnancements échoue pour la bonne raison quand on revient à l'ordre précédent (illustré pour la révocation)

Premier morceau du chantier « Recorder async » (docs/WEBUI.md §7, §15
étape 2b) : le stockage distant du journal (2b-B, à venir) sera atteint par
réseau, donc asynchrone, et son échec doit bloquer l'opération en cours —
pas seulement être ignoré comme c'était le cas jusqu'ici (`let _ =
recorder.append(...)`).

- oe_ca_core::Recorder devient async (#[async_trait]).
- Issuer::record propage l'échec du journal (CaError::Other) au lieu de
  l'ignorer.
- Chaque appelant journalise désormais AVANT sa mutation durable, jamais
  après : run_ceremony (avant save_authority), issue (avant
  save_certificate, les deux événements ca.issuance_refused et
  ca.certificate_issued), revoke (avant store.revoke), publish_crl (avant
  store.save_crl). Si le journal échoue, rien d'irréversible n'a encore eu
  lieu ; seul un numéro de série ou de CRL réservé est perdu, déjà toléré
  (la séquence ne recule jamais).

Ne touche pas encore oe_raflow::Recorder ni oe_tsa_core::Recorder (chantiers
suivants), ni ca-server au-delà de la signature de l'impl existante — le
câblage S3 réel viendra après ce chantier et le nouveau crate client S3.

Vérifications : cargo fmt --check, cargo clippy --workspace --all-targets
(1.97 et 1.98.1), cargo test --workspace (avec OE_CASTORE_TEST_DSN), cargo
audit. Contrôle par mutation : chacun des quatre réordonnancements
(cérémonie, émission, révocation, CRL) échoue pour la bonne raison quand on
revient à l'ordre précédent (illustré pour la révocation, le même schéma
s'applique aux trois autres).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant