Résumé

  • Dans la révision publique 3c2068477eb38ebbbe70039ee6e1b7b004fc69cd, toute nouvelle élection reçoit par défaut le mode de récupération ALL, quel que soit son type ; ONLY_BR et NONE restent configurables.
  • Une adresse normalisée est confrontée séparément aux électeurs, aux contacts des organisations membres et aux soutiens de candidature ; jusqu’à dix liens par catégorie peuvent être mis en file d’envoi.
  • La réponse uniforme et les plafonds sont de vrais garde-fous. Il manque toutefois un reçu privé reliant chaque renvoi à la règle électorale, au rôle, à la durée du jeton, à sa remise, à son usage et à son invalidation.

Une boîte de réception ne vote pas. Elle ne désigne pas non plus un candidat et n’accorde aucun soutien. Elle transporte seulement un message vers la personne qui la contrôle à cet instant. Cette banalité devient décisive lorsque le message contient un lien porteur d’un pouvoir électoral.

Le dépôt public elections-open-source de LACNIC rend ce passage observable. Dans les deux constructeurs de l’objet Election, une nouvelle élection est d’abord de type BOARD, puis reçoit la valeur produite par ElectionLinkRecoveryMode.defaultForElectionType. L’énumération connaît trois modes — NONE, ONLY_BR, ALL — mais la fonction renvoie ALL pour tout type fourni. Les tests attendent explicitement ce résultat. La documentation fonctionnelle l’énonce sans détour : dans cette distribution publique, les nouvelles élections démarrent en ALL, indépendamment du type.

Ce choix peut parfaitement servir la participation. Un électeur légitime ne devrait pas perdre sa voix parce qu’un message initial a été classé, supprimé ou envoyé sur un appareil devenu indisponible. Une organisation ne devrait pas rater une période de nomination uniquement parce que son contact ne retrouve plus l’URL. La récupération répare une panne de communication.

Mais elle réexpédie aussi une capacité. Le problème éditorial n’est donc pas « l’adresse électronique est-elle sûre ? ». Il est plus précis : quelle autorité est remise, sur le fondement de quel registre, pendant quelle fenêtre et avec quelle preuve de clôture ? Le paramètre ALL répond à la portée logicielle. Il ne répond pas à la question du mandat.

Trois recherches qui ne désignent pas le même principal

Le formulaire commence par supprimer les espaces et passer le courriel en minuscules. Il lance ensuite trois recherches limitées à l’élection concernée. La première examine UserVoter.mail. La deuxième examine Organization.membershipContactEmail. La troisième examine SupportNomination.supportingContactEmail.

Ces tables ne sont pas trois copies d’un même compte. L’électeur tient son droit du corps électoral. Le contact d’une organisation agit dans la chaîne qui permet à un membre de proposer une candidature. Le soutien intervient dans une relation déjà ouverte entre une nomination et un appui. Une même adresse peut légitimement apparaître dans les trois espaces, mais cette égalité textuelle ne fusionne pas leurs fondements.

Le code préserve une partie de la distinction. Il envoie un VOTER_VOTE_LINK, un NOMINATION_LINK ou un SUPPORT_LINK selon la source. Pour les organisations, le lien n’est retenu que si le jeton de nomination n’est pas vide. Chaque catégorie est plafonnée à dix résultats. ALL ne pose aucun filtre de pays ; ONLY_BR applique le Brésil au champ pertinent de chaque objet.

Ce plafond ne signifie pas dix liens en tout. Les trois requêtes ont chacune leur maximum. Il ne prouve pas davantage qu’une seule personne devrait posséder tous les liens trouvés. Il protège le traitement contre une expansion sans borne. L’autorité reste une propriété de la ligne d’origine et de l’état du processus.

L’interface évite, à juste titre, de révéler les correspondances. Lorsque le traitement ne connaît pas d’erreur opérationnelle, le même message d’acceptation apparaît si le courriel a trouvé des données ou s’il n’en a trouvé aucune. Les liens sont expédiés à l’adresse stockée ; ils ne sont pas affichés au visiteur. Cette réponse uniforme réduit la possibilité de dresser publiquement une liste d’électeurs ou de contacts.

La confidentialité de la réponse n’est pourtant pas la preuve de l’autorité de la remise. Une demande peut ne rien divulguer à l’écran tout en faisant parvenir plusieurs capacités à une boîte partagée. Deux contrôles différents sont en jeu : empêcher l’énumération et garantir que le renvoi demeure fidèle au rôle électoral.

Le défaut logiciel et la décision de gouvernance

Un défaut a une vertu : il rend une fonction utilisable sans demander un choix supplémentaire. Il a aussi un coût : l’absence de décision explicite ressemble ensuite à une décision prise.

Avec ALL, la récupération est large au moment où l’objet est créé. Un administrateur peut passer à ONLY_BR ou à NONE. Le dépôt ne prouve pas que LACNIC conserve le défaut dans une élection réelle. Il ne montre ni déploiement, ni réglage en production, ni demande de récupération. La conclusion doit s’arrêter au code public : la distribution rend la portée générale initiale et demande une action pour la réduire.

Cette distinction compte parce que les élections ne partagent pas toutes la même constitution. Le conseil d’administration, la Commission fiscale, la Commission électorale, la modération du PDP, l’ASO AC et l’IANA Review Committee répondent à des règles, des électorats et des temporalités différents. On peut décider que le même mécanisme convient à chacun. Encore faut-il conserver la décision et non seulement sa valeur finale.

Un auditeur devrait pouvoir savoir si ALL a été examiné, simplement hérité ou choisi à titre temporaire. Il devrait voir qui a accepté le risque, quels rôles pouvaient être récupérés et quelle règle électorale justifiait chacun d’eux. La colonne public_link_recovery_mode ne porte pas cette histoire.

La fenêtre elle-même est composée. Le panneau n’active la récupération que si l’élection n’est pas close et si le mode n’est pas NONE. La page publique doit être accessible et avoir atteint l’étape N_1. La documentation précise que la récupération n’ajoute pas de calendrier autonome. Elle emprunte donc l’ouverture de la page et la clôture générale de l’élection.

Les capacités renvoyées rencontrent ensuite leurs propres barrières. Le vote dépend de sa période ; la nomination et le soutien ont d’autres états et d’autres échéances. Un lien reçu peut être déjà inutilisable, ce qui n’est pas un dommage électoral. Un lien encore valable doit être bloqué au bon instant en aval. Pour comprendre l’événement, le journal de récupération doit être relié à ce contrôle terminal.

Le courriel prouve une destination, pas une qualité institutionnelle

La logique de récupération suppose qu’un courriel enregistré reste un canal acceptable pour restituer un lien déjà attribué. C’est une hypothèse opérationnelle courante. Elle ne transforme pas le propriétaire actuel de la boîte en source du droit.

Les boîtes de rôle compliquent la lecture. Une adresse peut être partagée par plusieurs salariés. Un prestataire peut administrer la messagerie. Un contact peut quitter l’organisation avant que la base électorale soit mise à jour. À l’inverse, une personne parfaitement autorisée peut ne rien recevoir à cause d’un rebond, d’un filtre ou d’un retard. « Mis en file » n’est donc ni « reçu » ni « utilisé par le mandataire compétent ».

Le panneau cumule le nombre de correspondances et le nombre d’envois mis en file. Si une catégorie trouve des lignes mais n’arrive à en mettre aucune en file, elle produit une erreur opérationnelle. Ce contrôle mérite d’être reconnu. Il situe la panne avant la remise, mais ne suit pas le message jusqu’au résultat final.

La comparaison avec les pratiques de récupération d’identité éclaire la forme du contrôle sans créer une norme électorale. L’OWASP recommande, pour les mots de passe oubliés, une réponse identique, des limites de fréquence ou un CAPTCHA et des jetons aléatoires, à usage unique et expirants. Le NIST demande que les méthodes alternatives de récupération reposent sur une analyse de risque documentée et associe une notification aux événements de récupération de compte. Un vote n’est pas un mot de passe, et ces textes n’imposent rien à LACNIC. Ils montrent néanmoins pourquoi la récupération doit posséder sa propre chaîne de preuve.

Le code capturé comporte déjà plusieurs éléments : réponse générique, limite par catégorie, portée limitée à une élection, possibilité de CAPTCHA et transmission de l’adresse IP du client à l’opération d’envoi. Le CAPTCHA n’est exécuté que si un réglage global l’autorise et si une clé de site existe. On ne peut déduire de cette condition ni son absence ni sa présence dans un système réel.

De même, les sources consultées ne démontrent pas la longueur aléatoire des jetons concernés, leur expiration, leur rotation après renvoi, la livraison par le fournisseur de messagerie ou leur invalidation après action. Ces propriétés peuvent exister ailleurs dans l’application ou dans l’exploitation. L’article ne transforme pas un silence documentaire en vulnérabilité.

La transparence du code a besoin d’un reçu de déploiement

LACNIC présente le système comme ouvert à l’audit. Le dépôt tient cette promesse d’une manière concrète : il permet de suivre le formulaire jusqu’aux trois familles d’objets, puis jusqu’à la file d’envoi. Un commit du 11 septembre 2026 a conservé le test du défaut ALL lors d’une mise à niveau générale des dépendances. Le commit de tête du 11 septembre ajoute des tests de lecture de fichiers téléversés. Ces événements datent la photographie sans prouver qu’elle est en production.

Le code ouvert rend donc la question formulable, mais pas résolue. Une branche publique n’identifie pas à elle seule le binaire déployé, sa configuration, ses secrets, ses contrôles réseau ou l’élection qui l’utilise. L’article ne prétend pas que le formulaire public de LACNIC exécute cette révision. Il n’a envoyé aucune demande.

Cette limite distingue aussi le sujet de travaux voisins. Un précédent article BTW a étudié l’adresse placée dans le chemin d’une requête GET pour une consultation authentifiée de rapports. Ici, le courriel est saisi dans un formulaire de récupération et sert à réexpédier des capacités. Un autre article archivé posait la question du lien entre code ouvert et build d’un scrutin réel. Le mécanisme présent est plus étroit : même en supposant le build connu, comment prouver la restitution de trois pouvoirs différents ?

Une projection publique suffisante ne montrerait aucun électeur. Elle indiquerait le commit ou la version retenue, le mode de récupération effectif, les catégories de liens activées, la fenêtre, les contrôles d’automatisation et l’autorité ayant approuvé le réglage. Les événements individuels resteraient dans un registre protégé.

Le reçu minimal de récupération de capacité

Le reçu privé devrait commencer par l’élection et sa génération logicielle. Il enregistrerait le type d’élection, la règle de participation et la valeur de récupération. Surtout, il distinguerait une valeur héritée d’un choix explicite. Le nom ou la fonction de l’approbateur, la date et le motif suffiraient à transformer un défaut en décision traçable.

Chaque correspondance conserverait ensuite son rôle : électeur, organisation proposant une candidature ou contact de soutien. Une référence opaque à la ligne d’autorité permettrait l’audit sans recopier le courriel. Le reçu indiquerait si cette ligne était courante, dans quelle fenêtre l’acte demeurait possible et quel état empêchait déjà une nouvelle action.

La partie consacrée au jeton noterait la génération du lien, son échéance et son statut. S’agit-il du renvoi d’un secret existant ou d’un remplacement ? L’ancien a-t-il été invalidé ? Le nouveau a-t-il été utilisé, expiré, révoqué ou remplacé ? La mise en file, la livraison et l’action sont trois événements distincts.

Enfin, la clôture serait prouvée. La fin du vote, de la nomination, du soutien et de l’élection ne sont pas nécessairement une seule date. Lorsqu’un lien reste consultable pour mémoire, le reçu préciserait qu’il ne permet plus de décider. Aucun jeton ni aucune adresse n’a besoin d’apparaître dans le rapport public.

Un tel dispositif n’a pas pour but de rendre la récupération plus difficile. Il préserve sa fonction d’accès tout en refusant que la boîte de réception devienne, par habitude, le registre du mandat. La bonne commodité répare un message perdu. La bonne preuve montre que le pouvoir renvoyé était encore celui de son destinataire.

Sources