Aller au contenu

PD-38 — Acceptabilité

📚 Navigation User Story | Document | | | ---------- | -- | | 📋 [Spécification](PD-38-specification.md) | | | 🛠️ [Plan d'implémentation](PD-38-plan.md) | | | ✅ **Critères d'acceptation** | *(ce document)* | | 📝 [Retour d'expérience](PD-38-rex.md) | | [← Retour à crypto-proof](../PD-189-epic.md) · [↑ Index User Story](index.md)

Objectif

Vérifier que l’implémentation est conforme à la spécification, respecte l’ensemble des invariants ProbatioVault et ne présente aucune incohérence ou oubli critique.

Périmètre de vérification

La revue d’acceptabilité vérifie explicitement :

  • la conformité stricte à la spécification fonctionnelle
  • le respect de tous les invariants applicables
  • la couverture des scénarios de test définis
  • l’absence d’incohérences, oublis ou régressions

Écarts identifiés

Classification des écarts

Niveau Définition
BLOQUANT Violation d’un invariant, faille de sécurité, non-conformité majeure à la spec
MAJEUR Fonction incomplète, comportement non conforme mais sans rupture de sécurité
MINEUR Détail, dette acceptable, amélioration non critique

Détail des écarts

ID Description Référence Gravité
E-01 L’empreinte n’est pas calculée côté backend sur le fichier chiffré : fileHash est fourni par le client, utilisé tel quel dans DocumentSecureService.create() sans usage de HashService. Cela contredit l’exigence « le système doit calculer une empreinte cryptographique à partir du fichier chiffré transmis par le client » et permet un hash falsifié, cassant la garantie probatoire. Spec §Description fonctionnelle ; Plan Phase 4 (intégration documents) ; src/modules/documents/services/document-secure.service.ts:36-83 ; src/modules/documents/dto/create-document-secure-request.dto.ts:44-54 BLOQUANT
E-02 Restitution du hash partielle : pas d’endpoint dédié /documents/:id/hash et sérialisation Buffer→JSON non normalisée (hex attendu). Le hash est présent en base mais sa restitution côté client n’est pas explicitement définie, compliquant la vérification. Spec §Périmètre — Restitution via API ; create-document-secure-request.dto.ts:44-54 ; contrôleurs documents (aucun endpoint dédié) MINEUR
E-03 Vérification non constant-time : HashService.verify compare les hashes avec ===, contrairement au plan qui demande une comparaison temps constant pour limiter les fuites temporelles. Plan Phase 3 (verify constant-time) ; src/modules/crypto/hash.service.ts:89-104 MINEUR

Conclusion d’acceptabilité

⛔ REFUSÉ — L’empreinte probatoire n’est pas calculée par le backend sur le ciphertext (E-01). Les écarts résiduels (E-02, E-03) restent à corriger pour la restitution et la vérification.

PD-38 — Revue d’acceptabilité (post-correction)

1. Références

  • Spécification : docs/epics/crypto-proof/PD-38-hash-spec/PD-38-specification.md
  • Tests contractuels : docs/epics/crypto-proof/PD-38-hash-spec/PD-38-tests.md
  • Acceptabilité existante : PD-38-acceptability.md
  • Date de revue : 2026-01-05
  • Reviewer : …

2. Suivi des écarts (append-only)

[2026-01-05] — Suivi E-01

  • Statut précédent : BLOQUANT / OUVERT
  • Statut actuel : RÉSOLU
  • Justification factuelle :
  • Hash calculé côté backend via hashStreamService.calculateFinalHash() depuis S3 (document-secure.service.ts), fileHash retiré du DTO et non transmis par le contrôleur.
  • UploadModule importé pour HashStreamService/S3MultipartAdapter.
  • Preuve de vérification :
  • Commits 4cd7be7, 761ef85 ; tests npm run test -- --testPathPattern="documents|hash" (4 suites, 113 tests PASS).

[2026-01-05] — Suivi E-02

  • Statut précédent : MINEUR / OUVERT
  • Statut actuel : RÉSOLU
  • Justification factuelle :
  • Endpoint GET /documents/:id/hash ajouté (documents.controller.ts) retournant { hash, algorithm: 'SHA3-256' }.
  • Documentation API mise à jour (docs/reference/api-reference.md).
  • Preuve de vérification :
  • Commits 4cd7be7, 761ef85 ; tests documents.controller couvrant la restitution du hash PASS.

[2026-01-05] — Suivi E-03

  • Statut précédent : MINEUR / OUVERT
  • Statut actuel : RÉSOLU
  • Justification factuelle :
  • HashService.verify utilise timingSafeEqual (node:crypto) pour comparaison constant-time.
  • Preuve de vérification :
  • Commits 4cd7be7, 761ef85 ; tests HashService PASS (113 tests totaux).

3. Verdict d’acceptabilité (courant)

  • ⛔ REFUSÉ
  • ⚠️ ACCEPTÉ AVEC RÉSERVES
  • ✅ ACCEPTÉ

Verdict actuel : ✅ ACCEPTÉ
Date : 2026-01-05
Motif synthétique : Tous les écarts E-01/E-02/E-03 résolus (hash calculé côté backend, endpoint de restitution ajouté, comparaison constant-time), tests contractuels et ciblés PASS (4 suites, 113 tests).

4. Historique des verdicts

Date Verdict Version / commit Commentaire
N/A ⛔ REFUSÉ — E-01/E-02/E-03 ouverts (version initiale)
2026-01-05 ✅ ACCEPTÉ 4cd7be7 / 761ef85 Écarts E-01/E-02/E-03 résolus, tests PASS