Logging ist die Kunst, ein System zu verstehen.
Software protokolliert was gerade passiert in Log-Dateien, und Entwickler durchsuchen sie in der Hoffnung, das zu finden, was sie brauchen. Das Problem dabei? Systeme protokollieren selten die richtigen Dinge. Doch ohne diese Dateien würden wir im Blindflug fliegen, ohne zu wissen, dass überhaupt etwas schiefgelaufen ist.
Dies ist die Geschichte von Apache Log4j – eines der ältesten Java-Frameworks, das heute noch verwendet wird. Ein Tool, das Entwicklern die Möglichkeit gab, ihre Systeme zu verstehen.
Log4j ist ein europäisches Projekt
Alles begann Mitte der 1990er-Jahre, als die Europäische Union (EU) noch in den Kinderschuhen steckte. Das SEMPER Projekt war eine frühe EU-Initiative zum Aufbau eines „sicheren Instrumentariums für den elektronischen Geschäftsverkehr“. Es begann im September 1995, endete drei Jahre später und wurde mit rund 10 Millionen Euro finanziert. Damals war dies eine enorme Investition. Nicht nur wegen des Betrags, sondern auch, weil viele bezweifelten, dass das Internet selbst überleben würde, geschweige denn der elektronische Handel. Es wurden Prototypen gebaut und getestet, und am Ende war SEMPER Geschichte – und hatte Geschichte geschrieben. Heute wird oft beklagt, die EU sei unflexibel. Aber 1995 war SEMPER der Beweis dafür, dass die EU innovativ sein kann.
Im Jahr 1996 stellten Ceki Gülcü, N. Asokan und Michael Steiner die Idee der „hierarchischen Kategorien“ vor. Damals war dies eine bahnbrechende Idee. Wie alle guten Programmierwitze war auch Logging damals streng binär: „ein“ oder ‚aus‘. Es gab keine Möglichkeit, nur datenbankbezogene Ereignisse zu protokollieren oder Benutzeraktivitäten zu verfolgen.
Hierarchien änderten alles. Entwickler konnten nun Logging auf Paketebene aktivieren, wobei untergeordnete Pakete automatisch die Einstellungen ihrer Eltern übernahmen. Das SEMPER-Projekt finanzierte die erste Version von Log4j und erkannte die Bedeutung des Loggings für die Beobachtbarkeit des Systems.
Der Weg zu Open Source
Nach dem Ende von SEMPER brachte Ceki Gülcü das Paket in das IBM-Forschungslabor in Zürich, wo er die Entwicklung fortsetzte. 1998 oder 1999 hatte Log4j dort ein neues Zuhause gefunden. Das Projekt hätte in der Versenkung verschwinden können, aber IBM Zürich hielt es am Leben. Frühe Aufzeichnungen zeigen, dass Log4j zuerst durch IBMs alphaWorks Initiative verbreitet wurde. IBM nutzte alphaWorks, um aufstrebende Technologien zu fördern, und Log4j passte perfekt zu dieser Vision.
Moment, Moment, aufstrebende Technologien? Vergessen wir nicht, dass Java nur ein paar Jahre zuvor (1995) als Betaversion auf den Markt kam und nur ein Jahr später die Version 1.0 erreichte. Log4j wurde zusammen mit J2SE 1.2 (1998) und 1.3 (2000) entwickelt. Java 1.2 brachte uns das Collections-Framework, und 1.3 folgte mit JNDI. In der Ära von Lambdas würde die Arbeit mit Java 1.2 die meisten von uns zur Holzbearbeitung treiben. Diese Upgrades machten die Java-Entwicklung massiv einfacher.
Als das neue Jahrtausend anbrach, beobachteten viele den Himmel in Angst und fragten sich, ob Y2K Flugzeuge zum Absturz bringen würde. Währenddessen nahm die Zukunft von Log4j Gestalt an. Herr Gülcü verlegte Log4j zu SourceForge, nutzte die Vorteile der öffentlichen Infrastruktur und registrierte log4j.org. Die Domain sollten Sie jetzt aber nicht unbedingt in Ihren Browser eintippen–es führt heute zu einigen seltsamen Orten.
Community over code
Open Source bedeutet heute etwas anderes als in der Vergangenheit. Heute wird Open Source oft als Geschäftsmodell betrachtet. Wir machen uns Gedanken über die Finanzierung, verwaiste Projekte und Unternehmen, die ihren einst offenen Code zurückfordern. Open Source nimmt heute viele Formen an, aber damals war es ganz einfach.
Geld war nicht die treibende Kraft.
Open Source war wie Punk – teils politisches Statement, teils Rebellion, eine Bewegung für Softwarefreiheit.
Ich erinnere mich an ein Gespräch mit dem CEO eines Unternehmens, als ich noch recht jung war. Er erklärte mir, wie sehr er freie Software verabscheue. Seiner Meinung nach würde sie ihn Geld kosten, weil Menschen ihre Arbeit kostenlos weitergäben. Ich war sprachlos. Wie sollte ein kleines Unternehmen ein Betriebssystem wie Linux entwickeln? Oder Support für Datenbank- und Webserver leisten? Er meinte, sie würden es tun – aber gegen Bezahlung. Auch afrikanische Krankenhäuser, kleine Firmen und gemeinnützige Organisationen sollten zur Kasse gebeten werden. Ich war erschüttert. Ohne Open Source wären nur große Konzerne in der Lage, Software-Innovation voranzutreiben. Open Source macht die Welt zu einem besseren und gerechteren Ort.
Auch heute noch geht der Kampf für Softwarefreiheit weiter, wenn auch in unterschiedlichen Formen. Aber Freiheit bringt auch Herausforderungen mit sich – Herausforderungen, die den Weg von Log4j bestimmten.
Die Free Software Foundation (FSF) war eine der stärksten Stimmen der frühen Open-Source-Bewegung. Viele Open-Source-Projekte fanden ein Zuhause bei der FSF, und Log4j hätte eines von ihnen sein können. Aber es gab ein paar Gründe, warum dies nie geschah:
Das größte Hindernis war die Lizenzierung: Die GPL der FSF funktionierte gut für C und C++, machte aber Probleme mit Java. Da Java Bibliotheken dynamisch lädt, geriet es in Konflikt mit den strengen Linking-Regeln der GPL.
Ein weiterer wahrscheinlicher Grund war vielleicht, dass Log4j schon früh Ant zum Bauen seiner Software eingesetzt hatte. Irgendwann wandte sich der Betreuer von Log4j an die Apache Software Foundation (ASF), eine wachsende Gemeinschaft, die Java-Projekte unterstützt. Die freizügige Lizenz der ASF förderte eine breite Akzeptanz und war auch für Java-Software geeignet.
Warum also sollte Log4j nicht der ASF beitreten, wo Ant bereits zu Hause war?
Log4j trat der ASF bei und wurde Teil des Apache Jakarta-Projekts. Ja, Apache Jakarta – derselbe Name, den man heute von der Eclipse Foundation kennt, die Java Enterprise Standards entwickelt. Im Jahr 2000 war Apache Jakarta zu einem Dachprojekt geworden, das fünf große Java-bezogene Projekte beherbergte, darunter Apache Ant und Apache Tomcat.
In der Zwischenzeit, im Jahr 2001, wurde Apache Commons Logging vorgeschlagen. Ziel war es, eine einfache API bereitzustellen, die sowohl mit JDK Logging als auch mit Log4j kompatibel ist. Außerdem wurde ein Plugin-System eingeführt, die die nahtlose Integration anderer Logging-Frameworks ermöglicht.
Commons Logging zielte darauf ab, das Logging unter einer einzigen Schnittstelle zu vereinheitlichen und sich selbst als Standard zu positionieren.
Die Zeit von Log4j bei Jakarta war kurz. Im Jahr 2003 wurde es unter dem Namen „Logging Services“ zu einem Top-Level-Projekt befördert. Bis dahin hatte Log4j eine kleine Gemeinschaft von sechs Mitwirkenden aufgebaut.
Die Entwicklung von einem Einzelprojekt zu einer echten Gemeinschaft ist selten einfach. Als sich Log4j weiterentwickelte, beauftragte das ASF-Board das Projekt außerdem mit der Integration von Schwester-Projekten wie Log4net und Log4php.
Die Zukunft sah rosig aus – zumindest für eine Weile.
Doch im Jahr 2005 brachten technische Streitigkeiten und persönliche Konflikte die Entwicklung zum Stillstand. Der Schwung ließ nach, und die Gemeinschaft hatte Mühe, sich zusammenzureißen. Schließlich zog sich der Gründer von Log4j zurück und gründete 2006 Logback und Slf4j.
Code ohne Community
Man hätte meinen können, dass die Trennung Frieden und Stabilität für Log4j bringen würde. Aber lange Streitigkeiten heilen nicht schnell, und Log4j hatte keine klare Vision. Die Community war erschöpft, und der Fortschritt kam zum Stillstand. Neue Versionen wurden nur sporadisch veröffentlicht.
So kam Version 1.2.15 im Jahr 2007 heraus. Der nächste Bugfix, 1.2.16, ließ weitere drei Jahre auf sich warten. Sogar Schwesterprojekte wie Log4php wurden zurückgefahren und schließlich eingestellt.
Es war eine düstere Zeit, in der es keine Anzeichen für Veränderungen gab. Log4j geriet ins Hintertreffen und drohte in Vergessenheit zu geraten.
Comeback
Im Jahr 2009 stieg ich in einer entscheidenden Phase in das Projekt ein. Für meine berufliche Arbeit war ich auf Log4php angewiesen – doch das Projekt war in einem desolaten Zustand. Also begann ich, es zu patchen – die erste nennenswerte Weiterentwicklung seit Jahren.
Kurz darauf engagierte sich Ralph Goers, um die Idee von Log4j 2 entwickeln. Zufällig ergänzten sich unsere Bemühungen, und das Projekt gewann wieder an Dynamik. Die Community erwachte zu neuem Leben, der Enthusiasmus wuchs – und mit ihm die Zahl der Mitwirkenden.
Die neuen Entwickler brachten eine frische, unvoreingenommene Perspektive in die alternde Log4j 1-Codebasis ein. Während Logback sich als Nachfolger positionierte, wurde Log4j 2 entwickelt, um aus den Fehlern der Vergangenheit zu lernen.
Es war eine komplette Neufassung. Die Apache Logging Services hätten ohne diesen Neuanfang wohl nicht überlebt.
Weltweit trugen Entwickler zur Weiterentwicklung von Log4j 2 bei und formten daraus ein lebendiges, community-getriebenes Projekt. Sein offener, gemeinschaftsorientierter Ansatz ermutigte Patches und Feedback beizusteuern.
Mit der Zeit wurde klar, dass Log4j 2 die Zukunft des Java-Logging ist und die Zeit von Log4j 1 vorbei war.
Im Jahr 2015 erreichte Log4j 1 offiziell sein Lebensende. Die Entwicklung wurde eingestellt, und der Schwerpunkt verlagerte sich auf Log4j 2. Das neue Team war überzeugt, dass die Lösung produktionsreif sei – und das war sie auch.
Positive Rückmeldungen förderten die Akzeptanz und zogen weitere Entwickler an. Zu den wichtigsten Beiträgen gehörten die asynchrone Protokollierung und der LMAX-Disruptor, der Log4j 2 wahnsinnig schnell machte.
Die Dinge sahen wieder gut aus – aber nicht jeder begrüßte die neue Logging-Landschaft.
Die Entwickler hatten nun die Wahl zwischen JUL, Slf4j, Logback und Commons Logging. Darüber hinaus existierten sowohl Log4j 1 als auch sein Nachfolger Log4j 2 nebeneinander.
Die Entwickler mussten sich für ein Framework entscheiden und “Brücken” konfigurieren, um verschiedene APIs zu verbinden. Bei Log4j 2 handelte es sich nicht nur um ein Produkt, sondern um zwei, die zusammen verpackt waren. Wie Slf4j und Logback kombinierte es eine API und eine Implementierung. Das wurde nur nie so kommuniziert.
Dunkle Tage: Log4shell
Im Juli 2013, etwa ein Jahr vor der ersten stabilen Version von Log4j 2, steuerte ein Entwickler die Funktion 313 bei, die JNDI-Unterstützung ermöglicht. Mit dieser Funktion wurde JNDI in Log4j 2 integriert.
Es wurde ohne zu zögern vom Log4j Team angenommen. Da JNDI ein zentrales Java-Feature ist, schien es ein logischer Schritt zu sein, es hinzuzufügen.
Log4j 2 befand sich noch in der Betaphase, so dass nur wenige die Änderung in Frage stellten – oder sie überhaupt bemerkten.
Natürlich haben wir uns mit unserer Arglosigkeit geirrt.
Log4j 2 wurde mit der Funktion 313 ausgeliefert – eine der schwerwiegendsten Sicherheitslücken, die jemals entdeckt wurden.
Die Warnzeichen waren da – wir hätten sie auf der Black Hat 2016, einer großen Sicherheitskonferenz, bemerken können. Aber das haben wir nicht.
Bis Log4Shell an die Öffentlichkeit ging, war mir persönlich Black Hat kein Begriff. Dabei hatten Sicherheitsexperten dort bereits in jenem Jahr detailliert aufgezeigt, wie sich JNDI gezielt ausnutzen lässt.
Dann kam der November 2021.
Wir kommunizierten über E-Mail-Listen, und jedes Projekt hatte seinen eigenen privaten Kanal. Diese Listen sind in der Regel wenig frequentiert und für gelegentliche persönliche Angelegenheiten oder nichtöffentliche Sicherheitsdiskussionen reserviert.
Aber im November 2021 stieg der Verkehr auf der Mailingliste plötzlich sprunghaft an – etwas, das fast nie passierte. Es dauerte nicht lange, bis ich die Worte entdeckte: “Remote Code Execution“.
Mein erster Instinkt? Den E-Mail-Client schließen. Ich sagte mir, dass ich mich jetzt nicht damit befassen könnte.
Eine Stunde später wusste ich, dass ich keine andere Wahl hatte – auch wenn ich zu dem Zeitpunkt nicht aktiv an der Entwicklung beteiligt war. Glücklicherweise war es nicht mein Teil des Codes – andere übernahmen die Führung.
Man kann über das Problem sagen, was man will – das Team von Log4j hat schnell gehandelt und ist verantwortungsvoll damit umgegangen.
Die erste Meldung ging am 24. November 2021 ein.
Ein Entwickler in China entdeckte die Sicherheitslücke. Innerhalb eines Tages bestätigten wir das Problem und erkannten, dass es wichtige Projekte wie Apache Struts, Druid und Flink – und wahrscheinlich unzählige andere – betraf. Nach einigen Tagen der Diskussion hatten wir das Problem bis zum 5. Dezember behoben. Wie üblich hatten wir eine dreitägige Abstimmung über die Veröffentlichung eingeleitet. Trotz der Schwere des Problems blieb das Team zuversichtlich – und erleichtert, als alles funktionierte.
Doch gerade als die Abstimmung über die Freigabe beendet war, geschahen zwei Dinge.
Erstens begannen Sicherheitsgruppen, das Log4j-Problem offen zu diskutieren – in den sozialen Medien und darüber hinaus.
Dann kam der eigentliche Schock: eine E-Mail vom ursprünglichen Reporter.
Der Fix funktionierte nicht.
Ab diesem Zeitpunkt änderte sich alles. Plötzlich war ich mittendrin – ich verbreitete Informationen und Workaround über das Problem und nahm Anrufe von Unternehmen entgegen. Panik machte sich breit, und wir taten alles, um eine neue Version herauszubringen. Am 9. Dezember erstellten wir eine neue Version und verkürzten die übliche Wartezeit von drei Tagen auf nur einen Tag.
Log4j 2.15 wurde veröffentlicht.
Aber der Alptraum war noch nicht vorbei.
Weitere Schwachstellen tauchten auf, und wir flickten sie, eine nach der anderen.
Inmitten des Chaos erhielten einige von uns E-Mails voller Wut und Schuldzuweisungen. In den Foren entlud sich die Frustration. Im Nachhinein betrachtet hatte eine Handvoll engagierter Leute unermüdlich daran gearbeitet, das Problem zu beheben und wurden dafür beschimpft.
Keiner von uns wurde für diese Arbeit bezahlt. Einige nahmen sich sogar Tage frei und opferten ihren Urlaub.
Das war unser Problem, kein Zweifel. Aber wir haben das sinkende Schiff nicht aufgegeben – wir haben dafür gekämpft, es über Wasser zu halten.
Ich denke oft an diese Zeit zurück und daran, was sie mich gelehrt hat: Dass dieses Projekt nie nur aus einer oder zwei Personen bestand, sondern aus einem Team. Mit einem starken Team und engagierten Leuten haben wir es geschafft!
Aftermath
Nach der Korrektur wurde Open Source auf eine neue Art und Weise betrachtet. Regierungen und große Zeitungen griffen die Geschichte auf und entfachten eine Diskussion über die Nachhaltigkeit von Open Source.
Jahrzehntelang arbeiteten die Entwickler kostenlos und stellten ihre Arbeit dem Gemeinwohl zur Verfügung, während die Unternehmen davon profitierten.
Und dann flog die Grundlage der Firmen und ihres Profits in die Luft.
Und wieder meldeten sich dieselben wenigen Leute, um das Problem zu lösen.
Unbezahlt.
Vor zwanzig Jahren spielten Programmierung und Software noch eine ganz andere Rolle in unserem Leben. Damals gab es noch nicht einmal Smartphones. Aber heute benutzen wir sie, um Rechnungen zu zahlen. Ihr Auto ist heute mehr Computer als Maschine. Fast jedes Gerät in Ihrem Haushalt ist heute ein winziger Computer–sogar Ihr Wasserkocher ist vielleicht mit dem Wi-Fi verbunden.
Zum Glück beginnt sich etwas zu ändern. Es ist noch lange nicht alles perfekt, aber Organisationen wie die Sovereign Tech Agency (STA) setzen sich für die Nachhaltigkeit von Open Source ein.
In den Jahren 2023 und 2024 erhielt das Log4j-Team Fördermittel, die wir gerne angenommen haben. Nun, zumindest ein Teil des Teams.
Ich habe schnell gelernt, dass die Finanzierung von Entwicklern nicht so einfach ist, wie es klingt. Einige konnten aufgrund von arbeitsvertraglichen Einschränkungen nicht zusagen. Bei anderen gab es steuerliche Komplikationen. Und einige hatten keine Zeit für ein großes Projekt mit begrenzten Mitteln und ungewisser beruflicher Zukunft.
Trotzdem: drei Personen arbeiteten 1,5 Jahre lang Vollzeit an Log4j. Wir haben Sicherheitsfunktionen wie SBOM hinzugefügt, Bereinigungen vorgenommen und die Dokumentation und die Website verbessert. Außerdem haben wir es möglich gemacht, Log4j mit Graal VM zu verwenden und es auf Android laufen zu lassen. Wir haben viel gelernt, und Log4j ist trotz der Krise, in der es steckte, gewachsen.
Takeaways
Was wäre, wenn wir nur zu zweit wären?
Was wäre, wenn wir zu dieser Zeit im Urlaub wären?
Was wäre, wenn es uns egal wäre?
Log4j hätte viele Male aufgegeben werden können, aber es hat überlebt. Manchmal war es Glück, und manchmal waren es die richtigen Leute zur richtigen Zeit.
Was habe ich gelernt?
Software-Ingenieure müssen Sicherheit ernster nehmen. Sicherheit wird eine der größten Herausforderungen für die Zukunft der Software sein. KI wird Angreifern helfen, Schwachstellen schneller zu entdecken, und wir müssen wachsam bleiben. Da sich die Bedrohungen weiterentwickeln, müssen wir immer einen Schritt voraus sein.
Überlegen Sie mal: Log4Shell wurde im Jahr 2013 eingeführt – und blieb bis 2021 unentdeckt. Wir können nicht wissen, ob es nicht schon vorher ausgenutzt wurde.
Die Gemeinschaft ist das Rückgrat der Softwareentwicklung. Weit verbreitete Projekte können nicht allein gewartet werden – wir brauchen ein zuverlässiges Team.
Open Source hat ein Nachhaltigkeitsproblem. Tech-Giganten profitieren von Open Source, doch ohne sie würde die Innovation zum Erliegen kommen.
Open Source ist überall. Lassen Sie uns dafür sorgen, dass es eine nachhaltige Zukunft hat.
Zukunft
Was bedeutet das für Log4j heute?
Aufgrund von Log4Shell wurde kein anderes Logging-Framework so gründlich getestet. Das Team hat seine Verantwortung und sein Engagement für die Sicherheit unter Beweis gestellt. Ja, es ist „sicher“. Niemand kann das nächste Log4Shell vorhersagen, aber wir haben unsere Sicherheit verbessert und eine sauberere, robustere Codebasis geschaffen.
Zusammenarbeit ist alles. Einige von uns hoffen, eines Tages unter einer gemeinsamen Logging-API zu arbeiten, die im Rahmen des Eclipse Jakarta-Projekts gehostet wird.
Bis es so weit ist, freuen wir uns auf weitere 20 Jahre Logging. Und wer weiß? Vielleicht schreibe ich in zwanzig Jahren einen weiteren Artikel wie diesen. Geschichte wird immer noch jeden Tag geschrieben.
Sie können ein Teil davon sein. Hinterlassen Sie Ihre Spur – Ihr nächster Commit wartet schon.
