коллеги, вопрос

заюзана такая штука:

<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.21</version>
<scope>compile</scope>
</dependency>

под ней зарыт я так понимаю какой то лог4ж 1.2... версии. надо ли ее обновлять вообще? и если да то как?

быстрый гуглеж показал что надо взять что то такое

<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j-impl</artifactId>
<version>2.16.0</version>
<scope>compile</scope>

но тут бяда. умники поназавязывались на модные классы старого лог4ж, которые в новом выпилили! скелетонАппендер и тп.

я правильно понимаю что тут печаль беда и надо это все переписывать под новый сдк?

хотя вроде сказано что 1.х можно забить если никто в конфиг не залезет и жмсаппендер рукой не пропишет.

везде понатыкана аннотация слф4ж от ломбока, я так понимаю она дает вот это вот:

private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(LogExample.class);

но это не собссно сама проблема.
челы выпендрились и написали какой то перехватчик логгинга который вколотили во все тесты чтоб тестировать то что лог выводит.

лол.

это не особо проблема. проблема в том что они заюзали классы сдк которого в 2.16 уже нет.

пока нашел тут такое:
http://slf4j.org/log4shell.html

пишут что 1.х не требует и там инжект будет только если жмх-аппендер рукой в конфиге прописать. но имхо, если кто-то имеет не очень санкционированный доступ к конфигу на запись со своего приложения то тут уже не логгер виноват а кое-кто другой.

авторIs log4j 1.x vulnerable?
As log4j 1.x does NOT offer a JNDI look-up mechanism at the message level, it does NOT suffer from CVE-2021-44228.
Given that log4j version 1.x is still very widely deployed, perhaps 10 times more widely than log4j 2.x, we have been receiving a steady stream of questions regarding the vulnerability of log4j version 1.x.

As log4j 1.x does NOT offer a JNDI look up mechanism at the message level, it does NOT suffer from CVE-2021-44228.

However, log4j 1.x comes with JMSAppender which will perform a JNDI lookup if enabled in log4j's configuration file, i.e. log4j.properties or log4j.xml.

я же говорю там кастомный аппендер сделан на лог4ж для тестов. я его не могу выпилить. вернее могу при условии что я эту требуху перепишу.

ну... ок. ты предлагаешь прыгнуть на логбак :) это слишком радикально для них.
с другой стороны.. если дока говорит что не ссать может не ссать? ну как и при каких обстоятельствах кто то может что то записать в конфиг? так тогда этот же чел может взять и прям в коде записать то что надо. это ж не системное администрироваие тут полная свобода

вот такая штука в тестах:

и вот аппендер скелетон это по ходу хрень мало того что напрямую с л4ж берется так еще и древняя как хобот мамонта

так да. я выше это и сказал что если жмхаппендер не вколотить в конфиг лог4ж то ничего и не будет. так сказано в оф.ресурсе.
но тиииипаааа ееееесли вписать это слово в конфиг то твой код перестает быть безопасным (три раза хахахаха).

я вот и не втыкаю при каких условиях можно изменить конфиг и не будет ли это первопричиной того что у тебя в целом система дырявая если несанкционировано кто то может в ней конфиги менять.