sh0 vend des abonnements mensuels et, jusqu'à récemment, délivrait des licences perpétuelles. Un seul
mois à 19 $ achetait le plan Pro pour toujours. Le correctif auquel tout le monde pense d'abord, c'est
« mettre une date d'expiration dans la clé », et nous l'avons fait : la licence est un document signé
en Ed25519 qui porte paid_through et expires_at. Puis nous avons laissé la fonctionnalité
désactivée, parce qu'une clé datée sans chemin de renouvellement est pire que la fuite. Elle coupe un
client au 38e jour pendant que Stripe continue tranquillement d'encaisser son argent.
Cet article traite de la moitié manquante : comment un serveur qui ne contacte son éditeur qu'une fois par jour obtient sa clé renouvelée sans que personne ne colle quoi que ce soit, et pourquoi la conception suggérée par le prompt de session aurait cassé au moment précis où l'on en avait besoin.
Les trois pièces
Le renouvellement exige trois choses qui n'existaient pas :
- Un endpoint sur le site web où un serveur peut récupérer la clé actuelle d'une licence qu'il détient.
- Un gestionnaire de webhook Stripe pour
invoice.paidqui re-signe la licence pour la nouvelle période. - Du code dans le binaire sh0 qui récupère, vérifie et remplace la clé stockée.
Les pièces 2 et 3 relèvent de la plomberie. La pièce 1 porte la décision de conception, parce que
l'endpoint sert du matériel de clé. L'endpoint existant GET /api/licences/:id/status est public à
dessein : il ne renvoie rien d'autre qu'un statut, et un identifiant de licence circule en clair dans
chaque appel quotidien ; quiconque en apprend un ne doit donc pas pouvoir le transformer en clé.
La conception suggérée par le prompt, et pourquoi elle échoue
Le prompt rédigé pour cette session proposait la preuve de possession évidente : le serveur stocke déjà un SHA-256 de sa clé, il suffit donc d'envoyer ce hash dans un en-tête et de laisser le site le comparer au hash de la clé qu'il a en archive.
Déroulons un renouvellement avec cette conception. Jour 30 : Stripe renouvelle, le webhook re-signe la licence, le site stocke désormais la clé N+1. Jour 31 : le serveur se réveille pour sa vérification quotidienne en détenant la clé N. Il envoie hash(N). Le site calcule hash(N+1). Pas de correspondance. 401. Le serveur garde la clé N, qui expire au jour 37, et au jour 38 un client payant perd son plan.
Le hash cesse de correspondre à l'instant précis pour lequel l'endpoint existe. Le corriger impose au site de mémoriser chaque hash qu'il a jamais émis pour une licence, c'est-à-dire une migration Prisma et une table d'historique. Une seule colonne « hash précédent » ne suffit pas non plus : un serveur resté hors ligne pendant deux cycles de facturation détient la clé N quand le site en est à N+2, et il est bloqué pour de bon.
Ce qui a tranché : la clé brute était déjà là
En confrontant les affirmations du prompt au code, une ligne du gestionnaire d'activation a réglé la question :
rust// Store raw key for cloud registration
let _ = sh0_db::Setting::set(&pool, "license_key_raw", &raw_key);Écrite des mois plus tôt pour une fonctionnalité qui ne l'a jamais relue. Chaque serveur activé sur le
terrain a sa clé brute sur disque. La preuve de possession peut donc être la clé elle-même : le serveur
envoie son document signé actuel comme jeton bearer, et le site vérifie sa propre signature Ed25519
sur ce document et contrôle que le licence_id qu'il contient correspond à l'URL.
C'est sans état. Pas de migration, pas de table d'historique, et cela fonctionne pour chaque serveur activé avant que l'endpoint n'existe. Une clé émise il y a un an reste un document que nous seuls avons pu signer ; un serveur qui a manqué douze renouvellements est donc servi exactement comme celui qui demande chaque jour.
Deux choix délibérés en découlent. Le site ne vérifie pas l'expiration de la clé présentée, parce que la clé est présentée précisément parce qu'elle expire. Et une licence révoquée reçoit un 403 sans aucun matériel de clé, parce que l'endpoint de statut l'a déjà signifié au serveur et que cet endpoint ne doit pas devenir un second avis.
Sur le réseau, la clé voyage en TLS vers l'émetteur qui la détient déjà. La conception par hash aurait elle aussi envoyé un identifiant bearer, simplement plus court. Aucune sécurité n'a été sacrifiée à la simplicité.
Le côté serveur a son propre piège
La passe quotidienne de sh0 chargeait jusqu'ici la licence active. C'est juste pour l'application des droits et faux pour le renouvellement : la licence qui a le plus besoin d'une clé renouvelée est celle que le balayage d'expiration a déjà retirée. Un serveur resté hors ligne au-delà de sa période de grâce, qui revient vers un abonnement à jour, serait resté en Free pour toujours, parce que la passe ne regardait jamais une ligne expirée.
La passe lit désormais la licence la plus récente quel que soit son statut, la retire si elle a expiré, tente le renouvellement, et seulement ensuite interroge la révocation. Les lignes révoquées et remplacées sont définitives et ne sont jamais touchées.
Accepter une clé récupérée suit la même règle que l'activation : la signature d'abord, avant de lire quoi que ce soit dans la charge utile. Ensuite, l'identifiant doit correspondre, et le document doit avoir été émis strictement après celui que nous détenons. Ce dernier contrôle refuse une réponse rejouée et un bug du site qui resservirait un document plus ancien. Chaque refus conserve la clé que nous avons, de la même façon que chaque panne réseau conserve le plan.
Trois tests de bout en bout pilotent toute la passe contre un pool SQLite en mémoire et un bouchon HTTP local qui signe avec une paire de clés éphémère : une licence expirée revient active avec la nouvelle clé stockée ; un document destiné à une autre licence la laisse retirée ; une clé brute périmée, laissée par une licence antérieure, n'est jamais présentée.
Ce qui n'a pas été livré, puis ce qui l'a prouvé
La session qui a écrit les trois pièces s'est terminée avec le drapeau toujours désactivé. Le prompt
disait de l'activer « seulement quand les trois pièces sont prouvées ensemble », et la règle du
registre veut que « corrigé dans le code » ne soit pas un état : un élément est prouvé, ou il est
ouvert. Trois pièces et une douzaine de tests au vert, dont aucun exécuté sur une cible réelle : c'est
exactement la situation pour laquelle cette règle existe. Le ticket est donc resté ouvert, avec une
ligne Preuve due: qui nommait l'observation, la cible et ce qui manquait.
Ce qui manquait, c'était un build. La session suivante, le même jour, a mené la campagne dans l'ordre
qui compte. D'abord, la release candidate est allée sur le serveur témoin, la release publique
latest restant intacte. Seulement ensuite, le drapeau a été activé sur le site, pour qu'aucun
serveur sur le terrain ne puisse recevoir une clé datée avant d'avoir le code pour la renouveler.
Puis l'abonnement au webhook invoice.paid a été créé et relu.
Le plan supposait une horloge de test Stripe. Elle n'a pas survécu au contact du réel : le site tourne
sur des clés live, et le mode test ne l'atteint jamais. La campagne a donc utilisé le vrai checkout,
avec un abonnement à zéro dollar, et forcé le cycle de facturation suivant en avançant la fin de
l'essai de quelques minutes. Stripe a émis une vraie facture subscription_cycle, payée à zéro, et
invoice.paid s'est déclenché.
Le site a re-signé la licence de lui-même : une nouvelle clé, différente octet pour octet de la première, datée de la fin de la nouvelle période plus la semaine de grâce. Le serveur a été redémarré plutôt que de le laisser attendre un jour sa passe suivante, et quelques minutes plus tard son log indiquait :
INFO sh0_api::licence: Licence renewed -- new key stored, no action was needed from anyoneLe serveur détient désormais le nouveau document, et la clé brute sur disque est la nouvelle clé,
octet pour octet. Le contre-cas a été joué sur une seconde licence : l'abonnement a été annulé, le site
a révoqué la licence en quelques secondes, et à sa passe suivante le serveur a journalisé
Licence revoked upstream -- Pro features stop, running applications are untouched et est retombé
en Free.
Une chose que la campagne n'a pas pu jouer en direct : une carte qui échoue. Les cartes de test exigent le mode test, que le site n'utilise pas. Ce chemin est couvert par la preuve du balayage d'expiration sur un autre ticket et par des tests unitaires, et le registre le dit au lieu de prétendre le contraire.
Le ticket a été clos le jour même où il a été consigné, sur une observation horodatée, pas sur le code. Le serveur témoin garde son abonnement à zéro dollar et reste activé ; la boucle est donc désormais exercée chaque mois par le vrai chemin. C'est tout l'intérêt de la règle : l'article que vous venez de lire aurait pu s'arrêter à « le code est écrit », et ce n'en aurait été que la moitié la moins intéressante.