Résumé

  • Le README public de pai-auth-ws-client indique Java 8 ou version ultérieure et illustre l’installation avec la version 1.0.0. Il n’a reçu qu’un seul commit, en novembre 2024.
  • Le plancher a bougé dans les versions. La 1.5.0 a porté les paramètres Maven source et target à 17 ; la 1.5.1 conserve ce choix et son workflow public utilise JDK 17.
  • Le paquet 1.5.1 existe bien sur JitPack. Son JAR de 20 580 octets contient douze classes, toutes de version majeure 61, et son manifeste mentionne JDK 17.0.12.
  • Le correctif utile n’est pas de revenir à Java 8, mais de publier pour chaque version une fiche reliant runtime minimal, runtimes testés, révision documentaire et périmètre de compatibilité PAI.

Le seuil que lit la JVM

Un intégrateur arrive sur le dépôt de LACNIC avec une question simple : quelle version de Java faut-il prévoir pour utiliser le client d’authentification PAI ? Le README répond « Java 8 ou supérieur ». Juste après, deux exemples de dépendance—Maven et Gradle—emploient la version 1.0.0. Leur commentaire invite à remplacer ce numéro par une version publiée sur JitPack, dont le badge affiche aujourd’hui 1.5.1. Dépôt du client PAI README de la version 1.5.1 Page du projet sur JitPack

Cette trajectoire est raisonnable : lire le prérequis, choisir la version courante, laisser l’outil de dépendances la résoudre. Or le fichier livré ne peut pas être chargé par une JVM Java 8. Le JAR 1.5.1 servi par JitPack contient douze fichiers .class; leur champ major_version vaut toujours 61. La spécification de la JVM associe 52 à Java SE 8 et 61 à Java SE 17. Le manifeste de l’archive indique en outre Build-Jdk: 17.0.12. POM JitPack 1.5.1 JAR JitPack 1.5.1 Spécification JVM, format des classes

Ce constat ne décrit aucun incident réel. Aucun élément consulté ne montre un utilisateur bloqué, une connexion refusée, une indisponibilité du service PAI ou une faille de sécurité. Il prouve seulement que le minimum générique annoncé au lecteur ne correspond plus au bytecode de la version la plus récente mise en avant.

Passer à Java 17 peut être la bonne décision

Le dossier le plus solide en faveur de LACNIC se trouve dans la version courante elle-même. Un client d’authentification n’a pas intérêt à rester indéfiniment attaché à un runtime ancien. Java 17 offre une base de maintenance plus récente ; relever le plancher peut faciliter les mises à jour de dépendances et réduire le coût de prise en charge d’un environnement obsolète. La compatibilité perpétuelle n’est pas une obligation d’ingénierie.

Surtout, les trois pièces techniques de la 1.5.1 sont alignées. Le POM fixe java.version, maven.compiler.source et maven.compiler.target à 17. Le workflow associé au tag installe le JDK 17 de distribution Zulu et lance la vérification Maven. Le JAR obtenu contient du bytecode 61. Configuration, construction publique et résultat binaire racontent la même histoire. POM 1.5.1 Workflow 1.5.1

Le README n’est pas non plus une consigne aveugle de mise à jour. Le commentaire de ses exemples demande de substituer une version publiée. Celui qui choisit expressément 1.0.0 retrouve dans son POM un source et un target à 1.8. La documentation était cohérente avec la première version. POM 1.0.0

La difficulté naît précisément entre ces deux faits légitimes. Une consigne de remplacement fait traverser une frontière de version. Un prérequis générique prétend couvrir ce qui se trouve après cette frontière. Quand le plancher change, le lien entre version et runtime doit devenir explicite.

La bascule se situe à la version 1.5.0

La série des tags permet de dater le changement sans spéculer sur une infrastructure privée. La version 1.0.0 cible Java 1.8. Les versions 1.1.0 à 1.4.0 gardent explicitement maven.compiler.source et maven.compiler.target à 1.8, même si leur CI fonctionne déjà sous JDK 17. Leurs POM contiennent aussi deux déclarations de java.version, d’abord 1.8 puis 17 : cette transition imparfaite mérite d’être décrite telle quelle, sans prétendre que toutes les propriétés étaient uniformes.

La version 1.5.0 tranche : propriété Java, source et target passent à 17. La 1.5.1 reprend ces valeurs. La dernière version ciblant encore 1.8 est donc la 1.4.0 dans la série publiée observée. POM 1.4.0 POM 1.5.0

La prose, elle, reste immobile. L’historique public ne montre qu’un commit du README, daté du 1er novembre 2024. Les octets vérifiés sont identiques dans les tags de 1.0.0 à 1.5.1 et sur la branche principale. GitHub date la sortie 1.5.0 du 29 octobre 2025 et la 1.5.1 du 14 avril 2026. Le corps de ces deux fiches de version est vide : aucune note publique n’y signale le nouveau seuil. Historique du README Liste des versions Version 1.5.1

Il n’y a pas besoin d’un grand dysfonctionnement pour que l’information se sépare. Une phrase exacte en 2024 peut devenir une instruction incomplète en 2026, alors que le code suit une évolution cohérente.

Ne pas confondre construction, cible et service

Dire simplement « le README est faux » ferait perdre la structure de preuve. Le JDK de construction, la cible du compilateur et le runtime minimal ne sont pas des synonymes. On peut compiler sous JDK 17 et produire des classes plus anciennes. Le guide du plugin Maven rappelle cette distinction et précise que target ne garantit pas à lui seul la disponibilité correcte de toutes les API. L’inspection du JAR est donc décisive pour connaître son format, mais elle ne suffit pas à établir toute sa compatibilité fonctionnelle. Guide du plugin Maven Compiler

Le format 61 dit qu’une JVM de génération Java 17 est nécessaire pour ces classes. Il ne dit pas avec quelle révision du service PAI elles ont été testées, quels modes d’identification sont pris en charge, ni si une requête aboutira dans l’environnement d’un membre. La résolution réussie d’une dépendance n’est pas son chargement ; le chargement n’est pas l’initialisation du client ; l’initialisation n’est pas l’acceptation d’une authentification.

Même l’absence d’assets attachés aux releases GitHub doit rester à sa place. Elle ne signifie pas que la bibliothèque manque : le README oriente vers JitPack, et le POM comme le JAR y répondent en HTTP 200. L’API de build JitPack renvoie certes une combinaison étrange—statut ok, message « Not found », modules et URL de build vides—mais ce texte contradictoire ne l’emporte pas sur le téléchargement effectif.

Cette précision distingue aussi ce sujet d’autres contrôles logiciels. Il ne s’agit pas de vérifier une signature détachée, l’autorité d’une clé ou la reproductibilité d’un build. Il ne s’agit pas de relier un service électoral en ligne à un commit audité. Il ne s’agit pas non plus de savoir si une capacité ASPA ou RTR livrée est activée. Ici, l’objet manquant est beaucoup plus étroit : quelle version exige quel runtime ?

Une fiche de compatibilité par version

La réparation peut tenir dans un petit fichier lisible par l’humain et la machine. Pour chaque release, LACNIC pourrait publier le projet, le tag, le commit, les coordonnées Maven, le niveau de classe, le JDK de construction, le runtime minimal pris en charge et les runtimes effectivement testés. La même fiche devrait indiquer le périmètre de compatibilité avec l’API PAI, la révision du guide applicable, les changements matériels, la fenêtre de support et le lien de correction ou de remplacement.

Une empreinte du JAR peut rattacher la fiche aux octets inspectés. Elle ne transforme pas l’article en audit de signature. De même, « construit avec JDK 17 », « cible 17 » et « testé sur 17 et 21 » doivent rester trois champs, car ils ne prouvent pas la même chose. Si une version ancienne reste maintenue, la fiche doit le dire ; si elle est seulement encore téléchargeable, ce statut ne doit pas être confondu avec le support.

L’essentiel des données existe déjà : tag, commit, POM, workflow et artefact. Le travail manquant consiste à joindre ces pièces au moment où l’intégrateur choisit. C’est une coordination mince, non une prise de contrôle sur son système.

La compatibilité est aussi une question de gouvernance

Le runtime demeure une décision locale. LACNIC ne choisit ni la distribution Java d’un opérateur, ni son calendrier de migration, ni ses tests. Mais LACNIC contrôle la manière dont la version publiée décrit son seuil d’entrée. JitPack contrôle les octets qu’il sert. La JVM applique le format de classe. L’intégrateur porte le risque de déploiement.

Une matrice claire permet à chacun de rester dans son rôle. LACNIC peut adopter Java 17 sans donner l’impression de maintenir Java 8 pour la dernière release. Un opérateur peut rester sur une branche ancienne en connaissance de cause ou chiffrer la migration avant une mise à jour urgente. Le support peut commencer par un identifiant de version, pas par une dispute sur le sens d’une phrase historique.

Le problème n’est donc pas le mouvement du code. Il est l’immobilité de la promesse. Quand le runtime change, la documentation doit acquérir une version elle aussi.

Sources

  1. LACNIC : dépôt du client PAI
  2. LACNIC : README de la version 1.5.1
  3. LACNIC : POM de la version 1.0.0
  4. LACNIC : POM de la version 1.4.0
  5. LACNIC : POM de la version 1.5.0
  6. LACNIC : POM de la version 1.5.1
  7. LACNIC : workflow de build de la version 1.5.1
  8. LACNIC : liste des releases GitHub
  9. LACNIC : release 1.5.1
  10. LACNIC : historique du README
  11. JitPack : projet du client PAI de LACNIC
  12. JitPack : POM généré de la version 1.5.1
  13. JitPack : JAR de la version 1.5.1
  14. Oracle : spécification de la JVM, format des fichiers de classe
  15. Apache Maven : configuration de source et target