Pull to refresh
21
0
Александр Елисеев @wAngel

User

Send message

У вас устаревшие данные и вы вводите людей в заблуждение.

  1. LOG4J_FORMAT_MSG_NO_LOOKUPS недостаточно (https://logging.apache.org/log4j/2.x/security.html)

Other insufficient mitigation measures are: setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.

The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf("%s", userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors.

  1. Версия 2.15, которую вы называете "новейшей", на данный момент (28.12.2021) а) уязвима к CVE-2021-45046 б) уж точно не новейшая.

Единственный правильный вариант по исправлению уязвимости в своих приложениях на данный момент - обновление на 2.17.

Модуль log4j-api не содержит уязвимости:

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

На 20 декабря 2021 правильнее обновляться сразу на 2.17 в которой исправлены ещё и CVE-2021-45105.

Про «надо помолчать» есть ещё один интересный психологический момент.

Случается, что технические специалисты воспринимают подобные ситуации как личный вызов «своему» решению и стараются искать ответ в текущей парадигме. Такая игра: придумай ответ, который максимально впихивается в ранее высказанное / существующее решение. И всё обсуждение сводится к посылу «я и раньше был прав», а вернуться на шаг назад и пересмотреть предпосылки — ментально сильно тяжелее.

Всё это напоминает градиентный метод, который приближает нас к оптимуму, но тот вполне вероятно — локальный.

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

Может у кого есть рецепты для фасилитации подобных дискуссий?
Подскажите, кто в теме, насколько в принципе законно расшифровывать трафик трафик сотрудников? Казалось бы это должно нарушать право на тайну личной переписки, которую гарантирует Конституция РФ и никакой трудовой договор не может этого отменить.

Наша организация как раз начала внедрять подобную практики, что поломало нам весь CI, завязанный на Linux-сервера, которые, понятное дело, не в AD и знать не знали о новом корневом сертификате, которым подписано всё от GitHub до DockerHub.

Посоветуйте, как бороться с такой «безопасностью»?
Алексей, скажите, пожалуйста, есть ли у вас опыт участия в реальном проекте по разработке ПО? В т.ч. с использованием тех методологий, которые вы упомянули в статье.
Я поэтому и спросил, т.к. не в курсе положения дел, и не делал никаких утверждений.
Если вы знаете — расскажите, плз.
Популярно ли решать задачи на ФЯП? Эффективно ли с точки зрения времени выполнения (по сравнению с другими) и, собственно, самой реализации?
А вот интересно. Как обстоят дела с применимостью функциональных ЯП в ACM-like задачах, где требуется иметь очень хорошее представление о вычислительной сложности операций, которое формируется в т.ч. за счет использования явных императивных конструкций?

Расскажите, плз, кто знает.
Более или менее известно — Copy-on-write же.
У нас противоположный опыт использования собственного NuGet-репозитория. Действительно, добавление еще одной точки отказа может привести к проблемам, но преимуществ оказалось больше. Возможно дело в специфике проектов. Никаких «случайных» обновлений не замечено.
А эти же 600 МБ теперь тоже тянутся, но из VCS?
Коллеги занимаются диагностированием заболеваний легких на основе снимков DiCom.
Если у кого-то есть интерес, пишите в личку.
Скажите, почему в примерах для C# нет «прогрева» JIT?
В TrueCrypt — hidden part c «ложной» базой паролей, например.
Ваш архитектор случайно не аргументировал свои слова?
Интересно, большое спасибо!

Лично мне, не смотря на все сравнения и примеры, ну никак не получается «понимать» такие большие (и малые) числа. Ноликом больше или меньше с определенного момента не имеет принципиального значения.

Об этом, кстати, писал Дуглас Адамс, что человек просто не может представить себе и осознать реальных размеров вселенной, а изысканный способ свести его с ума — машина, которая показывает человеку масштабы вселенной и его место в ней.
Пример того, как любое формальное следование чужим методологиям приводит к «культу карго».

Так вообще бывает? Посмотреть на другую компанию и решить работать точно так же?
Почему вы считаете детали реализации конкретной СУБД отличными задачками для собеседования?
Было такое же впечатление до того как поработал с PS. Попробуйте сами, возможно поменяете мнение.
Очень интересно было бы почитать про используемые подходы. Сам чит тут вряд ли кому-то нужен.

Может быть получится не нарушая условий написать статью?
Прям на душе потеплело, что не только у нас такие интерфейсы встречаются!

Про доработку под пользователей это точно, а еще бывает, что «в старой системе было не так, мы привыкли, сделайте как было».

Information

Rating
Does not participate
Location
Пермь, Пермский край, Россия
Date of birth
Registered
Activity