meymo schrieb:
Für mich persönlich hat sich log4j damit abgeschaft. So einen fetten Haufen Code brauch ich einfach nicht nur um ein paar Logs zu schreiben und überhaupt die log4j Entwickler scheinen sich ja auch nicht der Securityimplications bewusst zu sein, wenn sie wild im Netzrumfunken, wer weiß was für Perlen es da noch in der lib gibt...
Irgendwie habe ich da gerade ein Dejavu; vor 2-3 Jahren fing bei uns ein Entwicklunggsteam an, Nlog zu nutzen, das ist die .net Entsprechung von log4j. Gleichzeitig war die Idee der Entwickler alles und jedes zu loggen, in der Hoffnung, später beim Kunden, wo man oft nicht debuggen kann, Diagnose Informationen zu bekommen. Logging Systeme wie NLog haben ja umfangreiche Filterfunktionen, da kann man im Normalbetrieb unerwünschte Einträge unterdrücken um ein übermäßiges Logging zu vermeiden.
Soweit so gut. Das erste Problem was wir bekamen, wat dass der Log Thread komplett einen CPU Kern für sich brauchte. Dann haben sich unsere Consultants, die die Software beim Kunden einführen, beschwert das man mit dem Wust an Logginginformationen nichts anfangen konnte, egal welchen Loglevel man einstellte. Entweder hatte man zu wenig oder gleich zu viele Informationen. Die Consultants brauchen verständliche Logging Infos zu gängigen Konfigurationsfehlern, aber nicht „Class xyz instantiated“.
Das rework des Loggingsystems füllte zeitweise mehr als 50% des Backlogs. Was ich damit sagen will: Diese Loggingssysteme verleiten Entwickler dazu, sie extensiv zu nutzen, was natürlich auch zu weiteren Feature Requests führt, was sie weiter aufbläst und, wie man jetzt hier sieht, letztendlich auch dazu führt, das irgendwann was echt „Dummes“ eingebaut wird. Gleichzeitig ist der praktische Nutzwert oft zweifelhaft und die ursprünglich erhoffte Produktivitätssteigerung tritt nicht ein.
Einen ähnlichen Effekt haben wir zur Zeit bei Azure Log Analytics. Wir hatten schon Anwendungen, wo das logging mehr gekostet hat, als der eigentliche Application Service.
Marco01_809 schrieb:
Ganz genau. Auch Unternehmen können sich kostenlos bedienen, aber müssen dann halt auch die Konsequenzen ausbaden wenn sie nicht selber in Audits investieren.
Bei der Menge an Third-Party Bibliotheken, die man heute einsetzt, ist das nur realistisch kaum zu leisten. Mir ist sehr bewusst, dass das ein echtes Problem darstellt. Wie man am vorliegenden Beispiel sieht, hilft auch weite Verbreitung einer Software nichts. Bzw. sie hilft dahingehend, dass das Probleme schon früher oder später von irgendjemandem gefunden werden, und sie dann auch öffentlich werden. In einem Außenseiter Tool kann eine Lücke noch viel länger unentdeckt bleiben.
Nutzt Confluence nicht wie jira eh nur log4j 1.x und ist dann nur verwundbar wenn man nen JMS Appender (was kaum jemand macht) nutzt?
