Zusammenfassung

  • Die öffentliche README von pai-auth-ws-client nennt Java 8 oder neuer als Voraussetzung und zeigt in den Einbindungsbeispielen Version 1.0.0. Seit ihrem einzigen Commit im November 2024 blieb sie unverändert.
  • Mit Version 1.5.0 stellte das POM Quell- und Zielversion auf Java 17 um. Version 1.5.1 behält diese Vorgabe bei; der veröffentlichte Build-Workflow läuft ebenfalls mit JDK 17.
  • Das Artefakt ist verfügbar. JitPack liefert POM und JAR für 1.5.1. Alle zwölf enthaltenen Klassendateien tragen Major-Version 61, das Manifest nennt JDK 17.0.12.
  • Ein knapper, versionierter Kompatibilitätsnachweis sollte Mindest- und getestete Laufzeiten, Tag, Commit, Artefaktkoordinaten, Dokumentationsstand und PAI-Schnittstellenumfang zusammenführen. Er wäre Orientierung, keine Betriebsgarantie für fremde Systeme.

Ein Versionssprung ohne Wegweiser

Die README beschreibt einen Java-Client für den PAI Authentication Web Service von LACNIC. Unter den Voraussetzungen steht „Java 8 or later“. Die Beispiele für Maven und Gradle verwenden 1.0.0 und weisen ausdrücklich darauf hin, diese Zahl durch eine auf JitPack veröffentlichte Version zu ersetzen. Direkt darüber zeigt das JitPack-Abzeichen mittlerweile 1.5.1 an. Wer der Anleitung folgt, kombiniert daher plausibel die allgemeine Mindestanforderung mit dem derzeit beworbenen Release. Ein Hinweis auf einen inzwischen höheren Laufzeitsockel begegnet ihm dabei nicht. Repository des LACNIC-Clients README bei Version 1.5.1 Projektseite bei JitPack

Das eigentliche Paket antwortet präziser. Über die direkten JitPack-Adressen ließen sich das POM und ein 20.580 Byte großes JAR der Version 1.5.1 abrufen. Das Archiv enthält zwölf .class-Dateien. Jede weist im Kopf den Wert 61 für major_version aus. Im Manifest steht außerdem Build-Jdk: 17.0.12. Die Zuordnungstabelle der Java Virtual Machine Specification verbindet Major 52 mit Java SE 8 und Major 61 mit Java SE 17. Die ausgelieferten Bytes lassen den erforderlichen Klassendateistand nicht offen. JitPack-POM für 1.5.1 JitPack-JAR für 1.5.1 JVM-Spezifikation zum Klassendateiformat

Damit ist weder ein konkreter Fehlversuch auf Java 8 noch ein Ausfall des PAI-Dienstes belegt. Es gibt keinen Nachweis für eine gescheiterte Anmeldung, eine beschädigte Produktionsintegration, eine Sicherheitslücke oder ein fehlendes Artefakt. Belegt ist nur die engere Abweichung: Die allgemeine Laufzeitangabe auf der Projektseite beschreibt das aktuell angebotene JAR nicht mehr.

Java 17 kann die richtige Entscheidung sein

Die stärkste Verteidigung des Releases beginnt nicht mit der Dokumentation, sondern mit der Wartbarkeit. Java 17 ist ein lang unterstützter, moderner Sockel. Eine Authentifizierungsbibliothek auf diesem Stand zu pflegen kann veraltete Werkzeuge vermeiden, Abhängigkeiten vereinfachen und spätere Sicherheitsarbeit erleichtern. Eine Bibliothek muss nicht auf Dauer jede Umgebung unterstützen, die bei ihrer ersten Veröffentlichung aktuell war. Das Anheben der Mindestversion kann umsichtig sein.

Die jüngsten technischen Unterlagen passen zudem sauber zusammen. Im POM des Tags 1.5.1 stehen java.version, maven.compiler.source und maven.compiler.target jeweils auf 17. Der zugehörige GitHub-Actions-Workflow installiert Zulu JDK 17 und führt die Maven-Prüfung aus. Das Ergebnis sind Klassendateien der Stufe 61. Build-Konfiguration, CI-Umgebung und ausgeliefertes Artefakt widersprechen einander nicht. POM bei Version 1.5.1 Build-Workflow bei Version 1.5.1

Auch die alte Versionsnummer in den Beispielen ist nicht ohne Kontext falsch. Der Kommentar fordert gerade dazu auf, ein publiziertes Release einzusetzen. Das POM von 1.0.0 setzt Quelle und Ziel auf 1.8. Für diesen Ausgangspunkt war die README zutreffend. POM bei Version 1.0.0

Doch genau die Aufforderung zum Ersetzen der Versionsnummer macht eine Zuordnung nötig. Sie führt Nutzer von einem Beispiel zu einem anderen Release. Wenn spätere Releases einen neuen Bytecode-Sockel haben, reicht eine globale Mindestanforderung nicht mehr. Der berechtigte technische Wechsel braucht einen sichtbaren Wegweiser.

Was sich zwischen 1.4.0 und 1.5.0 änderte

Die Versionsgeschichte sollte dabei nicht nachträglich geglättet werden. In 1.0.0 sind Java-Eigenschaft sowie Compiler-Quelle und -Ziel auf 1.8 gesetzt. Von 1.1.0 bis 1.4.0 bleiben die expliziten Werte für Quelle und Ziel bei 1.8, obwohl der öffentliche Workflow bereits JDK 17 nutzt. In diesen Zwischenversionen steht java.version im POM sogar doppelt—zunächst 1.8, später 17. Wer alle Metadaten als durchgehend eindeutig schildert, würde diesen Befund unterschlagen. Maßgeblich für die beabsichtigte Klassendateistufe bleiben dort die ausdrücklichen Source- und Target-Werte.

Der klare Bruch folgt mit 1.5.0: Java-Eigenschaft, Source und Target wechseln geschlossen auf 17. Das POM von 1.5.1 übernimmt die Einstellung. Die Feststellung beruht auf dem Vergleich fester Release-Tags, nicht auf einer Vermutung über den Entwicklungszweig. POM bei Version 1.4.0 POM bei Version 1.5.0

Die Prosa vollzieht diesen Wechsel nicht nach. Für die README zeigt GitHub nur einen Commit vom 1. November 2024. Ihre geprüften Bytes sind in den Tags 1.0.0 bis 1.5.1 und im heutigen Hauptzweig identisch. Version 1.5.0 erschien laut GitHub am 29. Oktober 2025, Version 1.5.1 am 14. April 2026. Beide Release-Beschreibungen sind leer; auch dort steht keine Laufzeitnotiz. Commit-Verlauf der README Release-Übersicht Release 1.5.1

Dokumentationsdrift beginnt oft genau so: nicht als Störung, sondern als zeitliche Trennung zweier ursprünglich richtiger Aussagen. Die Einführung erklärt weiterhin das erste Release; die neueste Binärdatei hat längst eine andere Schwelle.

Sechs verschiedene Beweisstücke

Die README einfach als falsch zu bezeichnen, wäre zwar knapp, aber betrieblich wenig hilfreich. Sechs Dinge müssen getrennt bleiben: die allgemeine Dokumentationszusage, die konkrete Version im Abhängigkeitsbeispiel, die Release-Identität aus Tag und Commit, das Build-JDK, das Ziel der ausgelieferten Klassendateien und der Umfang der Kompatibilität mit dem PAI-Dienst beziehungsweise seiner API.

Diese Angaben beantworten unterschiedliche Fragen. Ein Build auf JDK 17 muss nicht zwangsläufig Java-17-Bytecode erzeugen; ein neuer Compiler kann ältere Ziele ausgeben. Maven trennt deshalb source und target und weist darauf hin, dass eine Zielstufe allein noch keine vollständige API-Verträglichkeit sicherstellt. Erst der Blick in das JAR schließt hier die entscheidende Lücke. Umgekehrt beweist Major 61 zwar die Bytecode-Generation, aber nicht, gegen welche PAI-Serverstände getestet wurde oder ob bestimmte Zugangsdaten funktionieren. Maven-Anleitung zu Source und Target

Ebenso wenig belegt eine GitHub-Release-Seite ohne angehängte Dateien, dass es keine Distribution gibt. Das Repository verweist auf JitPack, und dort lassen sich die Artefakte direkt abrufen. Eine JitPack-Build-Abfrage liefert zwar die merkwürdige Kombination aus Status ok, Text „Not found“ und fehlender Build-URL. Für die Verfügbarkeitsfrage sind jedoch das erfolgreich geladene POM und JAR entscheidend. Aus einer widersprüchlichen Metadatenantwort sollte keine Ausfallgeschichte werden.

Mit der Trennung werden auch die Zuständigkeiten sichtbar. LACNIC kontrolliert Repository, Tags und eigene Dokumentation. GitHub bewahrt Entwicklungs- und Release-Datensätze. JitPack baut und verteilt aus einem öffentlichen Tag ein Maven-Artefakt. Die JVM-Spezifikation definiert dessen technische Lesbarkeit. Der Integrator wählt Laufzeit, Bibliotheksversion und Einsatzbedingungen. Keines dieser Systeme kann die Aussage aller anderen ersetzen.

Vor der Anmeldung liegt das Laden

Weil die Bibliothek der Authentifizierung dient, wäre es leicht, den Befund in Richtung eines Sicherheits- oder Verfügbarkeitsurteils zu überdehnen. Dafür gibt es keine Grundlage. Die untersuchten Quellen zeigen weder abgeflossene Zugangsdaten noch Umgehung, Exploit, abgewiesene Anmeldung oder Serviceausfall. Aus dem Bytecode des Clients folgt auch nichts über die Laufzeit des PAI-Servers. Scheitert das Laden auf einer alten JVM, ist noch keine Anfrage an den entfernten Dienst erfolgt.

Für einen Betreiber ist die Reihenfolge deshalb wichtig. Zuerst muss das gewählte Artefakt in die eigene Laufzeit passen. Danach folgen getrennte Prüfungen für API-Stand, Konfiguration, Zugangsdaten, Netzpfad, Antwortverarbeitung und Anwendungssitzung. Ein Kompatibilitätsnachweis beantwortet die erste Frage. Er ist weder ein Zertifikat für den Rest noch ein Urteil über eine reale Installation.

Diese Begrenzung hält die Analyse auch von benachbarten Kontrollfragen fern. Es geht nicht um Signaturen oder Schlüsselgewahrsam, nicht um einen reproduzierbaren Build, nicht um die Identität eines installierten Binärpakets oder dessen Bindung an einen laufenden Dienst und nicht um die Aktivierung einer Funktion. Hier fehlt nur der belastbare Join zwischen Release-Version und Laufzeitboden.

Der kleinste sinnvolle Nachweis

Für diese Reparatur braucht LACNIC kein umfangreiches neues Verfahren. Ein kurzer Kompatibilitätsdatensatz je Release würde genügen. Er sollte Projekt, Tag und exakten Commit nennen; Maven-Gruppe, Artefakt und Version; Klassendateiziel und Build-JDK; minimale unterstützte sowie tatsächlich getestete Laufzeiten. Hinzu kommen der vorgesehene PAI-Dienst- oder API-Umfang, die passende Dokumentationsrevision, wesentliche Laufzeit- oder Abhängigkeitsänderungen und ein Support- oder Auslaufzeitraum. Ein Hash kann den Datensatz an das geprüfte Artefakt binden; ein Korrektur- oder Ablöseverweis erhält die Geschichte.

Der Nachweis muss seine Grenzen mitführen. „Mit JDK 17 gebaut“ ist nicht gleich „benötigt Java 17“. „Klassendateiziel 17“ garantiert nicht jede API-Nutzung unter jeder Installation. „Auf 17 und 21 getestet“ gilt nicht automatisch für alle Anbieter und künftigen Updates. „Mit PAI-API X kompatibel“ beweist keine erfolgreiche Anmeldung in einem Kundennetz.

Die meisten Bausteine liegen bereits offen vor. Das POM nennt Version und Ziel, der Workflow die Build-Laufzeit, der Tag den Commit, JitPack das ausgelieferte Paket. Es fehlt weniger an Fakten als an ihrer gemeinsamen Veröffentlichung. Ohne sie muss jeder Nutzer dieselbe kleine Forensik auf fünf Oberflächen wiederholen.

Der Laufzeitboden ist eine Governance-Angabe

Ein Authentifizierungsclient für eine Registry liegt zwischen institutioneller Infrastruktur und lokaler Automatisierung. Ein Laufzeitsprung beeinflusst, wer ein Release einsetzen kann, wie schnell eine wichtige Aktualisierung weitergegeben wird und ob zuvor eine interne Plattformmigration nötig ist. LACNIC entscheidet diese lokalen Fragen nicht. Sie entscheidet aber, mit welcher öffentlichen Information sie beginnen.

Eine versionierte Aussage schafft auf beiden Seiten Spielraum. LACNIC kann den Sockel anheben, ohne versehentlich alte Kompatibilität zu versprechen. Ein Integrator kann bewusst bei einer älteren Linie bleiben, eine Migration einplanen oder eine neue Version vor der Übernahme testen. Auch Supportgespräche beginnen dann nicht mehr mit der Auslegung eines Satzes, der rund anderthalb Jahre vor dem jüngsten Release geschrieben wurde.

Die Lösung lautet nicht, jedes Release auf Java 8 festzuhalten. Jedes Release soll seinen eigenen Tauschwert benennen: Welche Modernisierung verlangt es, und welche Unterstützung bietet es dafür? Software darf weiterziehen. Ihre Kompatibilitätszusage muss mitkommen.

Quellen

  1. LACNIC: Repository des PAI Authentication Web Service Client
  2. LACNIC: README bei Release 1.5.1
  3. LACNIC: POM bei Release 1.0.0
  4. LACNIC: POM bei Release 1.4.0
  5. LACNIC: POM bei Release 1.5.0
  6. LACNIC: POM bei Release 1.5.1
  7. LACNIC: Build-Workflow bei Release 1.5.1
  8. LACNIC: GitHub-Release-Übersicht
  9. LACNIC: Release 1.5.1
  10. LACNIC: Commit-Verlauf der README
  11. JitPack: Projektseite des LACNIC-PAI-Clients
  12. JitPack: generiertes POM für Version 1.5.1
  13. JitPack: JAR der Version 1.5.1
  14. Oracle: Java Virtual Machine Specification zum Klassendateiformat
  15. Apache Maven: Compiler-Quelle und -Ziel einstellen