| |
| 2.47, Аноним (47), 11:41, 19/12/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
Почти всегда DNS-трафик разрешен, т.к. нужен. Пихаешь данные в base64 и отправляешь на свой поддомен, который обслуживает твой DNS сервер.
Как от этого защититься fw? Мне кажется, никак. Тут только какие-то хитрые IPS/IDS с анализом интенсивности трафика или сигнатурами по определенной структуре запросов. Или вы про первичное выкачивание java-класса?
| | |
|
| |
| |
| 3.16, Wilem82 (ok), 02:38, 19/12/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +4 +/– |
 > кто в трезвом уме и здравой памяти будет переводить прод на java 9?
Её поддержка уже один раз чуть не закончилась. Но она таки когда-нибудь закончится. Кому-то это может по-барабану, но большие конторы так не могут - они обязаны соблюдать определённые правила. Например о том, что должна быть поддержка - используемые библиотеки должны официально поддерживаться, то есть для них выпускаются патчи при обнаружении проблем и всё такое.
Плюс сами библиотеки могут заканчивать поддержку старых версий жавы. Мир-то тоже не стоит на месте.
| | |
| |
| 4.119, Тинус Лорвальдс (ok), 18:39, 22/12/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
 >> кто в трезвом уме и здравой памяти будет переводить прод на java 9?
> Её поддержка уже один раз чуть не закончилась. Но она таки когда-нибудь
> закончится. Кому-то это может по-барабану, но большие конторы так не могут
> - они обязаны соблюдать определённые правила. Например о том, что должна
> быть поддержка - используемые библиотеки должны официально поддерживаться, то есть для
> них выпускаются патчи при обнаружении проблем и всё такое.
> Плюс сами библиотеки могут заканчивать поддержку старых версий жавы. Мир-то тоже не
> стоит на месте.
с каких пор поддержка джавы 9 не закончилась? она закончилась с выходом джавы 10.
| | |
|
|
| |
| |
| |
| 5.56, Wilem82 (ok), 15:08, 19/12/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +3 +/– | |
> А вы активно используете Unsafe и прочие вещи JVM, которые лишь для внутреннего использования?
При чём тут "мы"? Этим всем пользуются популярные библиотеки. Перестают они этим пользоваться только в новых версиях, зачастую мажорных, ломающих обратную совместимость. Поэтому переход на J9+ тянет за собой огромные затраты по миграции чуть ли не всех библиотек на новые версии с переписыванием кода, а некоторые библиотеки вообще не имеют версии для J9+, поэтому приходится их выкидывать и переписывать код ранее от них зависящий.
Если у вас новый проект, то вы не "перешли" на J17, т.е. переходить не с чего - проект новый. "Переход" имеет смысл в контексте уже существующего проекта, завязанного на J8, и таких проектов с 20-, 15-, 10-ти летней историей и кучей старого кода - навалом.
| | |
|
| 4.89, Аноним (90), 13:15, 20/12/2021 [^] [^^] [^^^] [ответить] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
Там всего несколько мест на самом деле которые поменялись и могут сломать системы, например поведение Set когда не найден элемент. Если их не использовать активно, то все ок. И если какие-то библиотеки используют module, то придется дать права старому кода на доступ к внутренностям (но это уже болье вина самих библиотек чем приложения). Ну и еще нужно проверить поведение зависимостей. В остальном если не на проекте не увлекались экзотическими функциями, то переход делается сменой номерков с 8 на 11.
| | |
|
|
|
| |
| 2.67, Ordu (ok), 01:22, 20/12/2021 [^] [^^] [^^^] [ответить] [↓] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
 Да, я могу объяснить.
1. Я сомневаюсь, что _все_ пытаются патчить, _вместо_ того, чтобы переползать.
2. Те, кто решил переползать закончат этот процесс ещё не скоро. Это может занять до полугода. И что ты им предложишь? Не патчить и жить с дырявым? Или уйти в оффлайн на это время?
3. log4j может использоваться депендансом, или несколькими. Так что мало свой код увести от lod4j, надо и чужой тоже.
4. Со временем дыры залатают. И когда это случится, вот сядут разрабы и задумаются: а собственно нахрена мы переползали?
5. Я читал мнение в интернете, что по-крайней мере первая дыра с ldap существовала благодаря обратной совместимости. Может разрабы log4j переосмыслят свой подход к обратной совместимости, перепилят синтаксис форматной строки, отломав оттуда 90% финтифлюшек, оставят ровно столько функционала, чтоб не более 5% зависимых проектов заметило бы изменение, и для этих 5% приделают опцию сборки "enable-deprecated-format-string"?
Короче, ещё рано делать выводы о том, отказывается ли кто-то или нет, и стоит ли овчинка выделки.
| | |
| |
| |
| 4.77, Ordu (ok), 10:37, 20/12/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| –1 +/– |
>> переползать ... Это может занять до полугода
> А, может, надо не переползать, а бежать? Тогда быстрее будет.
Тебе нужна стабильность или скорость? Тут ситуация такая, что чем быстрее бежишь, чем дольше выходит. Программирование требует от программиста, чтобы тот _думал_ _головой_. А мышление требует времени. Те кто бежит -- те не думают, они пытаются решить проблему брутфорсом. Это работает ровно до тех пор, пока оно не перестаёт работать, и вот после этого уже не остаётся никакого выбора, кроме как выкинуть результат и начать заново.
> Были времена,
> когда за год писали язык программирования + ось.
Да, и Солнце было ярче, и память меряли в килобайтах. И те оси ничего не умели по сегодняшним меркам, и, соответственно, никому не нужны сегодня. Некоторые из языков программирования остались, но если ты присмотришься, они остались вовсе не потому, что нельзя сделать лучше, а потому, что переползать на новые и более подходящие для задачи языки сложнее, чем продолжать пользоваться убогими.
| | |
|
|
| 2.83, Наме (?), 11:42, 20/12/2021 [^] [^^] [^^^] [ответить] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +1 +/– |
Причина простая. Увы, большинство крупных проектов на Жабе, мягко скажем, крайне сложны своей бессистемностью и объёмом. Народ массово и бездумно использует чужой код, благо тянуть его через maven очень просто. Хвост зависимостей более-менее развитого проекта очень уж разухабист, а чаще всего в проекте просто нет людей, которые бы хоть как-то себе представляли весь "масштаб бедствия".
| | |
| |
| 3.104, Аноним (-), 23:19, 20/12/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
В любом более-менее современном пакетном менеджере для Java очень легко вырезать ненужные зависимости. И даже полная перепаковка со сборкой нужных классов для Java не проблема. log4j2 заменяется переходником на slf4j, и всё. В том то и дело, что проблема очень странная. Зачем так держаться за log4j2? Кто использует какие-то фичи из него, которых не хватает в slf4j?
| | |
| |
| 4.107, Наме (?), 10:17, 21/12/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
Может быть, но по-моему, не меняется он легко в проекте, которому лет дцать, и у которого за это время группа разработки менялась сто раз. Это адский гемор.
В любом "пакетном менеджере" )))) Это в каком же? Везде maven. Вы знаете ещё какие-то? У шибко продвинутых bnd. Где-то в пыли gradle и ant.
| | |
| |
| 5.112, Аноним (39), 19:11, 21/12/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– | |
gradle, maven, sbt, ivy, ... Откройте maven search и посмотрите - https://search.maven.org/artifact/org.springframework/spring/5.2.19.RELEASE/po
И да, если в maven что-то сделать - это ужас-ужас, то в gradle чужие зависимости исключаются простым exclude. Как, впрочем, и миграция с maven на gradle в большинстве случаев проблем не вызывает. Но если вам нравится садомазо, то технически можете и в maven поправить.
| | |
| |
| 6.113, iZEN (ok), 19:18, 21/12/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
 > gradle, maven, sbt, ivy, ... Откройте maven search и посмотрите - https://search.maven.org/artifact/org.springframework/spring/5.2.19.RELEASE/po
> И да, если в maven что-то сделать - это ужас-ужас, то в
> gradle чужие зависимости исключаются простым exclude.
<exclusions>
<exclusion> <!-- declare the exclusion here -->
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
</exclusion>
</exclusions>
> Как, впрочем, и миграция с
> maven на gradle в большинстве случаев проблем не вызывает. Но если
> вам нравится садомазо, то технически можете и в maven поправить.
Можем использовать == используем. Садомазо с Gradle сами занимайтесь.
| | |
|
|
|
|
|
| 1.70, Аноним (70), 08:11, 20/12/2021 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +1 +/– |
Кто конкретно внёс указанную уязвимость? С современными системами контроля версий выяснить это не составляет труда. Почему старательно обходятся вопросы персональной ответственности разработчика? Или лицензия на этот самый Log4j не даёт возможность привлекать разработчиков? Тогда почему сотни проектов используют код, за который никто и никак не отвечает? Всё это очень странно.
| | |
| |
| 2.76, Аноним (75), 10:07, 20/12/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +1 +/– |
Да факт существования такой защиты это секрет. Не стоит вскрывать эту тему. Ты молодой, шутливый, тебе все легко. Это не то. Это не Чикатило и даже не архивы спецслужб. Сюда лучше не лезть. Серьезно, ты будешь жалеть. Лучше закрой тему и забудь, что тут писалось. Я вполне понимаю, что данным сообщением вызову дополнительный интерес, но хочу сразу предостеречь пытливых - стоп. Остальные просто не найдут.
| | |
|
|
