Выпуск сборочной системы Meson 0.51

Опубликован релиз сборочной системы Meson 0.51, которая используется для сборки таких проектов, как X.Org Server, Mesa, Lighttpd, systemd, GStreamer, Wayland, GNOME и GTK+. Код Meson написан на языке Python и поставляется под лицензией Apache 2.0.

Ключевой целью развития Meson является обеспечение высокой скорости сборочного процесса в сочетании с удобством и простотой использования. Вместо утилиты make при сборке по умолчанию применяется инструментарий Ninja, но возможно применение и других бэкендов, таких как xcode и VisualStudio. В систему встроен многоплатформенный обработчик зависимостей, позволяющий использовать Meson для сборки пакетов для дистрибутивов. Правила сборки задаются на упрощённом предметно-ориентированном языке, отличаются хорошей читаемостью и понятны пользователю (по задумке авторов разработчик должен тратить минимум времени на написание правил).

Поддерживается кросс-компиляция и сборка в Linux, macOS и Windows с использованием GCC, Clang, Visual Studio и других компиляторов. Возможна сборка проектов на различных языках программирования, включая C, C++, Fortran, Java и Rust. Поддерживается инкрементальный режим сборки, при котором пересобираются только компоненты, напрямую связанные с изменениями, внесёнными с момента прошлой сборки. Meson можно использовать для формирования повторяемых сборок, при которых запуск сборки в разных окружениях приводит к генерации полностью идентичных исполняемых файлов.

Основные новшества Meson 0.51:

  • Добавлена поддержка прозрачной сборки существующих проектов, в которых используются сборочные сценарии CMake. Meson теперь напрямую может собирать простые субпроекты (такие как одиночные библиотеки) с использованием модуля CMake по аналогии со штатными субпроектами (в том числе субпроекты на CMake могут размещаться в каталоге subprojects );
  • Для всех применяемых компиляторов включено предварительное тестирование через сборку и исполнение простейших тестовых файлов (sanity check), не ограничиваясь тестированием указанных пользователем флагов для кросс-компиляторов (отныне проверяются и родные для текущей платформы компиляторы).
  • Добавлена возможность определения опций командной строки, применяемых при кросс-компиляции, с привязкой через задание префикса платформы перед опцией. Ранее опции командной строки охватывали только сборку для родной платформы и не могли указываться для кросс-компиляции. Теперь опции командной строки применяются независимо от того осуществляется нативная сборка или кросс-компиляция, гарантируя, что для нативных и кросс-сборок будет получен идентичный результат;
  • Добавлена возможность указания флага «—cross-file» более одного раза в командной строке для перечисления нескольких cross-файлов;
  • Добавлена поддержка компилятора ICL (Intel C/C++ Compiler) для платформы Windows (ICL.EXE и ifort);
  • Добавлена начальная поддержка инструментария для CPU Xtensa (xt-xcc, xt-xc++, xt-nm);
  • В объект «dependency» добавлен метод «get_variable», позволяющий получить значение переменной без учёта типа текущей зависимости (например, dep.get_variable(pkg-config : ‘var-name’, cmake : ‘COP_VAR_NAME));
  • Добавлен новый аргумент параметров целевой сборки — «link_language» для явного определения языка, используемого при вызове компоновщика. Например, основная программа на Fortran, может вызывать код на C/C++, что приведёт к автоматическому выбору C/C++, в том время как нужно использовать компоновщик от Fortran;
  • Изменена обработка флагов препроцессора CPPFLAGS. Если раньше Meson отдельно сохранял CPPFLAGS и специфичные для языков флаги компиляции (CFLAGS, CXXFLAGS), то теперь они обрабатываются нераздельно и перечисленные в CPPFLAGS флаги применяются как ещё один источник флагов компиляции для языков, которые их поддерживают;
  • Вывод custom_target и custom_target[i] теперь может использоваться в качестве аргументов в операциях link_with и link_whole;
  • В генераторах добавлена возможность задания дополнительных зависимостей при помощи опции «depends» (например, generator(program_runner, output: [‘@BASENAME@.c’], depends: exe));
  • В find_library добавлена опция static для охвата поиском только статически связанных библиотек;
  • Для python.find_installation добавлена возможность определения наличия заданного Python-модуля для конкретной версии Python;
  • Добавлен новый модуль unstable-kconfig для разбора файлов kconfig;
  • Добавлена новая команда «subprojects foreach», принимающая команду с аргументами и запускающая её во всех каталогах субпроектов;

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

Релиз дистрибутива OpenMandriva Lx 4

Спустя почти три года с момента формирования прошлой значительной ветки состоялся релиз дистрибутива OpenMandriva Lx 4.0. Проект развивается силами сообщества после того как компания Mandriva S.A. передала управление проектом в руки некоммерческой организации «OpenMandriva Association». Для загрузки предлагается Live-сборка размером 2.6 Гб (x86_64 и сборка «znver1», оптимизированная для процессоров AMD Ryzen, ThreadRipper и EPYC).

Выпуск OpenMandriva Lx 4 примечателен переходом на пакетный менеджер RPMv4, консольный инструментарий DNF и графический интерфейс управления пакетами Dnfdragora. Ранее проектом использовалась отдельно развиваемая ветка RPMv5, инструментарий urpmi и GUI rpmdrake. RPMv4 поддерживается компанией Red Hat и используется в таких дистрибутивах, как Fedora, RHEL, openSUSE и SUSE. Ветка RPMv5 развивалась сторонними энтузиастами и уже много лет находится в стагнации — последний стабильный выпуск RPMv5 был сформирован в 2010 году, после чего разработка остановилась. В отличие от RPMv5, проект RPMv4 активно развивается и сопровождается, а также предоставляет более полноценный набор инструментов для управления пакетами и репозиториями. Переход на RPMv4 также позволит избавиться от применяемых ныне в OpenMandriva грязных хаков и вспомогательных Perl-скриптов.

Другие изменения в OpenMandriva Lx 4:

  • Компилятор Clang, используемый для сборки пакетов, обновлён до ветки LLVM 8.0.1. Обновлены версии ядра Linux 5.1, Systemd 242, GCC 9.1, glibc 2.29, binutils 2.32, OpenJDK 12, Perl, 5.28, Python 3.7.3 (Python 2 исключён из базовой поставки);
  • Обновлён графический стек и пользовательские приложения: KDE Plasma 5.15.5, KDE Frameworks 5.58.0, KDE Applications 19.04.2, Qt 5.12.3, Xorg 1.20.4, Wayland 1.17, Mesa 19.0.3, Pulseaudio 12.2, LibreOffice 6.2.4, Calligra 3.1.0, Firefox 66.0.5, Falkon 3.1.0, Krita 4.2.1, Chromium 75, DigiKam 6.0;
  • В базовый состав помимо KDE включено графическое окружение LXQt 0.14;
  • По умолчанию в LibreOffice задействован VCL-плагин на базе Qt 5 и KDE Frameworks 5, который позволил привести интерфейс LibreOffice к общему стилю рабочего стола KDE Plasma, а также дал возможность использовать штатный диалог выбора файлов из Plasma 5;
  • Помимо Firefox и Chromium в основной состав добавлен развиваемый сообществом KDE браузер Falkon, который предлагается по умолчанию;
  • В поставку включён мультимедийный проигрыватель SMPlayer, использующий по умолчанию бэкенд MPV;
  • В связи с истечением срока действия патентов на MP3 в основной состав включены декодировщики и кодировщики MP3;
  • Для управления пользователями вместо userdrake задействован интерфейс Kuser, а для создания резервных копий вместо draksnapshot предложен KBackup;
  • Для информирования пользователя о наличии обновлений пакетов задействован апплет Plasma software updates»;
  • В загрузочное меню Live-окружения добавлены пункты для выбора языка и раскладки клавиатуры;
  • Обновлено приложение OpenMandriva Welcome с экраном первичной настройки;
  • Конфигуратор OpenMandriva Control Center заменил собой DrakX;
  • Добавлено приложение om-repo-picker с интерфейсом для выбора репозиториев;
  • Обновлён инсталлятор Calamares. Добавлена опция для настройки раздела подкачки. Реализовано сохранение лога процесса установки на успешно установленную систему. После завершения установки обеспечено удаление всех лишних языковых пакетов, не соответствующих выбранным языкам. Добавлена проверка установки в окружении VirtualBox — если используется реальное оборудование, то обеспечено удаление вспомогательных пакетов для virtualbox.
  • Подготовлены порты для архитектур aarch64 (Raspberry Pi 3 и DragonBoard 410c) и armv7hnl. В разработке находится порт для архитектуры RISC-V, который пока не готов для релиза;
  • Сформированы дополнительные сборки, специально оптимизированные для процессоров AMD (Ryzen, ThreadRipper, EPYC).
  • В базовый состав Live-образа включена карточная игра KPatience;

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

Выпуск системы инициализации sysvinit 2.95

Состоялся релиз классической системы инициализации sysvinit 2.95, которая широко применялась в дистрибутивах Linux во времена до systemd и upstart, а теперь продолжает использоваться в дистрибутиве Devuan. Одновременно сформированы выпуски применяемых в связке с sysvinit утилит insserv 1.20.0 и startpar 0.63. Утилита insserv предназначена для организации процесса загрузки с учётом зависимостей между init-скриптами, а startpar применяется для обеспечения параллельного запуска нескольких скриптов в процессе загрузки системы.

В новом выпуске:

  • В утилите «pidof» прекращена поддержка настройки форматирования вывода и удалён флаг «-f», так как связанный с форматированием код вызывал проблемы с безопасностью и потенциальные ошибки при работе с памятью. При необходимости изменения формата вывода теперь предлагается использовать опцию «-d» для определения разделителя и преобразование утилитами, подобными «tr»;
  • На стадии завершении работы теперь применяются миллисекундные задержки вместо приостановок на целую секунду (вместо do_sleep() вызывается do_msleep()). Изменение позволило в среднем на полсекунды сократить время завершения работы и перезапуска;
  • В документации более детально описано поведение утилиты halt и связанных с ней опций (-h, -H и -P);
  • Прекращено связывание с библиотекой sepol, которая больше не используется;
  • В insserv внесены изменения в сборочные файлы (Makefile). При установке insserv больше не перезаписывает файл с настройками insserv.conf, если он уже существует, а сохраняет рядом новый файл insserv.conf.sample.
  • Добавлена обработка файла /etc/insserv/file-filters, в котором можно указать список расширений (например, .git и .puppet)), которые будут игнорированы при обработке скриптов в /etc/init.d.
  • В insserv добавлена опция «-i» для указания альтернативного каталога с файлами определения зависимостей.
  • В insserv в проведена чистка тестового набора, перенесённого из Debian, и обеспечен его запуск при помощи команды «make check». Сбой при выполнении тестов теперь останавливает дальнейшую проверку и сохраняет статистику на диске для анализа проблемы. В ходе работы над тестовым набором выявлены различные проблемные ситуации, которые insserv может корректно обработать или обойтись выводом предупреждения. Например, insserv теперь ограничивается предупреждением, при наличии неопределяемой зависимости «$service» или при указании одного и того же runlevel в полях Default-Start и Default-Stop.
  • Команда startpar теперь устанавливается в каталог /bin, а не в /sbin, так как она может использоваться не только администратором, но и обычными пользователями. Отменён план переноса файлов учёта зависимостей из /etc в /var или /lib, так как могли возникнуть потенциальные проблемы при использовании сетевых ФС и нарушалась совместимость с некоторыми утилитами. В коде некоторые строки, проверяемые через sizeof(), заменены на константы.

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

Представлена новая техника скрытой идентификации системы и браузера

Группа исследователей из Грацского технического университета (Австрия), ранее известная разработкой методов атак MDS, NetSpectre и Throwhammer, раскрыла сведения о новой технике анализа по сторонним каналам, позволяющей определить точную версию браузера, используемую операционную систему, архитектуру CPU и применение дополнений для борьбы со скрытой идентификацией.

Для определения указанных параметров достаточно выполнения в браузере подготовленного исследователями JavaScript кода. На практике метод может применяться не только в качестве дополнительного источника для косвенной идентификации пользователя, но и для определения параметров системного окружения для целевого применения эксплоитов с учётом ОС, архитектуры и браузера. Метод эффективен в том числе при применении браузеров с реализацией механизмов блокировки скрытой идентификации, таких как Tor Browser. Исходные тексты прототипа кода с реализацией метода опубликованы под лицензией MIT.

Определение производится на основе выделения свойственных для разных браузеров шаблонов состояния свойств в JavaScript и характеристик времени выполнения операций, зависящих от особенностей работы JIT, CPU и механизмов выделения памяти. Определение свойств производится через генерацию списка всех объектов, доступных из JavaScript. Как оказалось число объектов напрямую коррелирует с браузерным движком и его версией.

     function getProperties(o) {        var result = [];        while (o !== null) {           result = result.concat(Reflect.ownKeys(o));           o = Object.getPrototypeOf(o);        }        return result;     }  

Например, для Firefox в документации заявлена поддержка 2247 свойств, в то время как реальное число определённых свойств с учётом недокументированных составляет 15709 (в Tor Browser — 15639), для Chrome заявлено 2698 свойств, а реально предлагается 13570 (в Chrome для Android — 13119). Число и значения свойств меняются от версии к версии браузера и при применении различных операционных систем.

Значения и наличие тех или иных свойств можно использовать для определения типа ОС. Например, в Kubuntu свойство window.innerWidth выставляется в значение 1000, а в Windows 10 — в 1001. В Windows доступно свойство window.navigator.activeVRDisplays, а в Linux его нет. Для Android предоставляется множество специфичных вызовов, но нет window.SharedWorker. Для идентификации операционной системы также предлагается использовать анализ параметров WebGL, состояние которых зависит от драйверов. Кроме того, вызов WEBGL_debug_renderer_infoextension позволяет получить информацию о движке отрисовки OpenGL, который для каждой операционной системы разный.

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

Определённые в ходе выполнения скрипта параметры сравниваются с эталонными значениями, свойственными для заранее протестированных окружений. В ходе проверки разработанная техника позволила точно определить 40 различных тестовых окружений, определив версии используемых браузеров, производителя CPU, применяемую операционную систему и факт запуска на реальном оборудовании или в виртуальной машине.

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

Из иных методов идентификации можно отметить учёт таких косвенных данных, как разрешение экрана, список поддерживаемых MIME-типов, специфичные параметры в заголовках (HTTP/2 и HTTPS), анализ установленных плагинов и шрифтов, доступность определённых Web API, специфичные для видеокарт особенности отрисовки при помощи WebGL и Canvas, манипуляции с CSS, анализ особенностей работы с мышью и клавиатурой.

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

Массовая атака на уязвимые почтовые серверы на основе Exim

Исследователи безопасности из компании Cybereason предупредили администраторов почтовых серверов о выявлении массовой автоматизированной атаки, эксплуатирующей критическую уязвимость (CVE-2019-10149) в Exim, выявленную на прошлой неделе. В ходе атаки злоумышленники добиваются выполнения своего кода с правами root и устанавливают на сервер вредоносное ПО для майнинга криптовалют.

В соответствии с июньским автоматизированным опросом доля Exim составляет 57.05% (год назад 56.56%), Postfix используется на 34.52% (33.79%) почтовых серверов, Sendmail — 4.05% (4.59%), Microsoft Exchange — 0.57% (0.85%). По данным сервиса Shodan потенциально уязвимыми остаются более 3.6 млн почтовых серверов в глобальной сети, которые не обновлены до последнего актуального выпуска Exim 4.92. Около 2 млн потенциально уязвимых серверов размещены в США, 192 тысячи в России.

Администраторам рекомендуется срочно установить обновления, которые ещё на прошлой неделе были подготовлены дистрибутивами (Debian, Ubuntu, openSUSE, Arch Linux, Fedora, EPEL для RHEL/CentOS). В случае наличия в системе поверженной уязвимости версии Exim (с 4.87 по 4.91 включительно) необходимо удостовериться, что система уже не скомпрометирована, проверив crontab на предмет подозрительных вызовов и убедиться в остутствии дополнительных ключей в каталоге /root/.ssh. Об атаке также может свидетельствовать наличие в логе межсетевого экрана активности с хостов an7kmd2wp4xo7hpr.tor2web.su, an7kmd2wp4xo7hpr.tor2web.io и an7kmd2wp4xo7hpr.onion.sh, которые используются для в процессе загрузки вредоносного ПО.

Первые попытки атаки на серверы Exim зафиксированы 9 июня. К 13 июля атака приняла массовый характер. После эксплуатации уязвимости через шлюзы tor2web со скрытого сервиса Tor (an7kmd2wp4xo7hpr) загружается скрипт, который проверяет наличие OpenSSH (если нет устанавливает), меняет его настройки (разрешает вход с root и аутентификацию по ключам) и устанавливает для пользователя root RSA-ключ, предоставляющий привилегированный доступ в систему через SSH.

После настройки бэкдора в систему устанавливается сканер портов для выявления других уязвимых серверов. Также осуществляется поиск в системе уже имеющихся систем майнинга, которые удаляются в случае выявления. На последнем этапе загружается и прописывается в crontab собственный майнер. Майнер загружается под видом ico-файла (на деле является zip-архивом с паролем «no-password»), в котором упакован исполняемый файл в формате ELF для Linux с Glibc 2.7+.

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

Google обосновал ограничение API webRequest, используемого блокировщиками рекламы

Разработчики браузера Chrome попытались обосновать прекращение поддержки блокирующего режима работы API webRequest, позволяющего менять принимаемый контент на лету и активно применяемого в дополнениях для блокирования рекламы, защиты от вредоносного ПО, фишинга, шпионящей за пользователями активности, родительского контроля и обеспечения приватности.

Мотивы Google:

  • Блокирующий режим работы API webRequest приводит к большому потреблению ресурсов. При использовании данного API браузер вначале отправляет дополнению все содержащиеся в сетевом запросе данные, дополнение анализирует их и возвращает для дальнейшей обработки в браузере изменённый вариант или выдаёт инструкции по блокировке. При этом основные задержки возникают не на стадии обработки трафика дополнением, а из-за накладных расходов на координацию выполнения дополнения. В частности, подобные манипуляции требуют запуска для дополнения отдельного процесса, а также применения IPC для взаимодействия с этим процессом и механизмов сериализации данных;
  • Дополнение полностью контролирует весь трафик на низком уровне, что открывает обширные возможности для злоупотреблений и нарушений приватности. По статистике Google в 42% всех выявленных вредоносных дополнений применялся API webRequest. Отмечается, что ежемесячно в каталоге Chrome Web Store блокируются попытки размещения в среднем 1800 вредоносных дополнений. К сожалению рецензирование не позволяет отлавливать все без исключения вредоносные дополнения, поэтому для усиления защиты было решено ограничить дополнения на уровне API. Основная идея в том, чтобы предоставлять дополнениям доступ не ко всему трафику, а только к тем данным, которые необходимы для реализации задуманной функциональности. В частности, для блокировки контента не обязательно предоставлять дополнению полный доступ ко всем конфиденциальным данным пользователя;
  • Предложенный на замену декларативный API declarativeNetRequest берёт на себя всю работу по высокопроизводительной фильтрации контента и лишь требует от дополнений загрузки правил фильтрации. Дополнение при этом не может вмешиваться в трафик и приватные данные пользователя остаются неприкосновенны;
  • Google учёл многие замечания в отношении недостаточной функциональности API declarativeNetRequest и расширил лимит на число правил фильтрации с изначально предложенных 30 тысяч до 150 тысяч, а также добавил возможности для динамического изменения и добавления правил, удаления и замены HTTP-заголовков (Referer, Cookie, Set-Cookie) и параметров запросов;
  • Для предприятий оставлена возможность использования блокирующего режима работы API webRequest, так как политику применения дополнений определяет администратор, который понимает особенности инфраструктуры и осознаёт риски. Например, указанный API может применяться на предприятиях для учёта потоков трафика сотрудников и интеграции с внутренними системами;
  • Целью Google является не ущемление и подавление дополнений для блокирования рекламы, а предоставление возможности создания более безопасных и производительных блокировщиков рекламы;
  • Нежелание оставить блокирующий режим работы API webRequest наряду с новым declarativeNetRequest объясняется желанием ограничить доступ дополнений к конфиденциальным данным. Если оставить API webRequest как есть, то большинство дополнений не будут использовать более безопасный declarativeNetRequest, так как обычно при выборе между безопасностью и функциональностью основная масса разработчиков выберет функциональность.

Возражения разработчиков дополнений:

  • Проведённые разработчиками дополнений тесты показывают ничтожное на общем фоне влияние на производительность дополнений для блокирования рекламы (при тестировании сравниваласть производительность различных дополнений, но без учёта накладных расходов для координации работы дополнительного процесса, координирующего выполнение обработчиков в блокирующем режиме API webRequest);
  • Нецелесообразно полностью прекращать поддержку API, активно используемого в дополнениях. Вместо удаления можно добавить отдельное разрешение и жёстко контролировать адекватность его применения в дополнениях, что позволило бы избавить авторов многих популярных дополнений от полной переработки их продуктов и избежать урезания функциональности;
  • Для снижения накладных расходов можно не удалять API, а переделать на основе механизма Promise, по аналогии с реализацией webRequest в Firefox;
  • Предложенная альтернатива declarativeNetRequest не покрывает всех потребностей разработчиков дополнений для блокирования рекламы и обеспечения безопасности/приватности, так как предоставляет полного контроля за сетевыми запросами, не позволяет использовать собственные алгоритмы фильтрации и не даёт возможность использовать сложные правила, перекрывающие друг друга в зависимости от условий;
  • Забота о приватности надумана, так как работающий в режиме только для чтения неблокирующий режим API webRequest оставлен и по-прежнему позволяет вредоносным дополнениям контролировать весь трафик, но не даёт возможность на лету вмешиваться в него (изменить содержимое, поставить свою рекламу, запустить майнеры и анализировать содержимое форм ввода можно и после окончания загрузки страницы).

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

CERN отказывается от продуктов Microsoft в пользу открытого ПО

Европейский Центр ядерных исследований (CERN) представил проект MAlt (Microsoft Alternatives), в рамках которого ведётся работа по уходу от применения продуктов Microsoft в пользу альтернативных решений на основе открытого ПО. Из ближайших планов отмечена замена «Skype for Business» на решение на базе открытого стека VoIP и запуск локального почтового сервиса для ухода от использования Outlook.

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

Решение по переходу на открытое ПО принято после изменения лицензионной политики Microsoft, которая на протяжении последних 20 лет предоставляла CERN программное обеспечение со значительными скидками для учебных учреждений. Недавно Microsoft отозвал с CERN статус академического учреждения и после завершения ныне действующего договора CERN потребуется оплачивать полную стоимость в привязке к числу пользователей. Расчёт показал, что затраты на покупку лицензий при новом раскладе увеличатся более чем в 10 раз.

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

Выпуск графического редактора GIMP 2.10.12

Представлен выпуск графического редактора GIMP 2.10.12, в котором продолжено оттачивание функциональности и повышение стабильности ветки 2.10.

Кроме исправления ошибок в GIMP 2.10.12 представлены следующие улучшения:

  • Значительно улучшен инструмент цветокоррекции при помощи кривых (Цвет / Кривые), а также другие компоненты, в которых для задания параметров используется корректировка кривых (например, при задании динамики раскрашивания и настройке устройств ввода). При перемещении существующей опорной точки, она теперь не перескакивает сразу в позицию курсора в момент нажатия кнопки, а смещается относительно текущей позиции при перемещении курсора при удерживании нажатой кнопки мыши. Данное поведение позволяет быстро выбирать точки кликом без их смещения и затем уже корректировать позицию. При попадании курсора на точку или при перемещении точки индикатор координат теперь отображает позицию точки, а не курсора.

    При удержании клавиши Ctrl в процессе добавления новой точки обеспечена привязка к кривой и сохранение оригинальных координат по оси Y, что удобно при добавлении новых точек без смещения кривой. В интерфейсе изменения цветовых кривых добавлены поля «Input» и «Output» для ручного ввода числовых координат точек. Точки на кривой теперь могут иметь тип сглаженных («smooth», по умолчанию как раньше) или угловых (corner, позволяют формировать острые углы на кривой). Угловые точки отображаются в форме ромба, а сглаженные как круглые точки.

  • Добавлен новый фильтр Offset (Layer > Transform > Offset) для смещения пикселей, что можно использовать для создания повторяющихся шаблонов;
  • Для изображений в формате TIFF добавлена поддержка слоёв (при экспорте теперь сохраняются отдельные слои без их объединения);
  • Для платформы Windows 10 добавлена поддержка шрифтов, установленных непривилегированным пользователем (без получения прав администратора);
  • Внесена оптимизация, позволившая не менять буфер отрисовки при каждом мазке, если цвета и пиксельная карта не изменяются. Кроме ускорения некоторых операций изменение также решило проблемы с динамикой цвета градиентов при наличии у изображения цветового профиля;
  • В инструменте осветвления-затемнения (Dodge/Burn) реализован инкрементальный режим, при котором изменения применяются поступательно следом за смещением курсора, по аналогии инкрементальным режимом в инструментах рисования кистями, карандашом и ластиком;
  • В инструменте свободного выделения (Free Select) реализовано создание выделения сразу после замыкания области с возможностью последующей корректировки контура (ранее выделение создавалось только после отдельного подтверждения клавишей Enter или двойным кликом);
  • В инструменте перемещения (Move) добавлена возможность связанного перемещения сразу двух направляющих через их перетаскивание по точке пересечения. Изменение полезно когда направляющие определяют не отдельные линии, а точку (например, для определения точки симметрии);
  • Устранены многие ошибки, приводящие к краху, аномалиями с кистями, проблемам с управлением цветами и появлению артефактов в режиме симметричной раскраски;
  • Подготовлены новые выпуски библиотек GEGL 0.4.16 и babl 0.1.66. Наиболее заметным является изменение коэффициента кубической дискретизации, что может применяться для выполнения более гладкой интерполяции. В GEGL также обновлён код для управления памятью, в котором обеспечена поддержка условного освобождения памяти из кучи с использованием вызова malloc_trim(), что стимулирует более активную отдачу неиспользуемой памяти операционной системе (например, после окончания редактирования большого изображения память системе теперь возвращается значительно быстрее).

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

Уязвимость в Vim, приводящая к выполнению кода при открытии вредоносного файла

В текстовых редакторах Vim и Neovim найдена уязвимость (CVE-2019-12735), позволяющая выполнить произвольный код при открытии специально оформленного файла. Проблема проявляется при активности включенного по умолчанию режима modeline («:set modeline»), который позволяет определить в обрабатываемом файле опции редактирования. Уязвимость устранена в выпусках Vim 8.1.1365 и Neovim 0.3.6.

Через modeline допускается установка только ограниченного числа опций. Если в качестве значения опции указывается выражение, то оно выполняется в режиме sandbox, допускающем применение только простейших безопасных операций. При этом в число допустимых входит команда «:source», в которой можно использовать модификатор «!» для запуска произвольных команд из указанного файла. Таким образом для выполнения кода достаточно указать в строке modeline конструкцию вида «set foldexpr=execute(‘:source! some_file’):». В Neovim вызов execute запрещён, но вместо него можно использовать assert_fails.

Например, для выполнения команды «uname -a» достаточно просто открыть в Vim или Neovim файл, в первой или последней строке которого указано:

     :!uname -a||" vi:fen:fdm=expr:fde=assert_fails("source! %"):fdl=0:fdt="  

Компанда «source! %» прочитает команды из текущего файла и, соответственно, выполнит «:!uname -a». Для скрытия данной строки от вывода утилитой cat могут использоваться escape-последовательности. Например, в данном прототипе эксплоита при открытии файла в vim создаётся сетевое соединение с shell-доступом на систему жертвы, но при этом данный файл не вызовет подозрений при выводе в терминал утилитой cat.

Проверить активность режима modeline можно командой «:set modeline?». Для отключения в vimrc можно добавить строку «set nomodeline». В дистрибутивах проблема устранена в RHEL, SUSE/openSUSE, Fedora, FreeBSD, Ubuntu и Arch Linux. Уязвимость остаётся неисправленной в Debian.

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

Уязвимости в MyBB, позволяющие захватить контроль над форумом

В движке для создания web-форумов MyBB выявлено несколько уязвимостей, позволяющих организовать многоступенчатую атаку для выполнения произвольного PHP-кода на сервере. Проблемы устранены в выпуске MyBB 1.8.21.

Первая уязвимость присутствует в модулях публикации и отправки приватных сообщений, и позволяет осуществить подстановку JavaScript-кода (XSS), который будет выполнен в браузере при просмотре публикации или полученного сообщения. Подстановка JavaScript возможна из-за некорректного преобразования в HTML вложенных BBCode. В частности, тег «[video]» преобразуются в iframe с передачей указанных в BBCode атрибутов. При этом «[video]» обрабатывается отдельно от остальных BBCode, что позволяет в имени видео использовать ещё один BBCode «[url]», который будет раскрыт после формирования iframe и из-за перекрытия двойных кавычек может подставить атрибут onLoad для подключения своего обработчика события.

Например, можно указать ссылку на видео в форме

  [video=youtube]youtube.com/xyz[url]http://onload=evilCode()[/url][/video]  

и она при обработке BBCode «[video]» будет преобразована в тег

  ‹iframe src="youtube.com/xyz[url]http://onload=evilCode()[/url]"›‹/iframe›  

, а после обработки остальных BBCode в

  ‹iframe src="youtube.com/xyz‹a href="http://onload=evilCode()"›.."›‹/iframe›  

Соответственно двойная кавычка в ‘href=»‘ закрывает атрибут «src» и onLoad обрабатывается в контексте iframe.

Вторая уязвимость позволяет при наличии прав администратора форума сохранить в файловую систему web-сервера PHP-скрипт и организовать его выполнение. Проблема присутствует в коде управления стилями для активной темы оформления, который позволяет генерировать новые CSS-файлы. Подобные файлы сохраняются с добавлением расширения «.css», но размер поля в БД с именем файла ограничен 30 символами. Соответственно можно назвать файл «26символов.php.css». При записи в БД будут отрезаны лишние символы и в конечном счёте сохранится имя «26символов.php». Далее через панель администратора форума можно сгенерировать новый стиль и файл будет записан в каталог «cache» с расширением php.

Для проведения атаки злоумышленник может направить администратору форума специально оформленное сообщение или опубликовать подобное сообщение форуме. При просмотре данного сообщения в браузере в рамках текущего сеанса в форуме и с правами просматривающего сообщение пользователя будет выполнен заданный атакующим JavaScript-код. Если сообщение просмотрел администратор, то для выполнения PHP-кода в контексте привилегированного сеанса эксплуатируется вторая уязвимость.

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

Выпуск децентрализованной коммуникационной платформы Matrix 1.0

Представлен первый стабильный релиз протокола для организации децентрализованных коммуникаций Matrix 1.0 и связанных с ним библиотек, API (Server-Server) и спецификаций. Сообщается, что не все задуманные возможности Matrix описаны и реализованы, но основной протокол полностью стабилизирован и достиг состояния, пригодного для использования в качестве основы для разработки независимых реализаций клиентов, серверов, ботов и шлюзов. Наработки проекта распространяются под лицензией Apache 2.0.

Одновременно, опубликован сервер для обмена сообщениями Synapse 1.0.0 с эталонной реализацией протокола Matrix 1.0. Отмечается, что основное внимание при подготовке Synapse 1.0 было уделено корректности реализации протокола, безопасности и надёжности. Synapse теперь вышел из стадии бета-тестирования и готов для повсеместного исользования. Код Synapse написан на языке Python и может использовать для хранения данных СУБД SQLite или PostgreSQL. Synapse 1.0 является последним выпуском с поддержкой Python 2.x.

По умолчанию для создания новых чатов применяется 4 версия протокола Room, но опционально доступа и пятая версия с поддержкой ограничения времени жизни серверных ключей. При переходе с прошлых выпусков следует иметь в виду, что для подключения к общей децентрализованной сети теперь требуется получение корректного TLS-сертификата. В качестве клиентов можно использовать Riot (доступен для Linux, Windows, macOS, Web, Android и iOS), Weechat (CLI на Lua), nheko (С++/Qt), Quaternion (С++/Qt) и Fractal (Rust/GTK).

Из ещё не стабилизированных в Matrix 1.0 возможностей упоминаются редактирование отправленных сообщений (поддерживается в Synapse 1.0 и Riot, но не включено по умолчанию), реакции, нитевидные обсужления, перекрёстная верификация пользователей, Live-статистика по чатам. Из предстоящих работ в реализации сервера планируется провести оптимизацию производительности и снизить потребление памяти. Помимо эталонного сервера на языке Python также развиваются экспериментальные реализации Ruma (Rust) и Dendrite (Go).

Платформа для организации децентрализованных коммуникаций Matrix развивается как проект, использующий открытые стандарты и уделяющий большое внимание обеспечению безопасности и приватности пользователей. Matrix обеспечивает сквозное (end-to-end) шифрование на базе собственного протокола, использующего в том числе алгоритм Double Ratchet (часть протокола Signal). Оконечное шифрование применяется как при прямом обмене сообщениями, так и в чатах (применяется механизм Megolm). Реализация методов шифрования прошла аудит в организации NCC Group. В качестве транспорта применяется HTTPS+JSON с возможностью использования WebSockets или протокола на базе CoAP+Noise.

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

В сети отсутствует единая точка отказа или контроля за сообщениями. Все серверы, которые охватывает обсуждение, равноправны между собой. Любой пользователь может запустить собственный сервер и подключить его к общей сети. Возможно создание шлюзов для взаимодействия Matrix с системами на базе других протоколов, например, подготовлены сервисы для двусторонней отправки сообщений в IRC, Facebook, Telegram, Skype, Hangouts, Email, WhatsApp и Slack.

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

Для координирования разработки проекта на днях создана некоммерческая организация Matrix.org Foundation, которая будет гарантировать независимость проекта, развивать связанные с Matrix стандарты и выступать в роли нейтральной площадки для совместного принятия решений. Во главе Matrix.org Foundation поставлен совет из пяти директоров, не связанных с коммерческой экосистемой, пользующихся авторитетом в сообществе и призванных отстаивать миссию проекта.

В число директоров вошли Джон Кроукрофт (Jon Crowcroft, один из пионеров децентрализованных коммуникаций), Мэтью Ходжсон (Matthew Hodgson, сооснователь Matrix), Амандина Ле Папе (Amandine Le Pape, сооснователь Matrix), Росс Шульман (Ross Schulman, юрист из Open Technology Institute, специализирующийся на интернете и децентрализованных ситемах), Юта Штайнер (Jutta Steiner, сооснователь компании Parity Technologies, занимающейся технологиями на базе блокчейна).

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

Выпуск Mesa 19.1.0, свободной реализации OpenGL и Vulkan

Опубликован релиз свободной реализации API OpenGL и Vulkan — Mesa 19.1.0. Первый выпуск ветки Mesa 19.1.0 имеет экспериментальный статус — после проведения окончательной стабилизации кода будет выпущена стабильная версия 19.1.1. В Mesa 19.1 предоставляется полная поддержка OpenGL 4.5 для драйверов i965, radeonsi и nvc0, поддержка Vulkan 1.1 для карт Intel и AMD, а также частичная поддержка стандарта OpenGL 4.6.

Наиболее заметные изменения:

  • В состав включён разработанный в компании Intel новый драйвер Iris. В отличие от i965 новый драйвер основан на архитектуре Gallium3D, выносящей задачи управления памятью на сторону DRI-драйвера в ядре Linux и предоставляющей готовый трекер состояний с поддержкой кэша повторного использования выводимых объектов. Новый драйвер поддерживает только GPU на базе микроархитектуры Gen8+ (Broadwell, Skylake) c GPU HD, UHD и Iris.

    В тестах производительности драйвер Iris от 3 до 15 раз обгоняет i965, в зависимости от режима тестирования. В среднем Iris демонстрирует отрисовку в 5.45 раз большего числа объектов в секунду, чем драйвер i965. При выполнении реальных программ прирост не столь внушителен (в одной из демонстраций прирост около 19%, а в некоторых демонстрациях примерно равен i965).

  • В классическом драйвере i965 расширена поддержка чипов Gen 11 и добавлена поддержка графической подсистемы SoC Elkhart Lake;
  • В состав включён драйвер Lima для GPU Mali 400/450, применяемого во многих старых чипах на основе архитектуры ARM.
  • Добавлен драйвер Panfrost для GPU на базе микроархитектур Midgard (Mali-T6xx, Mali-T7xx, Mali-T8xx) и Bifrost (Mali G3x, G5x, G7x), используемых на многих устройствах с процессорами ARM.
  • В драйвер RADV (Vulkan-драйвер для карт AMD) добавлена поддержка технологии VESA Adaptive-Sync (FreeSync), позволяющей адаптивно менять частоту обновления монитора для обеспечения плавного вывода и отсутствия разрывов;
  • Добавлен новый Vulkan-драйвер TURNIP для GPU Qualcomm Adreno;
  • В драйвер Softpipe (программный растеризатор на базе Gallium3D) добавлена поддержка расширений OpenGL 4: ARB_gpu_shader5, ARB_ES3_1_compatibility, OES_geometry_shader, OES_primitive_bounding_box, OES_texture_cube_map_array и OES_viewport_array. До полной поддержки OpenGL 4.0 остаётся реализовать расширения GL_ARB_gpu_shader5, GL_ARB_sample_shading и GL_ARB_tessellation_shader;
  • Добавлена поддержка формата сжатия текстур ATC, используемого в GPU Qualcomm и AMD;
  • Увеличена производительность трекера состояний Gallium Nine, обеспечивающего поддержку API Direct3D 9 для Unix-подобных систем и обычно применяемого для запуска Windows игр с исполльзованием Wine;
  • Добавлены новые расширения OpenGL:
  • В Vulkan-драйвер ANV (для карт Intel) добавлены расширения:
  • В Vulkan-драйвер RADV (для карт AMD) добавлен набор расширений:

Дополнительно можно отметить добавление в ветку, которая ляжет в основу выпуска Mesa 19.2, реализации расширения GL_KHR_robustness для Gallium3D драйвера R600, которое было последним недостающим звеном для обеспечения поддержки OpenGL 4.5. Таким образом R600 стал четвёртым драйвером Mesa с поддержкой OpenGL 4.5. Поддержка OpenGL 4.5 в R600 доступна только для GPU Radeon HD 5800/6900.

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