test: clé de licence dont l’`exp` dépasse 2^32 (licences de 100 ans) #361

New issue

Closed

opened 2026-09-27 19:45:15 +00:00 by maximus · 1 comment

maximus commented

2026-09-27 19:45:15 +00:00

Owner

Suite de maximus/maximus-api#63 (licences de 100 ans, 36525 jours ; PR maximus-api#72). Priorité basse, mais à faire avant qu'un refactor des claims ne passe.

Contexte vérifié (2026-09-27)

Avec 100 ans, le claim exp d'une clé vaut environ 4,94 milliards de secondes : au-delà de 2^32. Les clés émises jusqu'ici restaient sous 2^31, donc cette frontière n'a jamais été exercée par un test ni par une clé réelle.
src-tauri/src/commands/license_commands.rs : exp: i64 dans LicenseClaims et ActivationClaims, identique à tous les tags de v0.7.0 à v0.15.0. jsonwebtoken 9 valide exp en u64. Les builds publiés sont x86_64 seulement. Le front affiche new Date(expires_at * 1000).
Tous les tests actuels du fichier signent des jetons avec exp: now() + 86400. Aucun ne passe une valeur au-delà de 2^32.
L'acceptation des clés de 100 ans par les binaires installés est donc établie par lecture du code, pas par exécution.

Tâches

Test Rust : une licence signée avec exp = now() + 36525 * 86400 est acceptée par strict_validation(), et expires_at rendu au front vaut exactement cet exp.
Test Rust : la même chose pour une valeur juste au-dessus de 2^32, pour épingler la frontière elle-même.
Test front : formatExpiry (carte Licence) rend une date en 2126 sans débordement ni « Invalid Date ». À coordonner avec #347, qui affiche « Sans échéance » au-delà de 50 ans.

Critères d'acceptation

Un refactor qui passerait exp en u32, i32 ou usize sur une cible 32 bits fait rougir la suite.
cargo test et la suite front verts.

Suite de maximus/maximus-api#63 (licences de 100 ans, 36525 jours ; PR maximus-api#72). Priorité basse, mais à faire avant qu'un refactor des claims ne passe. ## Contexte vérifié (2026-09-27) - Avec 100 ans, le claim `exp` d'une clé vaut environ 4,94 milliards de secondes : au-delà de 2^32. Les clés émises jusqu'ici restaient sous 2^31, donc cette frontière n'a jamais été exercée par un test ni par une clé réelle. - `src-tauri/src/commands/license_commands.rs` : `exp: i64` dans `LicenseClaims` et `ActivationClaims`, identique à tous les tags de v0.7.0 à v0.15.0. `jsonwebtoken` 9 valide `exp` en `u64`. Les builds publiés sont x86_64 seulement. Le front affiche `new Date(expires_at * 1000)`. - Tous les tests actuels du fichier signent des jetons avec `exp: now() + 86400`. Aucun ne passe une valeur au-delà de 2^32. - L'acceptation des clés de 100 ans par les binaires installés est donc établie par lecture du code, pas par exécution. ## Tâches - [ ] Test Rust : une licence signée avec `exp = now() + 36525 * 86400` est acceptée par `strict_validation()`, et `expires_at` rendu au front vaut exactement cet `exp`. - [ ] Test Rust : la même chose pour une valeur juste au-dessus de 2^32, pour épingler la frontière elle-même. - [ ] Test front : `formatExpiry` (carte Licence) rend une date en 2126 sans débordement ni « Invalid Date ». À coordonner avec #347, qui affiche « Sans échéance » au-delà de 50 ans. ## Critères d'acceptation - [ ] Un refactor qui passerait `exp` en `u32`, `i32` ou `usize` sur une cible 32 bits fait rougir la suite. - [ ] `cargo test` et la suite front verts.

maximus added this to the spec-paiements milestone 2026-09-27 19:45:15 +00:00

maximus added the

status:ready

type:refactor

source:analyste

labels 2026-09-27 19:45:15 +00:00

maximus commented

2026-09-27 20:21:50 +00:00

Author

Owner

Doublon de #363, créée huit minutes plus tard avec le même titre et un corps plus complet (coordination du skill /issue-license). Fermée ici, le suivi se fait dans #363.

Doublon de #363, créée huit minutes plus tard avec le même titre et un corps plus complet (coordination du skill `/issue-license`). Fermée ici, le suivi se fait dans #363.

maximus closed this issue

2026-09-27 20:21:51 +00:00