Критическая проблема в NPM 5.7, приводящая к смене прав доступа на системные каталоги

В опубликованном вчера выпуске пакетного менеджера NPM 5.7.0 выявлена серьёзная проблема, которая может привести к нарушению нормальной работы компонентов операционной системы. При запуске npm с использованием утилиты sudo (не важно, какая команда выполняется, достаточно запустить «sudo npm —help» или «npm update -g») рекурсивно меняются права доступа на каталоги, относительно корневого префикса npm. Судя по отчётам пострадавших пользователей, после подобного изменения могут возникнуть проблемы с загрузкой операционной системы и работой локальных приложений. Проблема проявляется только при запуске npm с использованием утилиты sudo.

При запуске с применением sudo вместо root в качестве владельца для системных каталогов, включая всё содержимое /etc, /usr и /boot, устанавливается текущий непривилегированный пользователь. Источником проблемы стал переход версии 5.7.0 на новую реализацию mkdir, сохраняющую исходные права доступа и владельца при запуске с правами root с использованием sudo.

Проблема уже решена в обновлении 5.7.1. Массовых проблем удалось избежать благодаря тому, что в репозитории выпуски npm 5.7.x были помечены как экспериментальные и не доставлялись через каналы обновления стабильных релизов. При этом на сайте анонс был опубликован в форме, не отличающейся от объявлений стабильных релизов, что ввело в заблуждение некоторых пользователей, которые попытались перевести на RPM 5.7 свои рабочие системы. Также интересно, что сообщение об ошибке с описанием проблемы было отправлено за неделю до релиза 5.7.0, но осталось без внимания разработчиков.

В случае отсутствия резервной копии для восстановления всех изначальных прав доступа может потребоваться переустановка системы или восстановление прав на уровне пакетного менеджера с ручной корректировкой каталогов пользователей. Например, можно выполнить:

    RPM:     for p in $(rpm -qa); do rpm --setperms $p; do rpm --setugids $p; done    DEB:     dpkg --get-selections | grep install | grep -v deinstall | cut -f1 | xargs apt-get --reinstall -y --force-yes install    FreeBSD:     mtree -U -f /etc/mtree/BSD.root.dist     mtree -U -f /etc/mtree/BSD.var.dist     mtree -U -f /etc/mtree/BSD.include.dist     mtree -U -f /etc/mtree/BSD.sendmail.dist     mtree -U -f /etc/mtree/BSD.usr.dist      

Источник: [ссылка]

Критическая проблема в NPM 5.7, приводящая к смене прав доступа на системные каталоги

В опубликованном вчера выпуске пакетного менеджера NPM 5.7.0 выявлена серьёзная проблема, которая может привести к нарушению нормальной работы компонентов операционной системы. При запуске npm с использованием утилиты sudo (не важно, какая команда выполняется, достаточно запустить «sudo npm —help» или «npm update -g») рекурсивно меняются права доступа на каталоги, относительно корневого префикса npm. Судя по отчётам пострадавших пользователей, после подобного изменения могут возникнуть проблемы с загрузкой операционной системы и работой локальных приложений. Проблема проявляется только при запуске npm с использованием утилиты sudo.

При запуске с применением sudo вместо root в качестве владельца для системных каталогов, включая всё содержимое /etc, /usr и /boot, устанавливается текущий непривилегированный пользователь. Источником проблемы стал переход версии 5.7.0 на новую реализацию mkdir, сохраняющую исходные права доступа и владельца при запуске с правами root с использованием sudo.

Проблема уже решена в обновлении 5.7.1. Массовых проблем удалось избежать благодаря тому, что в репозитории выпуски npm 5.7.x были помечены как экспериментальные и не доставлялись через каналы обновления стабильных релизов. При этом на сайте анонс был опубликован в форме, не отличающейся от объявлений стабильных релизов, что ввело в заблуждение некоторых пользователей, которые попытались перевести на RPM 5.7 свои рабочие системы. Также интересно, что сообщение об ошибке с описанием проблемы было отправлено за неделю до релиза 5.7.0, но осталось без внимания разработчиков.

В случае отсутствия резервной копии для восстановления всех изначальных прав доступа может потребоваться переустановка системы или восстановление прав на уровне пакетного менеджера с ручной корректировкой каталогов пользователей. Например, можно выполнить:

    RPM:     for p in $(rpm -qa); do rpm --setperms $p; do rpm --setugids $p; done    DEB:     dpkg --get-selections | grep install | grep -v deinstall | cut -f1 | xargs apt-get --reinstall -y --force-yes install    FreeBSD:     mtree -U -f /etc/mtree/BSD.root.dist     mtree -U -f /etc/mtree/BSD.var.dist     mtree -U -f /etc/mtree/BSD.include.dist     mtree -U -f /etc/mtree/BSD.sendmail.dist     mtree -U -f /etc/mtree/BSD.usr.dist      

Источник: [ссылка]

Релиз почтового сервера Postfix 3.3.0

После года разработки состоялся релиз новой стабильной ветки почтового сервера Postfix — 3.3.0. В то же время объявлено о прекращении поддержки ветки Postfix 2.11, выпущенной в начале 2014 года. Postfix является одним из редких проектов, сочетающих одновременно высокую безопасность, надёжность и производительность, чего удалось добиться благодаря продуманной архитектуре и достаточно жесткой политике оформления кода и аудита патчей.

Позавчера проект отметил 21 год с момента формирования первой сборки 20 февраля 1997 года, которая включала библиотеку функций и базовый обработчик, уложившиеся в 8086 строк кода (4204 без комментариев). В соответствии с данными, полученными в результате автоматизированного опроса около двух миллионов почтовых серверов, Postfix используется на 33.79% (год назад 33.07%) почтовых серверов, доля Exim составляет 56.8% (56.02%), Sendmail — 4.43% (5.06%), Microsoft Exchange — 0.81% (1.14%).

Основные новшества Postfix 3.3.0:

  • Переход на двойную лицензию. В дополнение к изначальной используемой жесткой копилефт лицензии IBM Public License (IPL) 1.0, код Postfix теперь также доступен и под лицензией Eclipse Public License (EPL) 2.0, которая относится к категории слабого копилефта, при котором изменения требуется открывать только при поставке продукта, содержащего модифицированную версию кода (для внутреннего использования изменения могут вноситься без их открытия). В своё время поставка Postfix под лицензией IPL не позволила включить его в базовый состав OpenBSD и привела к созданию проектом OpenBSD собственного SMTP-сервера;
  • В утилите postconf обеспечен вывод предупреждений при использовании неизвестных имён параметров в конфигурационных файлах с базами данных;
  • Средства для запуска в изолированном контейнере: при помощи новой команды «postfix start-fg» Postfix теперь можно запустить без перехода в фоновый режим. Для проброса логов на сторону хоста нужно примонтировать в контейнер сокет /dev/log (например, при помощи команды «docker run -v /dev/log:/dev/log») и указать отдельное имя для записи в лог («postconf syslog_name=имя»);
  • Поддержка Milter расширена возможностью отправки приложениями параметров RET и ENVID в запросах SMFIR_CHGFROM (изменение адреса отправителя);
  • По умолчанию применена новая схема форматирования содержимого заголовка «From:» для писем, сгенерированных в Postfix. Вместо ранее применявшегося синтаксиса «From: address (name)» теперь используется «From: name ‹address›». Для возврата старого поведения следует указать в настройках «header_from_format = obsolete»;
  • При включении поддержки одновременно IPv6 и IPv4 SMTP-клиент Postfix теперь пытается равномерно распределять отправки запросов по IPv6 и IPv4, независимо от числа фактически заявленных для MX адресов каждого типа. Предложенный метод балансировки позволяет избежать проблем с доставкой, когда для MX заявлено большое число адресов IPv6, но на деле работоспособен только IPv4 и наоборот. Для настройки поведения можно использовать параметр smtp_balance_mx_inet_protocols;
  • При запуске в режиме совместимости настроек по умолчанию с прошлыми ветками Postfix (compatibility_level меньше 1), SMTP-сервер теперь лишь выдаёт предупреждение (но не блокирует) для почты, которая раньше блокировалась в силу настройки smtpd_relay_restrictions;
  • В параметре pgsql_table добавлена поддержка URI «postgresql://»;
  • В SMTP-сервере разрешено использование команды XCLIENT до STARTTLS при применении TLS, что может быть полезным для организации работы серверов, размещённых за reverse-proxy, например, за nginx.

Источник: [ссылка]

Энтузиасты взяли на себя продолжение разработки Wine staging

Разработчики проекта Wine официально представили новый репозиторий на GitHub, в котором будет продолжена разработка проекта Wine staging, мэйнтейнеры которого несколько дней назад объявили, что не могут больше заниматься подготовкой новых релизов. Напомним, что в рамках проекта Wine staging развиваются расширенные сборки Wine, включающие не полностью готовые или рискованные патчи, пока не пригодные для принятия в основную ветку Wine. Например, в Wine staging предоставляется поддержка Windows ACL, CUDA/PhysX/NVENC для видеокарт NVIDIA, EAX 1, API Vulkan, тем оформления GTK3+, декодирования DXVA2 на стороне GPU.

Обязанности мэйнтейнера возрождённого Wine staging взял на себя Alistair Leslie-Hughes из сообщества разработчиков Wine, известный проектом monoDX (реализация DirectX для Mono). Помогать в сопровождении проекта согласились разработчики Thomas Crider и Zebediah Figura.

В настоящее время новая команда занялась переводом поддерживаемых проектом патчей на актуальную кодовую базу Wine 3.x. За два с половиной месяца неактивности разработки Wine staging многое изменилось и при попытке актуализации Wine staging всплывает множество конфликтов (проектом поддерживается более 1100 патчей), на разбор которых уходит много времени. Разработчики также находятся в процессе получения доступа к сборочной инфраструктуре Wine, которая позволит им наладить формирование готовых пакетов.

Среди краткосрочных планов отмечается перевод кода Wine staging на актуальную кодовую базу Wine, обеспечение компиляции без ошибок, переработка патчей для восстановления функциональности и выпуск начального релиза. После выпуска начального релиза будет возобновлён приём новых патчей. Среди долгосрочных целей называется сокращение числа патчей в ветке staging и улучшение связей между патчами и отчётами о решаемых ими проблемах.

Источник: [ссылка]

Для ядра Linux предложен новый пакетный фильтр bpfilter

Разработчики подсистемы NetFilter выставили на обсуждение патчи с начальной реализацией нового пакетного фильтра bpfilter, который со временем может заменить ныне поддерживаемые механизмы фильтрации пакетов nftables и iptables. Несмотря на все свои достоинства интенсивность внедрения механизма Nftables оставляет желать лучшего и iptables до сих пор остаётся более востребован и не желает повторять судьбу ipchains и ipfwadm.

В nftables логика фильтрации и специфичные для протоколов обработчики компилируются в байткод в пространстве пользователя, после чего данный байткод загружается в ядро при помощи интерфейса Netlink и выполняется в специальной виртуальной машине, напоминающей BPF (Berkeley Packet Filters). При этом последние годы в ядре Linux поставляется универсальная встроенная виртуальная машина BPF с JIT, для которой активно ведётся работа по улучшению производительности, функциональности и безопасности. Чтобы не поддерживать две разные виртуальные машины, выполняющие сходные задачи, и для достижения более высокой производительности у разработчиков возникла идея построения пакетного фильтра на основе штатного BPF-движка ядра Linux.

В итоге был подготовлен прототип нового пакетного фильтра bpfilter, иллюстрирующий идею применения BPF для фильтрации пакетов. Наиболее важным решением в предложенном прототипе стало желание обеспечить полную совместимость с наборами правил iptables, т.е. bpfilter сможет выступить в роли прозрачной замены iptables, полностью совместимой со всеми существующими конфигурациями (администраторам не придётся изучать новый синтаксис правил). Bpfilter обрабатывает запросы iptables и транслирует их в программы BPF, привязываемые к различным подсистемам. Например, при помощи XDP (eXpress Data Path) можно запустить BPF-программу на уровне сетевого драйвера, с возможностью прямого доступа к DMA-буферу пакетов для высокопроизводительной обработки.

Трансляция правил выполняется целиком в пространстве пользователя, что упрощает отладку и повышает безопасность. Для повышения производительности также может применяться JIT-компиляция BPF в машинные инструкции для архитектур x86_64, arm64, ppc64, sparc64, mips64, s390x и arm32, или задействование аппаратных механизмов выполнения BPF на уровне сетевого адаптера (например, Netronome NFP SmartNIC).

Харальд Вельте (Harald Welte), один из основных разработчиков netfilter/iptables, поставил под сомнение идею полной эмуляции правил iptables через BPF для обеспечения прозрачной замены iptables, так как полностью повторить поведение iptables будет слишком трудно, а наличие различий при обработке существующих наборов правил iptables может привести к возникновению неожиданных проблем с безопасностью.

К тому же некоторые элементы дизайна iptables нельзя назвать удачными и повторение API iptables в bpfilter может привести к тому, что допущенные 18 лет назад ошибки проектирования iptables закрепятся ещё на 10 лет. Например, API iptables не предоставляет способа добавления/замены единичного правила или небольшого набора правил, а может только целиком очистить и перезагрузить всю конфигурацию. Данная особенность делает внесение изменений в межсетевой экран неудобным и существенно усложняет координацию одновременного внесения изменений несколькими обработчиками. Недовольство также вызывает необходимость разделения наборов правил для IPv4 и IPv6.

Вельте предложил не фокусироваться только на повторении iptables, а реализовать в bpfilter эмуляцию nftables API, который спроектирован с учётом недостатков iptables и больше соответствует современным реалиям. Возможность использования API nftables позволит поддержать тех, кто уже перешёл на nftables, а для остающихся на iptables будет стимулировать миграцию.

Дэвид Миллер (David Miller), мэйнтейнер сетевой подсистемы ядра, возразил, что iptables до сих пор существенно более распространён и реализация его интерфейса позволит достичь широкого охвата при тестировании. Вельте парировал тем, что в наиболее крупных областях применения, таких как Docker и Kubernetes, используются утилиты командной строки, а не iptables API, поэтому нет смысла в эмуляции API как такового для проведения тестирования в подобных системах.

Миллер также обратил внимание на то, что nftables так и не решил проблемы с производительностью подсистемы фильтрации пакетов, сместив вместо этого внимание на сетевые технологии в пространстве пользователя. Nftables может стать одним из тех экспериментов, которые позволяются разобраться в некоторой проблемной области, но никогда не получают распространения в реальной практике. При этом, bpfilter ещё очень далеко до интеграции в ядре, так как представления о его производительности пока носят лишь теоретический характер, код достаточно сырой, отсутствуют многие возможности, а некоторые функции не могут быть реализованы через BPF и требуют дополнительной поддержки в ядре (например, отслеживание соединений).

Источник: [ссылка]

Представлен новый инсталлятор для серверной редакции Ubuntu

Дастин Киркленд (Dustin Kirkland), входящий в команду, определяющую стратегию развития в компании Canonical, представил новый инсталлятор Subiquity, который будет использован по умолчанию в серверной редакции Ubuntu 18.04. Новый инсталлятор предоставляет текстовый режим установки и уже доступен для тестирования в составе ежедневных Live-сборок.

Пользователю предлагаются консольные варианты интерфейса для разбивки дисков, настройки RAID, выбора языка и раскладки клавиатуры, создания пользователей, настройки сетевого соединения. Возможна автоматизированная установка по профилю конфигурации, определённому в формате JSON. Вместе с инсталлятором также поставляется утилита «console-conf» для первичной настройки системы, после первой загрузки.

Источник: [ссылка]

Скомпрометирована инфраструктура проекта Mageia

Разработчики Linux-дистрибутива Mageia, в рамках которого независимым сообществом энтузиастов развивается форк проекта Mandriva, сообщили о компрометации сервера идентификации проекта и утечке базы пользователей. Неизвестный атакующий смог получить доступ к LDAP-серверу Mageia (identity.mageia.org) и опубликовал хранящиеся там данные, включая имена пользователей, хэши паролей и email-адреса.

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

После выявления атаки все пароли были сброшены и пользователям предложено поменять параметры входа через интерфейс восстановления забытого пароля. С пользователями, имевшими повышенный уровень привилегий, администраторы проекта свяжутся отдельно для восстановления доступа в индивидуальном порядке. Всем пользователям, которые применяют одинаковые пароли в нескольких сервисах, рекомендуется срочно поменять пересекающиеся с Mageia пароли и на других сайтах, так как злоумышленники могут сопоставить учётные данные по email.

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

Источник: [ссылка]

Выпуск nginx 1.13.9 c поддержкой технологии HTTP/2 Server Push

Подготовлен выпуск основной ветки высокопроизводительного HTTP-сервера nginx 1.13.9, в котором реализован механизм Server Push для протокола HTTP/2. Server Push предоставляет возможность отправки ресурсов от сервера к клиенту, не дожидаясь их явного запроса (например, подобным образом можно передавать файлы CSS, скрипты и изображения, которые необходимы для отрисовки страницы).

Для отправки push-запросов используется уже установленное клиентом соединение. Т.е. клиент подключается и запрашивает определённую страницу, после этого сервер на основании своих настроек или содержимого переданного клиентом заголовка Link сам инициирует передачу определённых ресурсов через уже установленное соединение HTTP/2, не дожидаясь запроса этих ресурсов от клиента. При этом клиент может отвергнуть попытку push-отправки, вернув флаг RST_STREAM.

Переданный через push-обращение контент сохраняется на стороне клиента в специальном кэше, ассоциированном с текущим HTTP/2-соединением. Когда в процессе обработки страницы клиент дойдёт до запроса связанных с ней ресурсов (css, js, картинки и т.п.), перед фактической отправкой каждого запроса, будет выполнена проверка в кэше. Если ресурс уже передан сервером и находится в кэше, то клиент загрузит этот ресурс из локального кэша не формируя внешний запрос к серверу. После закрытия соединения HTTP/2 содержимое кэша очищается.

При этом есть важные особенности: Глобальный кэш браузера имеет больший приоритет, чем кэш соединения HTTP/2, поэтому даже если push-запросом был передан более свежий ресурс, браузер продолжит использование ресурса из своего глобального кэша, если он не потерял актуальность (трафик потраченный на push-запрос будет потрачен в пустую). С другой стороны, так как одно HTTP/2 соединение может обслуживать загрузку разных страниц с одного хоста, то загруженные через push ресурсы могут совместно использоваться при загрузке разных страниц.

Для управления отправкой push-запросов в новом выпуске nginx реализованы директивы:

  • «http2_push {uri}» для включения упреждающей отправки заданных ресурсов (например, «http2_push /main.css») в составе первого ответа, не дожидаясь их явного запроса. В URI допустимо использование переменных. В одном блоке конфигурации может быть задано несколько директив http2_push. Для обеспечения должного уровня защиты обрабатываются только относительные пути к ресурсу;
  • «http2_push_preload» — данные о ресурсах, которые следует передавать через Server Push, определяются на основе анализа содержимого отправляемых клиентом HTTP-заголовков Link;
  • «http2_max_concurrent_pushes» — максимально допустимое число одновременных push-запросов, сопровождающих ответ.

Источник: [ссылка]

Для FreeBSD и QEMU/KVM реализованы механизмы блокировки атак Spectre и Meltdown

Разработчики FreeBSD интегрировали в ветку 11-STABLE набор патчей, блокирующих проведение атак Spectre и Meltdown. Защита от Meltdown базируется на уже опробованной в других ОС технике PTI (Page Table Isolation), основанной на разделении таблиц страниц памяти ядра и пространства пользователя при переключении контекста во время системного вызова. Патч также включает оптимизации при помощи инструкции PCID, позволяющие снизить негативное влияние на производительность при включении PTI.

Защита от второго варианта атаки Spectre основана на использования режима IBRS (Indirect Branch Restricted Speculation), представленного компанией Intel в недавнем обновлении микрокода. IBRS позволяет во время работы в зависимости от ситуации разрешать и запрещать спекулятивное выполнение косвенных переходов, например, запрещать во время обработки прерываний, системных вызовов и переключений контекста.

Для применения защиты от Spectre обязательно требуется наличие обновлённого микрокода для процессоров Intel, которое пока проходит тестирование OEM-производителями перед началом массового распространения. Применение IBRS может быть отключено через sysctl, но PTI пока неотключаем, с чем в основном и связаны основные пожелания пользователей, участвующих в обсуждении.

Дополнительно можно отметить выпуск обновления QEMU 2.11.1, в котором представлен механизм защиты от Spectre и Meltdown для гостевых систем, работающих под управлением гипервизора KVM. Защита от Meltdown основана на патчах KPTI, а защита от Spectre построена с привлечением IBRS (Indirect Branch Restricted Speculation) и IBPB (Indirect Branch Prediction Barriers), предложенных в обновлённом микрокоде Intel и AMD.

Источник: [ссылка]

Опубликован прототип эмулятора для запуска исполняемых файлов OS/2 в Linux

Доступен начальный прототип нового эмулятора 2ine, нацеленного на выполнение исполняемых файлов OS/2 в Linux по аналогии с тем как Wine позволяет запускать исполняемые файлы Windows. В текущем виде проект уже может выполнять консольные приложения, такие как порты GCC и Watcom C для OS/2, сетевые приложения (например, FTP.EXE) и простейшие графические программы для Presentation Manager. Работа графики симулируется через SDL.

Проект развивает в качестве эксперимента Райан Гордон (Ryan C. Gordon), который является автором системы MojoELF, позволяющей запускать приложения Linux в окружении macOS. Райан также принимал участие в портировании огромного количества игр и программ для Linux (Google Earth, Quake 3, Unreal Tournament, Prey, Postal 2, Second Life и ещё более 40 игр), разработал формат компоновки исполняемых файлов FatELF, создал Apache-модуль mod_offload, придумал язык программирования Toby и являлся мэйнтейнером проекта SDL.

Источник: [ссылка]

Выпуск CRM-системы SuiteCRM 7.10

Состоялся релиз SuiteCRM 7.10, CRM-системы для организации взаимодействия с клиентами на предприятии, обеспечения работы службы продаж, ведения партнёрской сети, предоставления сервисов и планирования работы сотрудников. В том числе предоставляются модули для работы с контрактами, накладными, PDF-шаблонами, котировками, базой продуктов, формирования отчётов и диаграмм, управления событиями. SuiteCRM позиционируется в качестве полноценной открытой альтернативы проприетарному продукту SugarCRM, а также таким системам, как SalesForce и Microsoft Dynamics. Код системы и модулей написан на PHP и поставляется под лицензией GPLv3. В качестве СУБД по умолчанию предлагается использовать MariaDB.

SuiteCRM развивается компанией SalesAgility, использующей бизнес-модель, подразумевающую неограниченное распространение и разработку полностью открытого продукта, с получением прибыли через оказание платных услуг поддержки, доработки и сопровождения. В качестве основы SuiteCRM выступает Community-версия SugarCRM, доведённая до функциональности SugarCRM Professional Edition через открытые модули собственной разработки. Управление производится через web-интерфейс (online-демонстрация). SuiteCRM является полностью открытым проектом, как в плане доступности исходных текстов под свободной лицензией, так и в области открытого управления разработкой.

Особенности нового выпуска:

  • Представлено новое компактное оформление интерфейса, в котором экранное пространство более эффективно используется для размещения всей важной информации. На выбор предлагается 4 цветовых схемы — «Рассвет», «День», «Сумерки» и «Ночь»;
  • Новый REST API (v8), построенный на базе спецификации JSONAPI, предоставляющий доступ ко всей функциональности SuiteCRM и поддерживающий доступ с использованием аутентификации OAuth 2.0. Использование Swagger (OpenAPI v3.0) для предоставления документации;
  • Новый модуль, позволяющий создавать, оформлять и отправлять клиентам различные опросы. Результаты заполнения опросов сохраняются и анализируются в CRM. Поддерживаются различные типы опросников, в том числе отправляемые на email или оформляемые в виде web-страниц;
  • Режим помощи соблюдения общего регламента по защите данных (GDPR), предоставляющий клиентам возможность контроля над собственными персональными данными. Режим Web to Person, предоставляющий средства для подтверждения выбора по электронной почте. Возможность самостоятельного управления пользователем настройками opt-in (по умолчанию выключено, но пользователь может включить);
  • Поддержка двухфакторной аутентификации. Режим двухфакторной аутентификации с подтверждением по электронной почте;
  • Улучшена система предупреждений;
  • Расширены возможности по управлению паролями. Поддержка задания ограничений по оформлению паролей и ведение журнала попыток входа. Возможность интеграции с системой Fail2Ban для автоматического блокирования попыток подбора паролей.
  • Новый набор unit-тестов;
  • Увеличена производительность системы рассылки по электронной почте.

Источник: [ссылка]

Выпуск DPDK 18.02, фреймворка для высокопроизводительных сетевых приложений

Состоялся релиз фреймворка DPDK (Data Plane Development Kit), предоставляющего средства для создания высокопроизводительных сетевых приложений, напрямую работающих с сетевым оборудованием и обрабатывающих пакеты минуя сетевой стек ядра. В качестве первичной платформы заявлен Linux, но имеется ограниченный по своим возможностям вариант для FreeBSD. Исходные тексты библиотек и драйверов поставляются под лицензией BSD, а компоненты для ядра Linux доступны под GPLv2.

Разработчикам предлагается набор библиотек для низкоуровневой работы с сетевыми адаптерами, взаимодействия в многоядерных системах, задействования кольцевых буферов и больших страниц памяти («huge page»). При помощи данных библиотек можно принимать и отправлять сетевые пакеты с выполнением минимального числа циклов CPU (около 80 циклов на пакет), создавать быстрые системы захвата трафика (аналоги tcpdump) и разрабатывать высокопроизводительные компоненты сетевого стека.

При этом DPDK сам по себе не является сетевым стеком, а лишь предоставляет низкоуровневую функциональность на безе которой можно создавать реализации виртуализированных компонентов сетей (NFV, Network Functions Virtualization). Например, DPDK применяется в качестве основы для выполняемого в пространстве пользователя сетевого стека F-Stack, а также используется в проекте OPNFV (Open Platform for NFV Project) для разработки виртуальных реализаций пограничных контроллеров сессий (SBC), коммутаторов, балансировщиков нагрузки, межсетевых экранов, систем обнаружения атак и WAN-ускорителей. Разработка DPDK ведётся под эгидой организации Linux Foundation при участии компаний ARM, AT&T, Cavium, Intel, Mellanox, NXP, Red Hat, ZTE, Huawei и Wind River.

В новом выпуске сохранена полная совместимость с версией 17.11 на уровне ABI (можно обновить библиотеки без пересборки приложений). Добавлена поддержка новых классов устройств rawdev и bbdev (Wireless Base Band для ускорения обработки 3gpp Layer 1), представлен ethernet-драйвер AVF (Adaptive Virtual Function) и драйвер для поддержки платформы Hyper-V, расширены возможности драйверов igb, mlx5, mlx4, ixgbe и i40e, добавлены новые eventdev-драйверы DPAA (Data Path Acceleration Architecture) и OPDL (Ordered Packet Distribution Library), а также поддержка ускорения вычислений IPsec при помощи DPAA. Реализована экспериментальная поддержка систем сборки meson и ninja.

Источник: [ссылка]