Vlákno názorů k článku
Chyba v Log4j je ve velkém hledána a zneužívána útočníky od Filip Jirsák - Naštěstí to není zabudováno do každého projektu v...

Naštěstí to není zabudováno do každého projektu v Javě. V Javě se častěji používá knihovna Logback (má dvojnásobný podíl oproti Log4j 2), dokonce i původní (nepodporovaná ale touto chybou nepostižená) Log4j 1.x se používá zhruba stejně často. Vedle toho existují různé méně používané knihovny. (Počty užití vycházejí ze statistik na javalibs.com.)

To se mi nějak nezdálo, v mojí java dev bublině je log4j vždy první volba i když logback má reputaci výkonější library.

A nevim jestli na charts na javalibs.com nekoukam špatně, ale v počtu použití log4j v1 jasně vede (takže appky jsou chráněny svym technickym dluhem :) migrace na v2 nejde udělat jen jednoduchym updatem jarek, takže se stále dost používá), pak je log4j v2 a až třetí je logback

16. 12. 2021, 12:45 editováno autorem komentáře

U Logbacku má smysl dívat se na logback-classic, to je aplikační logování. Závislost na logback-core má v sobě, takže aplikace ji získávají tranzitivně – je přirozené, že ji přímo uvedenou nemají. Spíš je zvláštní, proč tolik projektů závisí přímo na logback-core. Dává to smysl, když někdo implementuje vlastní appendery, filtry apod., ale že by to bylo tak časté?

Podla http://slf4j.org/log4shell.html ma aj log4j-1.x chyby ktore by nebolo dobre ignorovat.

kromě jiného log4j 1 obsahuje zranitelnost CVE-2019-17571, to jsme řešili odebráním tříd SocketServer a JMSAppender z jarek, podobně jako se to řeší teď. Stejně tak jsou ošetřeny i balíčky např. pro Kafku nebo Zookeeper.

To co píšou na http://slf4j.org/log4shell.html je závislé na JMSAppender, to je třída, která se ne tak často používá a je nutné, aby byla v konfiguraci využita, jinak zranitelnost není jak využít.