Выпуск композитного сервера Weston 8.0

Опубликован стабильный релиз композитного сервера Weston 8.0, развивающего технологии, содействующие появлению полноценной поддержки протокола Wayland в Enlightenment, GNOME, KDE и других пользовательских окружениях. Разработка Weston нацелена на предоставление высококачественной кодовой базы и рабочих примеров для использования Wayland в десктоп-окружениях и встраиваемых решениях, таких как платформы для автомобильных информационно-развлекательных систем, смартфонов, телевизоров и прочих потребительских устройств. Выпуск протокола, механизма межпроцессного взаимодействия и библиотек Wayland 1.18 намечен на 11 февраля.

Смена значительного номера версии Weston обусловлена изменениями ABI, нарушающими совместимость. Изменения в новой ветке Weston:

  • Повышена эффективность задействования в DRM (Direct Rendering Manager) аппаратных механизмов манипуляции с регионами памяти, используемыми для хранения компонентов фреймбуфера (hardware planes);
  • В бэкенд DRM, используемый для организации вывода через подсистемы ядра DRM (Direct Rendering Manager), KMS (Kernel Mode Setting) и evdev, добавлена поддержка технологии защиты от копирования звукового и видеоконтента HDCP, которая используется для шифрования видеосигнала, передаваемого через интерфейсы DVI, DisplayPort, HDMI, GVIF или UDI;
  • В gl-renderer добавлена блокировка захвата, предоставления совместного доступа и создания скриншотов областей, в которых отображается защищённый от копирования контент;
  • В бэкенд headless, применяемый для рендеринга без экрана, добавлена поддержка отрисовки в буфер с использованием OpenGL (добавлена опция «—use-gl»), что позволяет получить виртуальное изображение экрана в памяти, которое можно передать удалённому клиенту;
  • В бэкенде вывода через подсистему DRM (Direct Rendering Manager) добавлена возможность сборки без привязки к библиотеке GBM (Generic Buffer Manager), предлагаемой в Mesa для управления выделением буферов отрисовки. Вместо форматов GBM задействованы форматы FourCC, применяемые в подсистеме DRM;
  • Для сокращения нагрузки на память в некоторых GPU по возможности теперь всегда применяется EGL-расширение EGL_KHR_partial_update, позволяющее выборочно обновлять содержимое поверхностей, пропуская области, в которых не было изменений;
  • Расширены возможности фреймворка для ведения отладочных логов;
  • В gl-renderer добавлена поддержка формата XYUV;
  • В оконном менеджере xwm реализован контроль за выводом изменений на поверхность Wayland при работе Xwayland, который позволил избавиться от артефактов при декорировании окон X11-приложений, запускаемых в окружении на базе Wayland;
  • Снижено потребление памяти при отображении однородного фона рабочего стола за счёт применения буфера 1×1 для всего viewport-а;
  • Добавлена поддержка расширения weston-direct-display, позволяющего организовать передачу содержимого dmabuf напрямую в контроллер экрана.

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

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

Исследователи из Мэрилендского университета в рамках проекта Geneva предприняли попытку создания движка для автоматизации определения методов, применяемых для цензурирования доступа к контенту. Вручную пытаться перебрать возможные бреши систем глубокого инспектирования пакетов (DPI) достаточно трудный и долгий процесс, в Geneva попытались использовать генетический алгоритм для оценки особенностей DPI, определения ошибок в реализации и выработки оптимальной стратегии обхода блокировки на стороне клиента. Код проекта написан на языке Python.

Применяемое для блокировки DPI-оборудование имеет свои недоработки, позволяющие скрыть обращение к запрещённому ресурсу или избежать блокировки. Например, в простейшем случае при организации блокировки через подстановку фиктивного ответа достаточно на стороне клиента отбросить фиктивный ответ, отправленный DPI. В других ситуациях можно скрыть от DPI сам факт обращения к заблокированному сайту, немного видоизменив параметры HTTP-запроса (например, добавив лишний пробел после «GET»), разделив на несколько пакетов данные согласования TLS-соединения или выполнив атаки TCB Teardown и TCB Desync. Суть упомянутых атак в отправке клиентом вначале фиктивного пакета с данными или флагами RST/ACK, который не получит целевой хост, но поймает DPI, примет на его основе решение и не станет анализировать идущий следом пакет с реальным запросом (для скрытия первого пакета от целевого хоста можно выставить низкий TTL, а также некорректную контрольную сумму, флаги или номер последовательности TCP).

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

align=top

Работа Geneva успешно опробована для обхода методов цензурирования, применяемых в Китае, Индии и Казахстане, в том числе при помощи Geneva было выявлено несколько новых брешей, о которых не было известно до этого. При этом Geneva эффективен только для обхода блокировок на основе DPI, при блокировании по IP-адресам он бесполезен и без VPN не обойтись. В ходе экспериментов выявлено несколько десятков типовых стратегий обхода DPI, которые можно протестировать сразу без проведения полного анализа, например:

     python3 engine.py --server-port 80 --strategy "[TCP:flags:PA]-duplicate(tamper{TCP:dataofs:replace:10} tamper{TCP:chksum:corrupt},),)-|" --log debug       2020-01-24 20:54:41 DEBUG:[ENGINE] Engine created with strategy / (ID bm3kdw3r) to port 80     2020-01-24 20:54:41 DEBUG:[ENGINE] Configuring iptables rules     2020-01-24 20:54:41 DEBUG:[ENGINE] iptables -A OUTPUT -p tcp --sport 80 -j NFQUEUE --queue-num 1     2020-01-24 20:54:41 DEBUG:[ENGINE] iptables -A INPUT -p tcp --dport 80 -j NFQUEUE --queue-num 2     2020-01-24 20:54:41 DEBUG:[ENGINE] iptables -A OUTPUT -p udp --sport 80 -j NFQUEUE --queue-num 1     2020-01-24 20:54:41 DEBUG:[ENGINE] iptables -A INPUT -p udp --dport 80 -j NFQUEUE --queue-num 2  

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

Релиз СУБД SQLite 3.31 с поддержкой генерируемых столбцов

Опубликован релиз SQLite 3.31.0, легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg.

Основные изменения:

  • Добавлена поддержка генерируемых столбцов (вычисляемых столбцов), позволяющих при создании таблицы определить столбец, значение которого автоматически вычисляется на основе содержимого другого столбца. Генерируемые столбцы могут быть как виртуальными (формируемыми на лету при каждом обращении), так и сохраняемыми в БД (сохраняются при каждом обновлении связанных столбцов). Содержимое генерируемых столбцов доступно только в режиме чтения (изменение производится только через модификацию значения в другом столбце, задействованном при вычислении). Например:
         CREATE TABLE t1(        a INTEGER PRIMARY KEY,        b INT,        c TEXT,        d INT GENERATED ALWAYS AS (a*abs(b)) VIRTUAL,        e TEXT GENERATED ALWAYS AS (substr(c,b,b+1)) STORED     );  
  • Добавлены PRAGMA trusted_schema, настройка SQLITE_DBCONFIG_TRUSTED_SCHEMA и сборочная опция «-DSQLITE_TRUSTED_SCHEMA», позволяющие управлять включением защиты от атак через модификацию схемы данных в БД. При активной защите ограничивается использование SQL-функций (не помеченных как SQLITE_INNOCUOUS) в триггерах, представлениях, выражениях CHECK и DEFAULT, индексах и генерируемых столбцах. Также отключается использование виртуальных таблиц в триггерах и представлениях, если виртуальная таблица явно не объявлена с флагом SQLITE_VTAB_INNOCUOUS.
  • Реализована возможность присвоения определённым в приложениях SQL-функциям свойств SQLITE_INNOCUOUS (безобидные функции, которые не зависят от внешних параметров и не могут использоваться для совершения вредоносных действий) и SQLITE_DIRECTONLY (только прямой вызов в SQL-запросах, без возможности применения в триггерах, представлениях и схемах структуры данных);
  • Добавлен модуль uuid с реализацией функций для обработки UUID ( RFC-4122);
  • Добавлена PRAGMA hard_heap_limit и функция sqlite3_hard_heap_limit64() для управления максимальным размером кучи;
  • В PRAGMA function_list добавлен вывод типа, свойств и числа аргументов каждой функции;
  • В виртуальную таблицу DBSTAT добавлен режим агрегирования данных;
  • В sqlite3_open_v2() реализована опция SQLITE_OPEN_NOFOLLOW, позволяющая запретить открытие символических ссылок;
  • Для аргумента PATH, передаваемого в JSON-функции, добавлена поддержка нотации массивов «#-N»;
  • В системе распределения памяти lookaside реализована поддержка двух отдельных пулов памяти, каждый из которых может использоваться для выделения блоков разного размера (разделение позволяет расширить применение системы lookaside, при этом снизив размер выделяемого на каждое соединение буфера со 120 до 48 КБ);
  • Прекращена поддержка PRAGMA legacy_file_format, которая была несовместима с VACUUM, генерируемыми столбцами и убывающими индексами (поддержку устаревшего формата можно вернуть через флаг SQLITE_DBCONFIG_LEGACY_FILE_FORMAT в sqlite3_db_config()).

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

Intel выпустил движок распределённой трассировки лучей OSPRay 2.0

Компания Intel представила значительный выпуск масштабируемого движка 3D-рендеринга OSPRay 2.0, предназначенного для реалистичной высококачественной визуализации методом трассировки лучей, пригодной для применения в интерактивных приложениях. Движок развивается как часть более крупного проекта Intel Rendering Framework, нацеленного на разработку средств программной визуализации научных расчётов SDVis (Software Defined Visualization), включающих библиотеку трассировки лучей Embree, систему фотореалистичной отрисовки GLuRay, библиотеку для устранения шумов на изображениях oidn (Open Image Denoise) и систему программной растеризации OpenSWR. Код написан на языке С++ и опубликован под лицензией Apache 2.0.

OSPRay нацелен главным образом на использование в интерактивных приложениях для отрисовки сцены на лету. Для симуляции поведения света применяется метод трассировки пути. Поддерживается визуализация в объёме и на плоскости, фотореалистичное глобальное освещение с учётом физических свойств материалов, расширенные эффекты затенения (тени, прозрачность и затенение «Ambient occlusion«).

OSPRay использует только возможности CPU, не привязываясь к GPU, что позволяет использовать библиотеку на широком спектре устройств, от рабочих станций до узлов в вычислительных кластерах. Для обеспечения должной производительности активно используется многопоточность и векторизация на базе SIMD-инструкций, таких как Intel SSE4, AVX, AVX2, и AVX-512 (для работы OSPRay как минимум требуется поддержка SSE4.1).

Рендернг может быть распределён на несколько узлов кластера (поддерживается MPI), что например, позволяет применять OSPRay для организации отрисовки картинки с очень высоким разрешением на видеостенах, единое изображение на которых формируется набором отдельных LCD-панелей. Например, работа OSPRay продемонстрирована на составном экране Stallion, скомпонованном из 80 30-дюймовых мониторов (общее разрешение 40960×8000 или 328 мегапикселей) и обслуживаемого кластером из 40 серверов с 6-ядерными CPU на базе микроархитектуры Intel Sandy Bridge.

Значительное изменение номера версии обусловлено большой переработкой API, в том числе с внесением изменений, нарушающих совместимость (для упрощения перехода на новый API предложена библиотека-прослойка, сглаживающая миграцию), и предоставлением новых геометрических типов. Добавлена поддержка Open VKL (Open Volume Kernel Library) для объёмного рендеринга. Реализована возможность подключения модуля для подавления шумов на изображении. В отдельные репозитории вынесены библиотека ospcommon и модуль для поддержи MPI.

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

Открыт код клиентских приложений ProtonVPN

Компания Proton Technologies, развивающая защищённый почтовый сервис и VPN, объявила об открытии исходных текстов клиентских программ ProtonVPN для Windows, macOS, Android и iOS (консольный Linux-клиент открыт изначально). Код открыт под лицензией GPLv3. Одновременно опубликованы отчёты о проведении независимого аудита указанных приложений. Проблем, которые могут привести к расшифровке VPN-трафика или повышению привилегий, в ходе аудита не найдено.

Код открыт в рамках инициативы по обеспечению прозрачности проекта для того, чтобы независимые эксперты могли убедиться в соответствии кода заявленным спецификациям и проконтролировать корректность проведения аудита безопасности. В рамках сотрудничества с Mozilla, которая развивает платный VPN-сервис, для аудита инженерам Mozilla также был открыт доступ и к другим технологиям ProtonVPN. Отмечается, что следующим шагом станет перевод в разряд открытых и остальных приложений ProtonVPN.

Из ранее происходивших инцидентов с ProtonVPN можно отметить выявление уязвимости в приложении для Windows, позволявшей пользователю поднять свои привилегии в системе до администратора (уязвимость была вызвана некорректным взаимодействием между непривилегированным GUI-клиентом и системным сервисом).

Завершившийся несколько дней назад аудит кода приложения для Windows выявил наличие 4 уязвимостей (две средней степени опасности и две незначительные): хранение в сессионных токенов и учётных данных в памяти процесса, предопределённые в файле конфигурации ключи VPN-сервера (не используются для аутентификации), включение отладочной информации и приём соединений на всех сетевых интерфейсах.

В версии для macOS уязвимостей не выявлено. В версии для iOS найдены две незначительные уязвимости (не используется привязка SSL-сертификата и не блокируется работа на устройствах после jailbreak). В версии для Android найдено четыре незначительные проблемы (включение отладочных сообщений, отсутствие блокировки бэкапа при помощи утилиты ADB, шифрование настроек предопределённым ключом, отсутствие привязки SSL-сертификата) и одна уязвимость средней степени опасности (неполное завершение сеанса, допускающее повторное использование сессионных токенов).

Напомним, что компания Proton Technologies основана несколькими исследователями из ЦЕРН (Европейская организация по ядерным исследованиям) и зарегистрирована в Швейцарии, имеющей жёсткое законодательство в области защиты частной жизни, не позволяющее спецслужбам контролировать информацию. Проект ProtonVPN обеспечивает высокий уровень защиты канала связи (поток шифруется при помощи AES-256, обмен ключами осуществляется на основе 2048-битных RSA-ключей и HMAC, для аутентификации используется SHA-256, имеется защита от атак, основанных на корреляции потоков данных), отказывается от ведения логов и ориентирован не на получение прибыли, а на повышение безопасности и приватности в Web (проект финансируется фондом FONGIT, поддерживаемым Еврокомиссией).

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

Технический комитет OASIS утвердил спецификацию OpenDocument 1.3

Технический комитет консорциума OASIS утвердил финальный вариант спецификации ODF 1.3 (OpenDocument). После утверждения в техническом комитете спецификация ODF 1.3 получила статус «Committee Specification», что подразумевает полное завершение работы, будущую неизменность спецификации и готовность документа для использования сторонними разработчиками и компаниями. Следующим этапом станет утверждение представленной спецификации на роль стандарта OASIS и ISO/IE.

Ключевым отличиями OpenDocument 1.3 от прошлой редакции спецификации стало включение новых возможностей для обеспечения защиты документов, таких как заверение документа цифровой подписью и шифрование содержимого c использованием ключей OpenPGP. В новую версию также внесены уточнения формулировок и расширены некоторые уже доступные возможности, например:

  • Добавлена поддержка типов полиномиальной и скользящей средней регрессии для графиков;
  • Реализованы дополнительные методы форматирования цифр в числах;
  • Добавлен отдельный тип верхних и нижних колонтитулов для заглавной страницы;
  • Определены средства расстановки отступов параграфов в зависимости от контекста;
  • Предложены дополнительные аргументы для функции WEEKDAY;
  • Добавлен новый тип шаблона для основного текста в документах.

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

Спецификации состоят из четырёх частей:

  • Часть 1, описывает общую схему ODF;
  • Часть 2, описывает спецификацию OpenFormula (формулы для электронных таблиц);
  • Часть 3, описывает модель упаковки данных в ODF-контейнер.
  • Часть 4, определяет формат описания формул OpenFormula

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

Стабильный релиз Wine 5.0

После года разработки и 28 экспериментальных версий представлен стабильный релиз открытой реализации Win32 API — Wine 5.0, который вобрал в себя более 7400 изменений. Из ключевых достижений новой версии отмечается поставка встроенных модулей Wine в формате PE, поддержка многомониторных конфигураций, новая реализация звукового API XAudio2 и поддержка графического API Vulkan 1.1.

В Wine подтверждена полноценная работа 4869 (год назад 4737) программ для Windows, еще 4136 (год назад 4045) программ прекрасно работают при дополнительных настройках и внешних DLL. У 3635 программ наблюдаются небольшие проблемы в работе, которые не мешают использованию основных функций приложений.

Ключевые новшества Wine 5.0:

  • Модули в формате PE
    • При наличии компилятора MinGW большинство модулей Wine теперь собираются в формате исполняемых файлов PE (Portable Executable, применяется в Windows) вместо ELF. Применение PE решает проблемы с поддержкой различных схем защиты от копирования, осуществляющих сверку идентичности системных модулей на диске и в памяти;
    • Исполняемые файлы PE теперь копируются в каталог ~/.wine ($WINEPREFIX) вместо применения фиктивных DLL-файлов, что делает начинку более похожей на реальные установки Windows, ценой потребления дополнительного дискового пространства;
    • Модули, преобразованные в формат PE, могут использовать штатные wchar Си-функций и константы с юникодом (например, L»abc»);
    • В Wine C runtime добавлена поддержка связывания с двоичными файлами, собранными в MinGW, которая при сборке DLL используется по умолчанию вместо MinGW runtime;
  • Графическая подсистема
    • Добавлена поддержка работы с несколькими мониторами и графическими адаптерами, включая возможность динамического изменения настроек;
    • Обновлён драйвер для графического API Vulkan, который приведён в соответствие со спецификацией Vulkan 1.1.126;
    • В библиотеке WindowsCodecs реализована возможность преобразования дополнительных растровых форматов, включая форматы с индексированной палитрой;
  • Direct3D
    • При выполнении полноэкранных приложений Direct3D обеспечена блокировка вызова хранителя экрана;
    • В DXGI (DirectX Graphics Infrastructure) добавлена поддержка информирования приложения о минимизации его окна, что позволяет приложению снизить выполнение ресурсоёмких операций при сворачивании окна;
    • Для приложений, использующих DXGI, реализована возможность переключения между полноэкранным и оконным режимом при помощи комбинации Alt+Enter;
    • Расширены возможности реализации Direct3D 12, например, появилась поддержка переключения между полноэкранным и оконным режимом, изменения режимов экрана, вывода с масштабированием и управления интервалом замены буферов отрисовки (swap interval);
    • Улучшена обработка различных пограничных ситуаций, таких как применение выходящих за допустимые диапазоны исходных значений для тестов прозрачности и глубины, отрисовка с отражёнными текстурами и буферами, использование некорректных DirectDraw объектов clipper, создание устройств Direct3 для некорректных окон, использование видимых областей, минимальные значения параметров которых равны максимальным и т.п.
    • В Direct3D 8 и 9 обеспечено более точное отслеживание «грязных» областей загружаемых текстур;
    • Снижен размер необходимого адресного пространства при загрузке 3D-текстур, сжатых методом S3TC (вместо загрузки целиком, текстуры грузятся кусками).
    • Реализован интерфейс ID3D11Multithread для защиты критических секций в многопоточных приложениях;
    • Для старых приложений DirectDraw внесены различных улучшения и исправления, связанных с расчётом освещения;
    • Реализованы дополнительные вызовы для получения информации о шейдерах в API ShaderReflection;
    • В wined3d добавлена поддержка блиттера на базе CPU для обработки сжатых ресурсов;
    • Расширена БД графических карт, распознаваемых в Direct3D;
    • Добавлены новые ключи реестра HKEY_CURRENT_USERSoftwareWineDirect3D: «shader_backend» (бэкенд для работы с шейдерами: «glsl» для GLSL, «arb» для ARB vertex/fragment и «none» для отключения поддержки шейдеров), «strict_shader_math» (0x1 — включить, 0x0 — отключить преобразование шейдеров Direct3D). Объявлен устаревшим ключ «UseGLSL» (следует использовать «shader_backend»);
  • D3DX
    • Реализована поддержка механизма сжатия 3D-текстур S3TC (S3 Texture Compression);
    • Добавлены корректные реализации таких операций, как заливка текстурой и неотражаемые (unmappable) поверхности;
    • Внесены различные улучшения и исправления во фреймворк создания визуальных эффектов;
  • Ядро (интерфейсы ядра Windows)
    • Большинство функций, используемых в Kernel32, перемещены в KernelBase, следуя изменениям в архитектуре Windows;
    • Возможность смешивания 32- и 64-разрядных DLL в каталогах, используемых для загрузки. Обеспечено игнорирование библиотек, не соответствующих текущей разрядности (32/64), на случай если далее в пути удастся найти корректную для текущей разрядности библиотеку;
    • Для драйверов устройств улучшена эмуляция объектов ядра;
    • Реализованы работающие на уровне ядра объекты синхронизации, такие как spin-блокировки, быстрые мьютексы и прикрепляемые к ресурсу переменные;
    • Обеспечено корректное информирование приложений о состоянии аккумулятора;
  • Интерфейс пользователя и интеграция с рабочим столом
    • Минимизированные окна теперь отображаются с использованием заголовка, а не пиктограммы в стиле Windows 3.1;
    • Добавлены новые стили кнопок SplitButton (кнопка с выпадающим списком действий) и Command Links (ссылки в диалоговых окнах, используемых для перехода на следующую стадию);
    • Для папок ‘Downloads’ и ‘Templates’ созданы символьные ссылки, указывающие на соответствующие каталоги в Unix-системах;
  • Устройства ввода
    • При запуске обеспечена установка и загрузка необходимых драйверов устройств Plug & Play;
    • Улучшена поддержка игровых контроллеров, включая мини-джойстик (hat switch), руль, педали для газа и тормозов.
    • Прекращена поддержка старого Linux API взаимодействия с джойстиками, используемого в ядрах Linux до версии 2.2;
  • .NET
    • Движок Mono обновлён до выпуска 4.9.4 и теперь включает части фреймворка Windows Presentation Foundation (WPF);
    • Добавлена возможность установки дополнений с Mono и Gecko в один общий каталог с размещением файлов в иерархии /usr/share/wine вместо копирования в новые префиксы;
  • Сетевые возможности
    • Браузерный движок Wine Gecko, который используется в библиотеке MSHTML, обновлён до выпуска 2.47.1. Реализована поддержка новых HTML API;
    • В MSHTML реализована поддержка элементов SVG;
    • Добавлено много новых функций VBScript (например, обработчики ошибок и исключений, функции Hour, Day, Month, String, LBound, RegExp.Replace, РScriptTypeInfo_* и ScriptTypeComp_Bind* и т.п.);
    • Обеспечено сохранение состояния кода в VBScript и JScript (script persistence);
    • Добавлена начальная реализация сервиса HTTP (WinHTTP) и связанного с ним API (HTTPAPI) для клиентских и серверных приложений, отравляющих и принимающих запросы при помощи протокола HTTP;
    • Реализована возможность получения параметров настройки HTTP-прокси чрез DHCP;
    • Добавлена поддержка перенаправления запросов аутентификации через службу Microsoft Passport;
  • Криптография
    • Реализована поддержка криптографических ключей на основе эллиптических кривых (ECC) при использовании GnuTLS;
    • Добавлена возможность импорта ключей и сертификатов из файлов в формате PFX;
    • Добавлена поддержка схемы формирования ключа на основе пароля PBKDF2;
  • Текст и шрифты
    • В реализации API DirectWrite добавлена поддержка возможностей OpenType, связанных с позиционированием глифов, которые включены по умолчанию для начертания Latin, включая кернинг;
    • Повышена безопасность обработки шрифтовых данных за счёт проверки корректности различных таблиц данных перед их использованием;
    • Интерфейсы DirectWrite приведены в соответствие со свежим SDK;
  • Звук и видео
    • Предложена новая реализация звукового API XAudio2, построенная на основе проекта FAudio. Использование FAudio в Wine позволяет добиться более высокого качества звука в играх и задействовать такие возможности как смешивание громкости и расширенные звуковые эффекты;
    • Добавлено большое число новых вызовов в реализацию фреймворка Media Foundation, включая поддержку встроенных и пользовательских асинхронных очередей, Source Reader API, Media Session и т.п.
    • Фильтр захвата видео переведён на использование API v4l2 вместо v4l1 API, что позволило расширить диапазон поддерживаемых камер;
    • Удалены встроенные декодировщики AVI, MPEG-I и WAVE, вместо которых теперь используются системные GStreamer или QuickTime;
    • Добавлено подмножество конфигурационных API VMR7;
    • В звуковые драйверы добавлена поддержка настройки громкости отдельных каналов;
  • Интернационализация
    • Таблицы Unicode обновлены до версии 12.1.0;
    • Реализована поддержка нормализации Unicode;
    • Обеспечена автоматическая установка географического региона (HKEY_CURRENT_USERControl PanelInternationalGeo) на основе текущей локали;
  • RPC/COM
    • В typelib добавлена поддержка сложных структур и массивов;
    • Добавлена начальная реализация runtime-библиотеки Windows Script;
    • Добавлена начальная реализация библиотеки ADO (Microsoft ActiveX Data Objects);
  • Установщики
    • Для установщика MSI реализована поддержка поставки патчей (Patch Files);
    • В утилите WUSA (Windows Update Standalone Installer) появилась возможность установки обновлений в формате .MSU;
  • Платформа ARM
    • Для архитектуры ARM64 в ntdll добавлена поддержка раскрутки стека (stack unwinding). Добавлена поддержка подключения внешних библиотек libunwind;
    • Для архитектуры ARM64 реализована поддержка бесшовных прокси (stubless proxies) для интерфейсов объектов;
  • Инструменты для разработки / Winelib
    • Добавлена возможность применения отладчика из Visual Studio для удалённой отладки приложений, запущенных в Wine;
    • Частично реализована библиотека DBGENG (Debug Engine);
    • Собранные для Windows исполняемые файлы больше не зависят от libwine, что позволяет запускать их в Windows без дополнительных зависимостей;
    • В Resource Compiler и IDL Compiler добавлена опция ‘—sysroot’ для определения пути размещения заголовочных файлов;
    • В winegcc добавлены опции ‘—target’, ‘—wine-objdir’, ‘—winebuild’ и ‘-fuse-ld’, упрощающие настройку окружения для кросс-компиляции;
  • Встроенные приложения
    • Реализована утилита CHCP для настройки кодировки консоли;
    • Реализована утилита MSIDB для манипуляции с базами в формате MSI;
  • Оптимизация производительности
    • Различные функции работы со временем переведены на использование высокопроизводительных системных функций работы с таймером, что позволило снизить накладные расходы в цикле отрисовки многих игр;
    • Добавлена возможность использования в ФС Ext4 режима работы без учёта регистра символов;
    • Проведена оптимизация производительности обработки большого числа элементов в диалогах вывода списков, работающих в режиме LBS_NODATA;
    • Добавлена более быстрая реализация SRW-блокировок (Slim Reader/Writer) для Linux, переведённая на Futex;
  • Внешние зависимости
    • Для сборки модулей в формате PE задействован кросс-компилятор MinGW-w64;
    • Реализация XAudio2 требует наличия библиотеки FAudio;
    • Для отслеживания изменений файлов на системах BSD задействована библиотека Inotify;
    • Для обработки исключений на платформе ARM64 необходима библиотека Unwind;
    • Вместо Video4Linux1 теперь требуется библиотека Video4Linux2.

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

Red Hat развивает JIT-компилятор MIR

В компании Rad Hat ведётся разработка нового легковесного JIT-компилятора MIR, обеспечивающего выполнение кода, предварительно преобразованного в промежуточное представление MIR (Medium Internal Representation, не путать с другим промежуточным представлением MIR (mid-level IR), применяемым в компиляторе Rust). Проект нацелен на предоставление основы для реализации быстрых и компактных интерпретаторов и JIT. Код проекта написан на языке Си и распространяется под лицензией MIT.

На текущей стадии разработки трансляторы в промежуточное представление MIR подготовлены для языка Си и биткода LLVM (Bitcode), но в будущем планируется реализовать возможность генерации MIR для WebAssembly, байткода Java, CIL (Common Intermediate Language), Rust и C++. Проект развивается одним из разработчиков JIT-движка MJIT, используемого в Ruby. В первую очередь JIT на базе MIR планируется реализовать для CRuby и MRuby. В будущем также не исключается возможность портирования GCC на использование MIR.

Промежуточный код MIR может быть представлен в бинарном и текстовом (читаемом) виде. Данный код можно будет исполнить в интерпретаторе, сренегерировать на его основе машинный код (x86_64, в планах ARM64, PPC64 и MIPS64). Возможно и выполнение обратного преобразования — из MIR в CIL, байткод Java, WebAssembly и код на языке Си.

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

Ключевым достоинством выполнения промежуточного кода в JIT вместо компиляции в нативные исполняемые файлы, является возможность формирования компактных файлов, которые могут выполняться без пересборки на разных аппаратных архитектурах (x86, ARM, PPC, MIPS). Для неподдерживаемых архитектур доступен режим интерпретации, который в случае MIR работает в 6-10 раз медленнее JIT.

Из недостатков существующих JIT-компиляторов GCC и LLVM называется их излишняя раздутость, низкая скорость компиляции и трудность реализации комбинированных оптимизаций для разных языков программирования. Разработчики MIR попытались решить эти проблемы и поставили перед собой цели:

  • Компиляция в MIR должна осуществляться как минимум в 100 раз быстрее, чем в GCC;
  • JIT для исполнения MIR должен быть очень компактным и включать примерно 15 тысяч строк кода;
  • Исполнение MIR с использованием JIT должно быть не более чем на 30% медленнее, чем производительность исполняемого файла, собранного на основе того же Си-кода в GCC (с оптимизациями «-O2»);
  • Стадии инициализации до начала фактического исполния должны занимать в 100 раз меньше времени;
  • MIR-представление для JIT должны быть в 100 раз меньше собранного в GCC исполняемого файла.

В текущем виде реализация MIR во многим опережает изначально поставленные цели: проведённые тесты показали, что производительность компиляции в MIR быстрее «GCC -O2» в 178 раз, производительность исполнения отстаёт от нативного кода на 6%, размер кода меньше в 144 раза, реализация MIR JIT составляет 16 тысяч строк кода.

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

Samsung предложил новый вариант драйвера exFAT для ядра Linux

Компания Samsung предложила для включения в ядро Linux набор патчей с реализацией нового драйвера exFAT, основанного на актуальной кодовой базе «sdfat», развиваемой для прошивок Android-смартфонов Samsung. Если патчи будут приняты, то они войдут в состав ядра Linux 5.6, релиз которого ожидается через 2-3 месяца. По сравнению с ранее добавленным в ядро драйвером exFAT, новый драйвер обеспечивает прирост производительности примерно на 10%.

Основные отличия редакции драйвера sdfat для основного ядра Linux от драйвера, используемого Samsung в Android:

  • Удалён код с реализацией ФС VFAT, так как данная файловая система уже отдельно поддерживается в ядре (fs/fat);
  • Драйвер переименован с sdfat в exfat;
  • Проведён рефакторинг кода. Исходные тексты приведены к требованиям по оформлению кода для ядра Linux;
  • Выполнена оптимизация операций с метаданными, такими как создание файлов, поиск элементов ФС (lookup) и определение содержимого каталога (readdir).
  • Исправлены выявленные при дополнительном тестировании ошибки.

Напомним, что после того, как компания Microsoft опубликовала общедоступные спецификации и предоставила возможность безвозмездного использования патентов на exFAT в Linux, в экспериментальный раздел «staging» («drivers/staging/») ядра 5.4 был добавлен драйвер exFAT, также разработанный в Samsung, но основанный на устаревшем коде (версия 1.2.9). Энтузиастами из Android-прошивок был портирован новый драйвер sdFAT (2.x), но компания Samsung самостоятельно решила заняться продвижением этого драйвера в основное ядро Linux. Кроме того, компанией Paragon Software был открыт альтернативный драйвер, ранее поставляемый в пропритетарном наборе драйверов.

Файловая система exFAT была создана Microsoft для устранения ограничений FAT32 при использовании на Flash-накопителях большого объема. Поддержка файловой системы exFAT появилась в Windows Vista Service Pack 1 и Windows XP с Service Pack 2. Максимальный размер файла по сравнению с FAT32 был расширен с 4 Гб до 16 эксабайт, устранено ограничение на максимальный размер раздела в 32 Гб, для уменьшения фрагментации и увеличения скорости введена битовая карта свободных блоков, ограничение на число файлов в одной директории поднято до 65 тыс., предусмотрена возможность хранения ACL.

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

Сотрудник Red Hat представил сборочную систему Goals. Выпуск GNU Make 4.2

Ричард Джонс (Richard WM Jones), автор libguestfs, работающий в компании Red Hat, объявил о начале работы над новой сборочной утилитой Goals, нацеленной на устранение недостатков и проблем в утилите make, при сохранении общей простоты и понятности сценариев. Утилита make проектировалась в 1976 году и имеет ряд концептуальных недоработок, в Goals планируется устранить эти недоработки не меняя общей концепции.

Решаемые проблемы:

  • Поддержка только одной тактики разрешения зависимостей — «сборочная инструкция запускается если целевой файл отсутствует или он старее одной из зависимостей». В Goals планируется реализовать и другие тактики, такие как проверка наличия URL, сравнение времени изменения с любым файлом, оценка сборки пакета в Koji, сравнение контрольных сумм, запуск тестовых наборов с выборочным пропуском тестов.
  • При обработке сборочных целей утилита make не разделяет файлы и имена правил, и, как следствие, отсутствует проверка того, что при запуске правила действительно будет создан файл, создание которого заявлено. Например, если при наличии правила с именем «test», запускающего скрипты с тестами, случайно будет создан файл с именем «test», то тесты перестанут вызываться, так как make посчитает, что цель собрана и не требует выполнения каких-либо действий (для обхода проблемы в make можно указать директиву «.PHONY: test»). Goals явно разделяет файлы и имена правил.
  • Проблема с предоставлением только одного параметра для сборочных инструкций.

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

  • Завязка на shell-интерпретатор. Например, необходимость контролировать экранирование пробелов в именах файлов и каталогов, трата ресурсов на запуск отдельного shell-интерпретатора при выполнении каждой команды, двойная трактовка символа «$» (используется как в shell, так и в make), учёт отступов.

    Указанные проблемы решаются в Goals использованием символа «%» вместо «$» для сборочных переменных («$» остаётся только для shell), применением парсера LALR(1), требующего обрамлять пути и имена файлов кавычками и выделять фигурными скобками блоки с кодом. Весь блок команда запускается в одном экземпляре командной оболочки, а внутри блока допускается произвольное форматирование кода, без привязки к специальным пробелам.

      Было:      target: foo.o bar.o                    ${CC} ${CFLAGS} $

Другие особенности Goals:

  • Опциональная поддержка задания произвольных имён и параметров:
           goal all = : "target"         goal link =       "target" : "foo.o", "bar.o" { ... }         goal compile (name) =       "%name.o" : "%name.c", "dep.h" { %CC %CFLAGS -c $^ -o $@ }  
  • Два режима запуска: режим make для сопоставления сборочных целей с именами файлов (например, файл «foo.o» соответствует цели «%name.o»), и режим прямой компиляции:
           goal all = : link         goal link =       "target" : "foo.o", compile ("bar") { ... }         goal compile (name) =       "%name.o" : "%name.c", "dep.h" { %CC %CFLAGS -c $^ -o $@ }  
  • Тактика сборки определяется специальными правилами, при помощи которых можно определять необходимость пересборки сборочной цели. Если осуществляется привязка к наличию файла, то это явно определяется через соответствующий признак («target» для имени правила и *file(«target») для проверки файла).
        "target" : "foo.o", "bar.o" { ... }      *file("target") : *file("foo.o"), *file("bar.o") { ... }  
  • Разработчик может определять произвольные признаки сборочных тактик. Признак «*file» определён по умолчанию (@{…} указывает на подавление вывода, а «exit 99» сигнализирует о необходимости пересборки):
         tactic *file (filename) = @{        test -f %filename || exit 99        for f in %
  • Предлагается парсер сценариев на языке goals и runtime для выполнения языка, построения графа зависимостей и параллельного запуска работ. В состав входит стандартная библиотека вспомогательных функций, которые могут определяться на shell или с использованием специфичного синтаксиса сценариев goals. Функции могут вызываться как по имени, так и по шаблону (по аналогии с языком Пролог)
          function wildcard (wc) returning strings = @{          shopt -s nullglob          wc=%wc          for f in $wc; do echo "$f"; done      }  
  • Из планов на будущее упоминается поддержка типов, отличных от строк, возможность определения значений параметров по умолчанию и поддержка анонимных функций.
          goal build (project, bool release = true) = ...      build ("foo")      build ("foo", false)        let hello = { echo "hello" }        let f = function (name, version) { CODE }      f ("goals", "0.1")  

    Тем временем, после почти четырёх лет разработки состоялся релиз системы сборки GNU Make 4.3. Кроме исправления ошибок, в новой версии можно отметить следующие улучшения:

    • Применение символа «#» внутри макроподстановок или при вызове функций теперь не обрабатывается как комментарий и не требует экранирования (например, теперь нужно писать «foo := $(shell echo ‘#’)», а «foo := $(shell echo ‘#’)» будет приводить к выводу «#»).
    • Использование оператора ‘+=’ для добавления к пустой переменной теперь не приводит к подстановке начального пробела, так же как и прикрепление пустой строки вконец переменной не приводит к добавлению финального пробела.
    • Добавлена возможность явного определения правил, генерирующих несколько сборочных целей при одном вызове. Для использования данной возможности при определении сборочной цели вместо символа «:» в правилах следует использовать «&:»;
    • Реализована переменная «.EXTRA_PREREQS», через которую можно задать необходимые для цели дополнительные компоненты;
    • В Makefile теперь допускается выставление опции ‘-j’ в переменных MAKEFLAGS для запуска в параллельном режиме;
    • Добавлена возможность использования вызова posix_spawn() вместо fork/exec;
    • Применяемый в Windows лимит на 63 параллельные работы (включая субпроцессы, запускаемые через выражения «$(shell)») увеличен до 4095;
    • Добавлена опция «—no-silent», отменяющая действие флагов «-s», «—silent» и «—quiet»;
    • Добавлен сокращённый вариант опции «—eval» — «-E»;
    • Для всех операций раскрытия по маске, включая «$(wildcard …)», теперь применяется сортировка результата (для обеспечения предсказуемого на разных платформах поведения);
    • Добавлена поддержка новых версий Си-библиотек Glibc и musl;
    • Внесены оптимизации производительности;
    • Код перемещён из корня архива в каталог src/*.

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

Первый релиз wZD 1.0.0, сервера компактного хранения мелких файлов

Доступен первый выпуск wZD 1.0.0 — сервера для эффективного хранения большого числа файлов в компактном виде, который снаружи выглядит как обычный WebDAV-сервер. Для хранения используется модифицированная версия BoltDB. Код проекта написан на языке Go и распространяется под лицензией BSD.

Сервер позволяет значительно сократить количество маленьких файлов на обычных или кластерных файловых системах с полной поддержкой блокировок. Поддерживаемый разработчиками wZD кластер хранит около 250 миллионов мелких файлов, разнесённых по 15 миллионам директорий в кластерной ФС MooseFS.

wZD даёт возможность переместить (архивировать) содержимое директорий в архивы в формате BoltDB и затем раздавать эти файлы из этих архивов (или помещать файлы в архивы методом PUT), значительно сократив число файлов в ФС и снизив накладные расходы на хранение метаданных. Для повышения эффективности обработки больших файлов, такие файлы могут сохраняться отдельно от Bolt-архивов. Подобный подход позволяет организовать хранение огромного числа мелких файлов, не упираясь в лимит на число inode в файловой системе.

Сервер также можно использовать как NoSQL базу для данных в формате ключ/значение (с шардингом на базе структуры директорий) или для раздачи из БД предварительно сгенерированных html или json-документов. Что касается производительности, то отдача и запись данных с использованием Bolt-архивов приводит к увеличению задержки приблизительно на 20-25% при чтении и на 40-50% при записи. Чем меньше размер файла, тем меньше различия в задержках.

Основные возможности:

  • Многопоточность;
  • Мультисерверность, обеспечивающая отказоустойчивость и сбалансированность нагрузки;
  • Максимальная прозрачность для пользователя или разработчика;
  • Поддерживаемые HTTP-методы: GET, HEAD, PUT и DELETE;
  • Управление поведением при чтении и записи через клиентские заголовки;
  • Поддержка гибко настраиваемых виртуальных хостов;
  • Поддержка CRC-целостности данных при записи/чтении;
  • Полудинамические буферы для минимального потребления памяти и оптимальной настройки сетевой производительности;
  • Отложенная упаковка данных;
  • В дополнение предлагается многопоточный архиватор wZA для перемещения файлов в Bolt-архивы без остановки сервиса.

Некоторые ограничения текущего выпуска: нет поддержки Multipart, метода POST, протокола HTTPS, биндингов для языков программирования, рекурсивного удаления директорий, отсутствует поддержка монтирования структуры в файловую систему через WebDAV или FUSE, файлы хранятся под одним системным пользователем. Формат хранения привязан к архитектуре и не переносим между системами Little Endian и Big Endian. Несмотря на то, что сервер wZD реализует поддержку протокола HTTP, запускать его требуется только под прикрытием реверс прокси, таких как nginx и haproxy.

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

Выпуск платформы совместной разработки OneDev 3.0

Доступен новый значительный выпуск OneDev 3.0, платформы для управлением полным циклом разработки ПО, предоставляющей полный набор инструментов для разработки проектов в соответствии с парадигмой DevOps. По своим возможностям OneDev напоминает GitLab и также даёт возможность развернуть на своих мощностях инфраструктуру совместной разработки, рецензирования, тестирования, сборки и доставки релизов, не привязываясь к внешним облачным сервисам, таким как GitHub. Код проект написан на языке Java и распространяется под лицензией MIT.

Некоторые возможности:

  • Упрощённый процесс развёртывания сборочной фермы для запуска CI-сборок в Kubernetes, не требующий выполнения агентов и runner-ов. Возможность тестирования в контейнерах с Linux и Windows;
  • Поддержка создания спецификаций сборки (Build Spec) в наглядном режиме без написания YAML-файлов и запоминания синтаксиса;
  • Возможность гибкой настройки процесса сборки с использованием условных сборочных параметров, параллельным запуском нескольких сборочных работ и автоматическим запуском работ при наступлении определённых событий;
  • Поддержка определения собственных состояний и полей для уведомлений о проблемах (issue), возможность определения зависимостей между полями и автоматическая смена состояния при наступлении определённых событий;
  • Автообновляемый интерфейс issue, не требующий перезагрузки страницы;
  • Система поиска и навигации по коду и изменениям, учитывающая особенности синтаксиса Java, JavaScript, C, C++, CSharp, Go, PHP, Python, CSS, SCSS, LESS и R;
  • Поддержка привязки обсуждений и внешних комментариев к коду и блокам с изменениями (diff);
  • Гибкие правила рецензирования pull-запросов c возможностью защиты определённых веток и назначением разработчиков для рецензировния;
  • Поэтапный режим анализа коммитов при рецезнировании pull-запросов. Привязка к обсуждениям прошлого рецензирования;
  • Язык запросов, позволяющий находить нужную информацию в проектах, коммитах, сборках, issues, pull-запросах и комментариях. Возможность сохранения запроса и получения уведомления о появлении связанных с ним новых событиях;
  • Система контроля доступа, позволяющая определять кто может изменять код в определённом подкаталоге, назначать issues, запускать сборки релизов, просматривать логи и т.п.
  • Возможности для создания и клонирования репозиториев;
  • Подписка на получение уведомлений об осуществлении коммитов в master-ветку;
  • Поддержка pull-запросов с автоматизацией проверки принимаемого коммита в системе непрерывной интеграции и утверждением экспертным советом, включающим как минимум два разработчика;
  • Возможность закрытия issues через сообщение коммита, которое может связывать обсуждение, коммит, сборки и pull-запросы;
  • Возможность создания сохраняемых в интерфейсе форм для отображения каким пользователям назначено решение проблем (issue);
  • Поддержка создания произвольных полей для прикрепления issue к определённым модулям и платформам;
  • Возможность автоматической смены статуса проблемы на Deployed при исправлении при сборке и на Review при открытии pull-запроса;
  • Возможность назначения проблеме состояния Verified, которое могут присваивать разработчики, имеющие статус тестировщика;
  • Поддержка ручного инициирования пересборки с возможностью указания версии, которая будет присвоена и создан соответствующий тег в случае успеха сборки;
  • Возможность выбора платформы и версии ядра Linux при запуске ручной пересборки;
  • Поддержка тестирования в CI различных комбинаций Oracle/MySQL и Linux/Windows при коммите в master-ветку;
  • Автоматическое создание уведомлений о проблемах (issue) и назначение ответственного для разбора проблемы в случае сбоя сборки master-ветки в CI. Автозакрытие issue при устранении сбоя при сборке
  • Возможность генерации файлов в одной работе, их параллельной обработке во второй и анализ результатов в третьей;
  • Поддержка повторного запуска работ в случае ошибки запуска обработчика в Kubernetes;
  • Возможность использования сервиса MySQL в процессе выполнения работ;
  • Поддержка задания секретного ключа при определении спецификации сборки;
  • Возможность ограничения доступа анонимным пользователям только к релизам определённых проектов;
  • Поддержка ограничения генерации релизов только master-веткой и размещения на рабочих серверах только релизов, собранных из master-ветки.

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