Moin zusammen,
nachdem sich hier bislang in erster Linie Anwender und Admins geäußert haben, hier einmal die Entwickler-Perspektive.
Wir entwickeln eine große Java-Anwenung, wir haben eine vierstellige Zahl an Kunden, mit 6-7stellig Anwendern dahinter. Die von uns selbst entwickelte Software war von dem Problem nicht betroffen und ich behaupte mal ganz arrogant, dass das kein Zufall ist, sondern verantwortungsbewusstes Handeln.
Man muss dazu wissen, dass es in Java einen Zoo von Log-Frameworks gibt. Die größten sind
- log4j (1) (jau, das alte Log4J hat immernoch extreme Relevanz)
- logback
- apache.commons.logging
- java.util.logging
und eben das betroffene log4j-2
Wenn man seine Anwendung mit Open-Source-Drittkomponenten entwickelt (ich glaube, es geht gar nicht mehr ohne), dann kommt man nicht dran vorbei, dass man einen Zoo von den Teilen in seinem Abhängigkeitsbaum stehen hat. Das
kann man dann aufräumen, oder eben nicht.
Wir haben bei uns vor 6 oder 7 Jahren einmal ordentlich aufgeräumt (das war meine Aufgabe) und dabei war dann die Frage, wie geht man mit dem Zoo um. Glücklicherweise gibt es seit langem eine Abstraktionsschicht, die nach oben jedes der genannten Logsysteme emuliert und nach unten eine beliebige Implementierung zulässt - nennt sich SLF4J (Standard Logging Facade for Java).
Klar war, dass man sowas braucht, wenn man auch nur ein Minimum an Kontrolle haben will, was in der eigenen Software los ist (Worst case: man muss ohne Slf4j jedes der Logsysteme individuell in eigenen Mechanismen konfigurieren und jeder Teil der Anwendung schreibt in eine eigene Logdatei). Weniger klar war, was man drunter schraubt.
Im Prinzip gibts zwei relevante Optionen. Log4j (2) oder Logback. Da kann man jetzt einfach mal Google anschauen (und stellte damals fest, dass log4j weiter verbreitet ist) oder man recherchiert ordentlich. Tut man das, findet man raus, dass log4j-2 ein typisches Mimimi-Apache Projekt ist, weil sie sauer waren, dass der Hauptentwickler von log4j-1 sein eigenes Ding mit Logback gemacht hat und die Leute scharenweise abgewandert sind. Deswegen habe die Jungs von log4j dann ganz schnell ein wir-auch-Produkt auf den Markt geworfen und sinnlose Nicht-features eingebaut, in der Hoffnung, den Exodus zu stoppen.
Für mich ist das Fehlerbild "erlaube das Parsen von Logmeldungen auf JNDI-URLs" genau so ein Nicht-Feature, das sich wie ne gute Idee anhört, bis man sich überlegt, ob man sowas wirklich braucht und dann sehr schnell zu dem Ergebnis kommt, nein. Für mich passt das perfekt zu dem Eindruck, den ich damals gewonnen habe, als ich für unsere Firma entschieden habe nicht zu log4j-2 zu gehen, sondern zu logback.
Stand heute kennt das Maven Repository ungefähr 3 mal so viele Bibliotheken die logback benutzen als log4j-2 und noch immer mehr als doppelt so viele Nutzer von log4j-1 als log4j-2. Ich denke, die Behauptung ist fair, dass man das durchaus hätte erahnen können, Und tatsächlich: keines der großen Frameworks, die wir nutzen, setzt native auf log4j-2: Wildfly nicht, Spring nicht und nichtmal Tomcat (der wiederum von Apache kommt).
Ich finde übrigens den Fehler selber nicht besonders schlimm. Sowas kann passieren. Was ich aber ne Katastrophe finde ist, dass es offensichtlich ein responsible-disclosure Verfahren war (Problembeschreibung und Lösung kam am gleichen Tag) und trotzdem haben sie es nicht geschafft, das Problem im ersten Anlauf zu lösen sondern mussten im Nachgang eine Rolle zurück machen und sowohl ne neue Version ausliefern als auch die Aussage zurücknehmen, dass die Mitigation funktioniert.
Das ist mal unprofessionell.
