The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

·20.05.2022 Google открыл наработки, связанные с защищённым сетевым протоколом PSP (76 +9)
  Компания Google объявила об открытии спецификаций и эталонной реализации протокола PSP (PSP Security Protocol), применяемого для шифрования трафика между датацентрами. Протокол использует похожую на IPsec ESP (Encapsulating Security Payloads) архитектуру инкапсуляции трафика поверх IP, обеспечивая шифрование, криптографический контроль целостности и аутентификацию источника. Код реализации PSP написан на языке Си и распространяется под лицензией Apache 2.0.

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

В качестве транспорта для передачи данных используется протокол UDP. Пакет PSP начинается с заголовка IP, после которого следует заголовок UDP и затем собственный заголовок PSP с информацией о шифровании и аутентификации. Далее прикрепляется содержимое оригинального пакета TCP/UDP, которое завершается финальным блоком PSP с контрольной суммой для подтверждения целостности. Заголовок PSP, а также заголовок и данные инкапсулируемого пакета всегда аутентифицированы для подтверждения подлинности пакета. Данные инкапсулируемого пакета могут могут быть зашифрованы, при этом допускается возможность выборочного применения шифрования с оставлением части TCP-заголовка в открытом виде (при сохранении контроля подлинности), например, для предоставления возможности инспектирования пакетов на транзитном сетевом оборудовании.

PSP не привязывается к какому-то определённому протоколу обмена ключами, предлагает несколько вариантов формата пакетов и поддерживает использование разных криптоалгоритмов. Например, предоставляется поддержка алгоритма AES-GCM для шифрования и проверки подлинности (аутентификации) и AES-GMAC для проверки подлинности без шифрования непосредственных данных, например когда данные не представляют ценности, но нужно гарантировать, что они не были подменены во время передачи и именно те, что были отправлены изначально.

В отличие от типовых VPN-протоколов в PSP применяется шифрование на уровне отдельных сетевых соединений, а не всего канала связи, т.е. PSP использует отдельные ключи шифрования для разных туннелируемых UDP- и TCP-соединений. Подобный подход даёт возможность добиться более строгой изоляции трафика от разных приложений и обработчиков, что актуально при выполнении на одном сервере приложений и сервисов разных пользователей.

В Google протокол PSP применяется как для защиты собственных внутренних коммуникаций, так и для защиты трафика клиентов Google Cloud. Протокол изначально рассчитан на эффективную работу в инфраструктурах уровня Google и должен обеспечивать аппаратное ускорение шифрования в условиях наличия миллионов активных сетевых соединений и установки сотен тысяч новых соединений в секунду.

Поддерживается два режима работы - "stateful" и "stateless". В режиме "stateless" ключи для шифрования передаются сетевой карте в дескрипторе пакета, а для расшифровки извлекаются из присутствующего в пакете поля SPI (Security Parameter Index) при помощи мастер-ключа (256-bit AES, хранится в памяти сетевой карты и заменяется каждые 24 часа), что позволяет экономить память сетевой карты и минимизировать информацию о состоянии шифрованных соединений, хранимую на стороне оборудования. В режиме "stateful" ключи для каждого соединения хранятся на сетевой карте в специальной таблице, по аналогии тем как реализовано аппаратное ускорение в IPsec.

PSP предоставляет своеобразную комбинацию возможностей протоколов TLS и IPsec/VPN. TLS подходил Google с точки зрения защиты на уровне отдельных соединений, но не устраивал из-за недостаточной гибкости для аппаратного ускорения и отсутствия поддержки UDP. IPsec обеспечивал независимость от протоколов и хорошо поддерживал аппаратное ускорения, но не поддерживал привязку ключей к отдельным соединениям, был рассчитан лишь на небольшое число создаваемых туннелей и имел проблемы с масштабированием аппаратного ускорения из-за хранения полного состояния шифрования в таблицах, размещаемых в памяти сетевой карты (например, для обработки 10 млн соединений требуется 5 ГБ памяти).

В случае PSP информация о состоянии шифрования (ключи, векторы инициализации, порядковые номера и т.п.) может передаваться в TX-дескрипторе пакета или в форме указателя на память хост-системы, не занимая память сетевой карты. По данным Google ранее на шифрование RPC-трафика в инфраструктуре компании тратилось примерно 0.7% вычислительной мощности и большой объём памяти. Внедрение PSP за счёт привлечения средств аппаратного ускорения позволило снизить этот показатель до 0.2%.

  1. OpenNews: Компания Intel развивает протокол HTTPA, дополняющий HTTPS
  2. OpenNews: Протокол QUIC получил статус предложенного стандарта
  3. OpenNews: Компания ExpressVPN открыла наработки, связанные с VPN-протоколом Lightway
  4. OpenNews: Выпуск qBittorrent 4.4 с поддержкой протокола BitTorrent v2
  5. OpenNews: Huawei развивает протокол NEW IP, нацеленный на использование в сетях будущего
Обсуждение (76 +9) | Тип: К сведению |
·19.05.2022 Выпуск языка программирования Rust 1.61 (231 –10)
  Опубликован релиз языка программирования общего назначения Rust 1.61, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки).

Методы работы с памятью в Rust избавляют разработчика от ошибок при манипулировании указателями и защищают от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Для распространения библиотек, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo. Для размещения библиотек поддерживается репозиторий crates.io.

Безопасная работа с памятью обеспечивается в Rust во время компиляции через проверку ссылок, отслеживание владения объектами, учёт времени жизни объектов (области видимости) и оценку корректности доступа к памяти во время выполнения кода. Rust также предоставляет средства для защиты от целочисленных переполнений, требует обязательной инициализации значений переменных перед использованием, лучше обрабатывает ошибки в стандартной библиотеке, применяет концепцию неизменяемости (immutable) ссылок и переменных по умолчанию, предлагает сильную статическую типизацию для минимизации логических ошибок.

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

  • Предоставлена возможность определения собственных кодов возврата из функции main. Изначально функция main в Rust могла возвращать только тип "()" (unit), что всегда указывало на успешный статус завершения, если разработчиком явно не вызвана функция "process::exit(code)". В Rust 1.26 при помощи нестабильного типажа Termination в функции main была предоставлена возможность возвращение значений "Ok" и "Err", соответствующих кодам EXIT_SUCCESS и EXIT_FAILURE в программах на языке Си. В Rust 1.61 типаж Termination переведён в разряд стабильных, а для представления конкретного кода возврата предложен отдельный тип ExitCode, который абстрагирует специфичные для платформы типы возвращаемых значений, предоставляя как предопределённые константы SUCCESS и FAILURE, так и метод From<u8> для возвращения произвольного кода возврата.
    
       use std::process::ExitCode;
    
       fn main() -> ExitCode {
           if !check_foo() {
               return ExitCode::from(42);
           }
           ExitCode::SUCCESS
       }
    
  • Стабилизированы дополнительные возможности функций, определённых с использованием выражения "const fn", которые могут вызываться не только как обычные функции, но и использоваться в любом контексте вместо констант. Данные функции вычисляются на этапе компиляции, а не в ходе выполнения, поэтому на них накладываются определённые ограничения, такие как возможность чтения только из констант. В новой версии внутри const-функций разрешены базовые операции с указателями на функции (разрешено создание, передача и приведение указателей, но не вызов функции по указателю); ограничения типажей (trait bounds) для обобщённых параметров const-функций, таких как T: Copy; динамически диспетчеризируемые типажи (dyn Trait); типы impl Trait для аргументов и возвращаемых значений функции.
  • Дескрипторы потоков Stdin, Stdout и Stderr в std::io теперь имеют cтатическое время жизни ("'static") при блокировке, что позволяет использовать конструкции вида "let out = std::io::stdout().lock();" с получением дескриптора и выставлением блокировки в одном выражении.
  • В разряд стабильных переведена новая порция API, в том числе стабилизированы методы и реализации типажей:
  • Признак "const", определяющий возможность использования в любом контексте вместо констант, применён в функциях:

Дополнительно можно отметить статью "Rust: A Critical Retrospective" с обобщением впечатлений о языке Rust после написания на нём 100 тысяч строк кода в процессе разработки микроядерной операционной системы Xous, используемой в прошивках. Из недостатков отмечается трудный для восприятия синтаксис, незавершённость и продолжение развития языка, отсутствие повторяемых сборок, типовые проблемы с доверием к зависимостям в Crates.io, необходимость соблюдения определённой дисциплины для написания безопасного кода. Из возможностей превзошедших ожидания упоминаются средства для рефакторинга кода и переделки "хаков", добавленных при быстром создании прототипов.

  1. OpenNews: Выпуск языка программирования Rust 1.60
  2. OpenNews: В Rust-репозитории crates.io выявлен вредоносный пакет rustdecimal
  3. OpenNews: Шестая версия патчей для ядра Linux с поддержкой языка Rust
  4. OpenNews: Выпуск операционной системы Redox OS 0.7, написанной на языке Rust
  5. OpenNews: В написанной на Rust реализации OpenCL для Mesa обеспечена поддержка OpenCL 3.0
Обсуждение (231 –10) | Тип: Программы |
·19.05.2022 В Firefox началось тестирование третьей версии манифеста Chrome (93 +4)
  Компания Mozilla объявила о начале тестирования реализации в Firefox третьей версии манифеста Chrome, определяющей возможности и ресурсы, доступные для дополнений, написанных с использованием API WebExtensions. Для тестирования третьей версии манифеста в бета-версии Firefox 101 на странице about:config следует установить параметр "extensions.manifestV3.enabled" в значение true, а параметр "xpinstall.signatures.required" в значение false. Для установки дополнений можно использовать интерфейс about:debugging. Включение третьей версии манифеста по умолчанию запланировано на конец года.

Начиная с версии 57 Firefox полностью перешёл на использование API WebExtensions для разработки дополнений и прекратил поддержку технологии XUL. Переход на WebExtensions позволил унифицировать разработку дополнений с платформами Chrome, Opera, Safari и Edge, упростил портирование дополнений между различными web-браузерами и дал возможность полноценно использовать многопроцессный режим работы (дополнения WebExtensions могут выполняться в отдельных процессах, изолированно от остальных частей браузера). Для унификации разработки дополнений с остальными браузерами в Firefox обеспечивается почти полная совместимость со второй версией манифеста Chrome.

В настоящее время в Chrome ведётся работа по переходу на третью версию манифеста, а поддержка второй версии будет прекращена в январе 2023 года. Так как третья версия манифеста стала объектом критики и приведёт к нарушению работы многих дополнений для блокирования нежелательного контента и обеспечения безопасности, компания Mozilla решила отойти от практики обеспечения полной совместимости с манифестом в Firefox и реализовать иначе некоторые изменения.

Основное недовольство третьей версией манифеста связано с переводом в режим только для чтения API webRequest, позволявшего подключать собственные обработчики, имеющие полный доступ к сетевым запросам и способные на лету модифицировать трафик. Указанный API применяется в uBlock Origin и многих других дополнениях для блокирования нежелательного контента и обеспечения безопасности. Вместо API webRequest в третьей версии манифеста предложен ограниченный по своим возможностям API declarativeNetRequest, предоставляющий доступ к встроенному движку для фильтрации, самостоятельно обрабатывающему правила блокировки, не разрешающему использовать собственные алгоритмы фильтрации и не позволяющему задавать сложные правила, перекрывающие друг друга в зависимости от условий.

В предложенной в Firefox реализации третьей версии манифеста добавили новый декларативный API фильтрации контента, но в отличие от Chrome не стали прекращать поддержку старого блокирующего режима работы API webRequest. Среди других особенностей реализации нового манифеста в Firefox:

  • В манифесте определена замена фоновых страниц на вариант Service Workers, работающий в виде фоновых процессов (Background Service Workers). Для обеспечения совместимости в Firefox будет реализовано данное требование, но дополнительно предложен новый механизм Event Pages, который более привычен для web-разработчиков, не требует полной переработки дополнений и устраняет ограничения, связанные с применением Service Workers. Event Pages позволит привести существующие дополнения с фоновыми страницами к требованиям третьей версии манифеста, сохранив при этом доступ ко всем возможностям, необходимым для работы с DOM. В доступной для тестирования в Firefox реализации манифеста пока поддерживаются только Event Pages, а поддержку решения на базе Service Workers обещают добавить позднее. Предложение поддержала компания Apple и реализовала Event Pages в выпуске Safari Technology Preview 136.
  • Новая гранулированная модель запроса полномочий - дополнение не сможет активироваться сразу для всех страниц (убрано полномочие "all_urls"), а будет работать только в контексте активной вкладки, т.е. пользователю потребуется подтверждать работу дополнения для каждого сайта. В Firеfox все запросы на доступ к данным сайта будут рассматриваться как необязательные, а конечное решение о предоставлении доступа будет принимать пользователь, который сможет выборочно решать какому дополнению предоставить доступ к своим данным на том или ином сайте.
  • Изменение обработки Cross-origin запросов - в соответствии с новым манифестом на скрипты обработки контента будут распространяться те же ограничения полномочий, что и для основной страницы, в которую эти скрипты внедряются (например, если страница не имеет доступа к API определению местоположения, то и скрипт дополнения также не получит этот доступ). Данное изменение полностью реализовано в Firefox.
  • API на основе Promise. Firefox уже поддерживает данный API и для третьей версии манифеста перенесёт его в пространство имён "chrome.*".
  • Запрет выполнения кода, загруженного с внешних серверов (речь про ситуации, когда дополнение подгружает и выполняет внешний код). В Firefox уже применяется блокировка внешнего кода и разработчики Mozilla добавили дополнительные техники отслеживания загрузок кода, предлагаемые в третьей версии манифеста. Для скриптов обработки контента представлена отдельная политика ограничения доступа к контенту (CSP, Content Security Policy).

  1. OpenNews: Google опубликовал план прекращения поддержки второй версии манифеста Chrome
  2. OpenNews: Mozilla обобщила планы по поддержке в Firefox третьей версии манифеста Chrome
  3. OpenNews: Chrome 88 переведён на новый манифест, несовместимый с uBlock Origin
  4. OpenNews: В Chrome началось тестирование третьей редакции манифеста, несовместимой с uBlock Origin
  5. OpenNews: Новая редакция манифеста Chrome сделает невозможным использование uBlock Origin
Обсуждение (93 +4) | Тип: К сведению |
·19.05.2022 Релиз Mesa 22.1, свободной реализации OpenGL и Vulkan (66 +19)
  После двух месяцев разработки опубликован релиз свободной реализации API OpenGL и Vulkan - Mesa 22.1.0. Первый выпуск ветки Mesa 22.1.0 имеет экспериментальный статус - после проведения окончательной стабилизации кода будет выпущена стабильная версия 22.1.1.

В Mesa 22.1 доступна поддержка графического API Vulkan 1.3 в драйверах anv для GPU Intel, radv для GPU AMD и программном растеризаторе lavapipe. Поддержка Vulkan 1.2 реализована в режиме эмулятора (vn), Vulkan 1.1 - в драйвере для GPU Qualcomm (tu). а Vulkan 1.0 в драйвере для GPU Broadcom VideoCore VI (Raspberry Pi 4). В Mesa также обеспечивается полная поддержка OpenGL 4.6 для драйверов 965, iris (Intel), radeonsi (AMD), zink и llvmpipe. Поддержка OpenGL 4.5 доступна для GPU AMD (r600) и NVIDIA (nvc0), а OpenGL 4.3 для virgl (виртуальный GPU Virgil3D для QEMU/KVM) и vmwgfx (VMware).

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

  • В Vulkan-драйвере ANV (Intel) и OpenGL-драйвере Iris реализована поддержка дискретных видеокарт Intel DG2 (Arc Alchemist) и Arctic Sound-M.
  • В драйвере D3D12 с прослойкой для организации работы OpenGL поверх API DirectX 12 (D3D12) обеспечена совместимость с OpenGL 4.2. Драйвер применяется в прослойке WSL2 для запуска графических приложений Linux в Windows.
  • В драйвере lavapipe с реализацией программного растеризатора для API Vulkan (аналог llvmpipe, но для Vulkan, выполняющий трансляцию вызовов API Vulkan в API Gallium) реализована поддержка Vulkan 1.3.
  • Добавлена поддержка GPU AMD GFX1036 и GFX1037.
  • В драйвере RADV (AMD) реализована возможность отсеивания примитивов при трассировке лучей (ray primitive culling), что улучшило поддержку трассировки лучей для игр, таких как DOOM Eternal.
  • Предложена начальная реализация драйвера Vulkan для GPU на базе архитектуры PowerVR Rogue, развиваемой компанией Imagination.
  • Драйвер Nouveau для старых GPU GeForce 6/7/8 переведён на использование бестипового промежуточного представление (IR) шейдеров NIR. Поддержка NIR также позволяет получить поддержку промежуточного представления TGSI (Tungsten Graphics Shader Infrastructure) через задействование слоя для трансляции NIR в TGSI.
  • В состав включён компактный компилятор OpenCL, предложенный компанией Intel и используемый при трассировке лучей.
  • В OpenGL-драйвере v3d, развиваемом для графического ускорителя VideoCore VI, применяемого начиная с модели Raspberry Pi 4, реализована поддержка кэширования шейдеров на диске.
  • Для GPU AMD, оснащённым движком обработки видео VCN 2.0, реализована поддержка EFC (Encoder Format Conversion), позволяющая использовать аппаратный кодировщик видео для прямого чтения RGB-поверхностей без преобразований RGB->YUV, выполняемых шейдерами.
  • В драйвере Crocus, развиваемом для старых GPU Intel на базе микроархитектур Gen4-Gen7, не поддерживаемых драйвером Iris, включён профиль совместимости со старыми версиями OpenGL.
  • В драйвере PanVk, предоставляющем поддержку графического API Vulkan для GPU ARM Mali Midgard и Bifrost, началась работа по поддержке вычислительных шейдеров.
  • В драйвер Venus с реализацией виртуального GPU (virtio-gpu) на базе API Vulkan добавлена поддержка прослойки ANGLE, отвечающей за трансляцию вызовов OpenGL ES в OpenGL, Direct3D 9/11, Desktop GL и Vulkan.
  • Добавлена поддержка предложенного компанией NVIDIA OpenGL-расширения GL_NV_pack_subimage, предназначенного для обновления прямоугольников в памяти хоста с использованием данных из фреймбуфера или текстуры.
  • В Vulkan-драйверы RADV (AMD), ANV (Intel) и lavapipe добавлена поддержка расширений:

  1. OpenNews: В написанной на Rust реализации OpenCL для Mesa обеспечена поддержка OpenCL 3.0
  2. OpenNews: Релиз Mesa 22.0, свободной реализации OpenGL и Vulkan
  3. OpenNews: Из Mesa удалён код классических драйверов, не использующих Gallium3D
  4. OpenNews: В Mesa принят OpenGL-драйвер с начальной поддержкой чипов Apple M1
  5. OpenNews: Релиз Mesa 21.3, свободной реализации OpenGL и Vulkan
Обсуждение (66 +19) | Тип: Программы |
·19.05.2022 Опубликован MyBee 13.1.0, дистрибутив FreeBSD для организации работы виртуальных машин (29 +12)
  Состоялся выпуск свободного дистрибутива MyBee 13.1.0, построенного на базе технологий FreeBSD 13.1 и предоставляющего API для работы с виртуальными машинами (через гипервизор bhyve) и контейнерами (на базе FreeBSD jail). Дистрибутив рассчитан на установку на выделенный физический сервер. Размер установочного образа - 1.7ГБ

Базовая инсталляция MyBee предоставляет возможности для создания, уничтожения, запуска и остановки виртуальных окружений. Создавая собственные микросервисы и регистрируя их endpoints в API (например, легко могут быть реализованы микросервисы снапшотов, миграции, чекпоинтов, клонирования, переименовывания и т.д.), пользователи могут конструировать и расширять API под любые задачи и создавать специфичные решения.

Кроме этого, в дистрибутив входит большое количество профилей современных ОС, таких как Debian, CentOS, Rocky, Kali, Oracle, Ubuntu, FreeBSD, OpenBSD, DragonflyBSD и NetBSD, готовых к немедленному использованию. Конфигурирование сети и доступа осуществляется посредством пакетов cloud-init (для ОС семейства *Unix) и cloudbase (для Windows). Также, проект предоставляет инструментарий для создания своих собственных образов. Один из примеров кастомизированного образа - кластер Kubernetes, также запускаемый через API (поддержка Kubernetes обеспечивается при помощи проекта K8S-bhyve).

Высокая скорость развёртывания виртуальных машин и работы гипервизора bhyve позволяет дистрибутиву в режиме однонодовой установки найти применение в задачах по тестированию приложений, а также в исследовательской деятельности. В случае объединения нескольких серверов MyBee в кластер, дистрибутив может найти применение в качестве базы для построения частных облаков и FaaS/SaaS платформ. Несмотря на наличие простейшей системы контроля доступа к API, дистрибутив рассчитан на работу только в доверенных (trusted) окружениях.

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

  1. OpenNews: Выпуск Bastille 0.9.20220216, системы управления контейнерами на основе FreeBSD Jail
  2. OpenNews: Выпуск MirageOS 4.0, платформы для запуска приложений поверх гипервизора
  3. OpenNews: Выпуск OmniOS CE r151036, дистрибутива Illumos
  4. OpenNews: Проект NetBSD развивает новый гипервизор NVMM
  5. OpenNews: Первый выпуск ClonOS, платформы для управления виртуальными окружениями
Обсуждение (29 +12) | Автор: Аноним | Тип: Программы |
·18.05.2022 Первый выпуск дистрибутива openSUSE Leap Micro (74 +8)
  Разработчики проекта openSUSE представили первый выпуск новой редакции дистрибутива openSUSE - "Leap Micro", основанной на наработках проекта MicroOS. Дистрибутив openSUSE Leap Micro позиционируется как community-версия коммерческого продукта SUSE Linux Enterprise Micro 5.2, чем и объясняется необычный номер первой версии - 5.2, который выбран для синхронизации нумерации выпусков в обоих дистрибутивах. Время поддержки выпуска openSUSE Leap Micro 5.2 составит 4 года.

Для загрузки доступны сборки для архитектур x86_64 и ARM64 (Aarch64), поставляемые как с инсталлятором (Offline-сборки, размером 370МБ), так и в форме готовых загрузочных образов: 570МБ (преднастроенный), 740МБ (с Real-Time ядром) и 820МБ. Образы могут запускаться под управлением гипервизоров Xen и KVM или поверх оборудования, включая платы Raspberry Pi. Для настройки можно использовать инструментарий cloud-init для передачи настроек при каждой загрузке или Combustion для выставления настроек во время первой загрузки.

Ключевой особенностью Leap Micro является механизм атомарной установки обновлений, которые загружаются и применяются автоматически. В отличие от атомарных обновлений на базе ostree и snap, используемых в Fedora и Ubuntu, в openSUSE Leap Micro вместо построения отдельных атомарных образов и развёртывания дополнительной инфраструктуры доставки применяются штатный пакетный менеджер и механизм снапшотов в ФС. Для обновления ядра Linux без перезапуска и приостановки работы поддерживаются live-патчи.

Корневой раздел монтируется в режиме только для чтения и не меняется в процессе работы. В качестве файловой системы используется Btrfs, снапшоты в которой служат основой для атомарного переключения между состоянием системы до и после установки обновлений. В случае возникновения проблем после применения обновлений можно откатить систему в предыдущее состояние. Для запуска изолированных контейнеров в состав интегрирован инструментарий с поддержкой runtime Podman/CRI-O и Docker.

Среди областей применения Leap Micro упоминается использование в качестве базовой системы для платформ виртуализации и контейнерной изоляции, а также применение в децентрализованных окружениях и системах на основе микросервисов. Leap Micro также является важным звеном в формировании следующего поколения дистрибутива SUSE Linux, в котором планируют разделить базовую основу дистрибутива на две части: урезанную "host OS" для работы поверх оборудования и слой для поддержки приложений, ориентированный на запуск в контейнерах и виртуальных машинах.

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

  1. OpenNews: Планы в отношении следующего поколения дистрибутива SUSE Linux
  2. OpenNews: Релиз дистрибутива openSUSE Leap 15.3
  3. OpenNews: Проект openSUSE анонсировал публикацию промежуточных сборок
  4. OpenNews: Компания SUSE развивает собственную замену CentOS 8, совместимую с RHEL 8.5
  5. OpenNews: Первый выпуск D-Installer, нового инсталлятора для openSUSE и SUSE
Обсуждение (74 +8) | Тип: Программы |
·18.05.2022 Технический директор Qt Company и главный сопровождающий Qt покидает проект (94 +16)
  Ларс Кнолл (Lars Knoll), создатель разработанного для KDE движка KHTML, который лёг в основу движков браузеров Safari и Chrome, объявил об уходе с поста технического директора компании Qt Company и главного сопровождающего Qt после 25 лет работы в экосистеме данного проекта. По мнению Ларса после его ухода проект останется в надёжных руках и продолжит развитие в соответствии с теми же принципами. В качестве мотива ухода называется желание попробовать заняться чем-то другим, помимо фреймворка Qt, которым он занимается ещё со студенческих времён.

Новым местом работы станет стартап, созданный вместе с одним из основателей компании Trolltech. Подробности о новом проекте пока не приводятся, упоминается лишь то, что он не связан с языком C++ и инструментами для разработчиков. До конца июня Ларс продолжит работать над Qt в том же темпе, но затем переключится на новый проект и будет уделять Qt заметно меньше времени, но полностью не покинет сообщество, останется доступен в рассылках и готов консультировать других разработчиков.

Кроме должности технического директора Qt Company Ларс также заявил об уходе с поста лидера (главного сопровождающего, Chief Maintainer) проекта Qt. При этом он продолжит сопровождать модуль Qt Multimedia, на поддержание которого готов выделить несколько часов своего времени в неделю. На пост нового лидера Qt предложено назначить Фолькера Хилсхаймера (Volker Hilsheimer), который занимается Qt полный рабочий день, знает все технические нюансы, имеет связи в компании Qt Company, пользуется авторитетом в среде разработчиков и является сторонником развития Qt как открытого проекта. Фолькер занимает в компании Qt Company должность директора, курирующего вопросы, связанные с исследованиями и опытно-конструкторскими работами (R&D), графикой и интерфейсом пользователя.

  1. OpenNews: Для Chromium развивается возможность использования Qt
  2. OpenNews: Релиз фреймворка Qt 6.3
  3. OpenNews: Выпуск среды разработки Qt Creator 7
  4. OpenNews: Выпуск сборочного инструментария Qbs 1.21 и начало тестирования Qt 6.3
  5. OpenNews: Релиз фреймворка Qt 6.2
Обсуждение (94 +16) | Тип: К сведению |
·18.05.2022 Доступен PikaScript 1.8, вариант языка Python для микроконтроллеров (139 +12)
  Опубликован выпуск проекта PikaScript 1.8, развивающего компактный движок для написания приложений для микроконтроллеров на языке Python. PikaScript не привязан к внешним зависимостям и может работать на микроконтроллерах с 4 КБ ОЗУ и 32 КБ Flash, таких как STM32G030C8 и STM32F103C8. Для сравнения для работы MicroPython требуется 16 КБ ОЗУ и 256КБ Flash, а для Snek - 2 КБ ОЗУ и 32 КБ Flash. Код проекта написан на языке Си и распространяется под лицензией MIT.

PikaScript предоставляет подмножество языка Python 3, поддерживающее такие элементы синтаксиса, как операторы ветвления и циклов (if, while, for, else, elif, break, continue), базовые операторы (+ - * / < == >), модули, инкапсуляцию, наследование, полиморфизм, классы и методы. Python-скрипты выполняются на устройствах после предварительной компиляции - PikaScript вначале преобразует Python-код во внутренний байткод Pika Asm, который на конечном устройстве выполняется в специальной виртуальной машине Pika Runtime. Поддерживается работа напрямую поверх оборудования или в окружениях RT-Thread, VSF (Versaloon Software Framework) и Linux.

Отдельно отмечается простота интеграции скриптов PikaScript с кодом на языке Си - к коду могут привязываться написанные на языке Си функции, что позволяет при внедрении PikaScript использовать наработки старых проектов, написанных на языке Си. Для разработки Си-модулей могут использовать существующие среды разработки, такие как Keil, IAR, RT-Thread Studio и Segger Embedded Studio. Привязки генерируются автоматически на этапе компиляции, достаточно определить API в файле с Python-кодом и привязка Си-функций к модулям Python будет выполнена во время запуска компилятора Pika Pre-compiler.

В PikaScript заявлена поддержка 24 микроконтроллеров, включая различные модели stm32g*, stm32f*, stm32h*, WCH ch582, ch32*, WinnerMicro w80*, Geehy apm32*, Bouffalo Lab bl-706, Raspberry Pico, ESP32C3 и Infineon TC264D. Для быстрого начала разработки без оборудования предоставляется симулятор или предлагается плата для разработчиков Pika-Pi-Zero на основе микроконтроллера STM32G030C8T6 с 64 КБ Flash и 8 КБ ОЗУ, поддерживающая типовые периферийные интерфейсы (GPIO, TIME, IIC, RGB, KEY, LCD, RGB). Разработчики также подготовили online-генератор проектов и пакетный менеджер PikaPackage.

В новой версии реализовано управление памятью на основе подсчёта ссылок и добавлена поддержка виртуальных конструкторов (factory method). Проведена диагностика проблем с памятью, выполненная с использованием инструментария valgrind. Добавлена поддержка компиляции pc-файлов Python в байткод и упаковки в прошивку. Реализована возможность использования в прошивках нескольких Python-файлов без необходимости использования файловой системы.

  1. OpenNews: Выпуск Snek 1.6, Python-подобного языка программирования для встраиваемых систем
  2. OpenNews: Проект Pine64 выпустил водонепроницаемые умные часы PineTime
  3. OpenNews: Проект Raspberry Pi выпустил микроконтроллер RP2040 стоимостью 1 доллар
  4. OpenNews: Британская вещательная корпорация представила вторую редакцию платы micro:bit
  5. OpenNews: Обеспечена возможность запуска MicroPython в web-браузере
Обсуждение (139 +12) | Тип: Программы |
·18.05.2022 Выпуск Ultimaker Cura 5.0, пакета для подготовки модели к 3D-печати (13 +14)
  Доступна новая версия пакета Ultimaker Cura 5.0, предоставляющего графический интерфейс для подготовки моделей к 3D-печати (slicing). Код проекта написан на языке Python и распространяется под лицензией LGPLv3. GUI построен при помощи фреймворка Uranium, использующего Qt.

На основе модели программа определяет сценарий работы 3D-принтера при последовательном нанесении каждого слоя. В простейшем случае достаточно импортировать модель в одном из поддерживаемых форматов (STL, OBJ, X3D, 3MF, BMP, GIF, JPG, PNG), выбрать настройки скорости, материала и качества и отправить задание на печать. Имеются плагины для интеграции с SolidWorks, Siemens NX, Autodesk Inventor​ и другими САПР. Для трансляции 3D-модели в набор инструкций 3D-принтера применяется движок CuraEngine.

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

  • Интерфейс пользователя переведён на использование библиотеки Qt6 (ранее применялась ветка Qt5). Переход на Qt6 позволил обеспечить поддержку работы на новых устройствах Mac, оснащённых чипом Apple M1.

  • Предложен новый движок нарезки на слои - Arachne, который использует переменную ширину линий при подготовке файлов, что позволяет повысить точность печати тонких и сложных деталей.
  • Улучшено качество предпросмотра нарезки отмасштабированных моделей.
  • Обновлён интерфейс каталога плагинов и материалов Cura Marketplace, встроенный в приложение. Упрощены операции поиска и установки плагинов и профилей материалов.
  • Улучшены профили для печати на принтерах Ultimaker. Скорость вывода на печать в некоторые случаях возросла до 20%.
  • Добавлена новая заставка, появляющаяся при запуске приложения, и предложена новая пиктограмма.
  • Обновлены цифровые рабочие столы (build plate) для принтеров Ultimaker.
  • Представлен параметр "минимальная ширина линии стенки" (Minimum Wall Line Width).
  • Добавлены настройки для 3D-печати металлом.
  • Добавлена поддержка компенсации усадки пластика при печати с использованием материалов PLA, tPLA и PETG.
  • Улучшен подбор ширины линий по умолчанию для печати спиралеобразных форм.
  • Повышена заметность опций в интерфейсе.

  1. OpenNews: Выпуск Ultimaker Cura 4.11, пакета для подготовки модели к 3D-печати
  2. OpenNews: Autodesk анонсировал Spark, открытую платформу для 3D-принтеров
  3. OpenNews: Проект Arduino представил собственный 3D-принтер
  4. OpenNews: Фонд свободного ПО сертифицировал 3D-принтер LulzBot TAZ 6
  5. OpenNews: Техника использования 3D-принтера для обхода аутентификации по отпечаткам пальцев
Обсуждение (13 +14) | Тип: Программы |
·17.05.2022 Новый поворот в разбирательстве, связанном с нарушением лицензии GPL компанией Vizio (157 +45)
  Правозащитная организация Software Freedom Conservancy (SFC) сообщила о новом витке судебного разбирательства с компанией Vizio, обвиняемой в невыполнении требований лицензии GPL при распространении прошивок к умным телевизорам на базе платформы SmartCast. Представители SFC добились возвращения рассмотрения дела из Федерального суда США в Окружной суд штата Калифорнии, что имеет принципиальное значение с точки зрения отнесения GPL не только к объектам авторского права, но и к области договорных отношений.

Ранее компания Vizio добилась переноса дела в Федеральный суд, который уполномочен решать вопросы, связанные с нарушениями авторского права. Рассматриваемое дело примечательно тем, что оно впервые в истории подано не от имени участника разработки, которому принадлежат имущественные права на код, а со стороны потребителя, которому не были предоставлены исходные тексты компонентов, распространяемых под лицензией GPL. Смещая рассмотрение GPL в область авторского права, компания Vizio строит свою защиту на попытке доказать, что потребители не являются бенефициарами и не имеют прав подавать подобные иски. Т.е. Vizio добивается закрытия дела на основании неправомерности подачи иска, не касаясь оспаривания предъявленных обвинений в нарушении GPL.

Представители организации SFC отталкиваются от того, что GPL имеет элементы договора и потребитель, которому лицензия предоставляет определённые права, является его участником и может потребовать исполнения своих прав на получение кода производного продукта. Согласие Федерального суда вернуть дело в Окружной суд подтверждает возможность применения к нарушению GPL законодательства о договорных отношениях (разбирательства о нарушении авторских прав ведутся в Федеральных судах, а о нарушении договора - в окружных).

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

Иск против Vizio был подан в 2021 году после трёхлетних попыток добиться выполнения требований лицензии GPL мирным путём. В прошивках умных телевизоров Vizio выявлены такие GPL-пакеты, как ядро Linux, U-Boot, Bash, gawk, GNU tar, glibc, FFmpeg, Bluez, BusyBox, Coreutils, glib, dnsmasq, DirectFB, libgcrypt и systemd, но компания не предоставила возможность запроса пользователем исходных текстов GPL-компонентов прошивки, а в информационных материалах не упомянула об использовании программного обеспечения под копилефт-лицензиями и предоставляемых данными лицензиями правах. Иск не предусматривает выплаты денежной компенсации, организация SFC лишь просит суд обязать Vizio выполнить условия GPL в своих продуктах и информировать потребителей о правах, которые предоставляют копилефт лицензии.

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

  1. OpenNews: Компания Vizio потребовала закрыть дело, связанное с нарушением лицензии GPL
  2. OpenNews: Против компании Vizio подан судебный иск с обвинением в нарушении лицензии GPL
  3. OpenNews: Проект Stockfish подал иск против компании ChessBase и отозвал лицензию GPL
  4. OpenNews: Апелляционный суд встал на сторону VMware в деле о нарушении GPL
  5. OpenNews: Решение суда о неправомерности удаления дополнительных условий к лицензии AGPL
Обсуждение (157 +45) | Тип: К сведению |
·17.05.2022 Релиз FreeBSD 13.1 (246 +33)
  После года разработки опубликован релиз FreeBSD 13.1. Установочные образы доступны для архитектур amd64, i386, powerpc, powerpc64, powerpc64le, powerpcspe, armv6, armv7, aarch64 и riscv64. Дополнительно подготовлены сборки для систем виртуализации (QCOW2, VHD, VMDK, raw) и облачных окружений Amazon EC2, Google Compute Engine и Vagrant.

В новой версии:

  • Предложен драйвер iwlwifi для беспроводных карт Intel c поддержкой новых чипов и стандарта 802.11ac. Драйвер основан на Linux-драйвере и коде из Linux-подсистемы net80211, работа которых во FreeBSD обеспечивается при помощи прослойки linuxkpi.
  • Реализация файловой системы ZFS обновлена до выпуска OpenZFS 2.1 с поддержкой технологии dRAID (Distributed Spare RAID) и значительными оптимизациями производительности.
  • Добавлен новый rc-скрипт zfskeys, при помощи которого можно на этапе загрузки организовать автоматическую расшифровку зашифрованных ZFS-разделов.
  • В сетевом стеке изменено поведение для IPv4-адресов с нулевым последним числом (x.x.x.0), который теперь можно использовать в качестве хоста и к нему по умолчанию не применяется отправка в широковещательном режиме. Старое поведение можно вернуть при помощи sysctl net.inet.ip.broadcast_lowest.
  • Для 64-разрядных архитектур включена по умолчанию сборка базовой системы с использованием режима PIE (Position Independent Executable). Для отключения предусмотрена настройка WITHOUT_PIE.
  • Добавлена возможность вызова chroot непривилегированным процессом, для которого выставлен флаг NO_NEW_PRIVS. Режим включается при помощи sysctl security.bsd.unprivileged_chroot. В утилиту chroot добавлена опция "-n", выставляющая для процесса флаг NO_NEW_PRIVS перед его изоляцией.
  • В инсталлятор bsdinstall добавлен режим автоматизированного редактирования дисковых разделов, позволяющий для разных имён дисков подключать сценарии разбивки, работающие без участия пользователя. Предложенная возможность упрощает создание полностью автоматически работающих установочных носителей для систем и виртуальных машин с разными дисками.
  • Улучшена поддержка загрузки на системах с UEFI. В загрузчике включена автоматическая настройка параметра copy_staging в зависимости от возможностей загружаемого ядра.
  • Проведена работа по повышению производительности загрузчика, nvme, rtsold, инициализации генератора псевдослучайных чисел и калибровки таймера, что привело к сокращению времени загрузки.
  • Добавлена поддержка работы NFS поверх шифрованного канала связи на базе TLS 1.3. Новая реализация использует предоставляемый ядром стек TLS, позволяющий задействовать средства аппаратного ускорения. Сборка процессов rpc.tlsclntd и rpc.tlsservd с реализацией клиента и сервера NFS-over-TLS, по умолчанию включена для архитектур amd64 и arm64.
  • Для NFSv4.1 и 4.2 реализована опция монтирования nconnect, определяющая число установленных с сервером TCP-соединений. Первое соединение используется для мелких RPC сообщений, а остальные для балансировки трафика с передаваемыми данными.
  • Для сервера NFS добавлен sysctl vfs.nfsd.srvmaxio, позволяющий изменить максимальный размер блока ввода/вывода (по умолчанию 128Kb).


  • Улучшена поддержка оборудования. В драйвер igc добавлена поддержка Ethernet-контроллера Intel I225. Улучшена поддержка Big-endian систем. Добавлен драйвер mgb для Ethernet-контроллера Microchip devices LAN7430 PCIe Gigabit Ethernet
  • Драйвер ice, используемый для Ethernet-контроллеров Intel E800, обновлён до версии 1.34.2-k, в которой появилась поддержка отражения в системном логе событий прошивки и добавлена начальная реализация расширений протокола DCB (Data center bridging).
  • В образах для Amazon EC2 по умолчанию включена загрузка с использованием UEFI вместо BIOS.
  • В гипервизоре bhyve обновлены компоненты для эмуляции накопителей NVMe, в которых обеспечена поддержка спецификации NVMe 1.4. Решены проблемы с NVMe iovec при интенсивном вводе/выводе.
  • Библиотека CAM переведена на использование вызова realpath при обработке имён устройств, что позволяет использовать символические ссылки на устройства в утилитах camcontrol и smartctl. В camcontrol решены проблемы с загрузкой прошивок на устройства.
  • Прекращена сборка утилиты svnlite в базовой системе.
  • Добавлены Linux-варианты утилит для вычисления контрольных сумм (md5sum, sha1sum и т.п.) которые реализованы путём вызова имеющихся BSD-утилит (md5, sha1 и т.п.) с опцией "-r".
  • В утилиту mpsutil добавлена поддержка управления NCQ и обеспечен показ информации об адаптере.
  • В /etc/defaults/rc.conf по умолчанию включено применение опции "-i" при вызове процессов rtsol и rtsold, отвечающих за отправку сообщений ICMPv6 RS (Router Solicitation). Указанная опция отключает случайную задержку перед отправкой сообщения.
  • Для архитектур riscv64 и riscv64sf включена сборка библиотек с ASAN (address sanitizer), UBSAN (Undefined Behavior Sanitizer), OpenMP и OFED (Open Fabrics Enterprise Distribution).
  • Решены проблемы с определением поддерживаемых процессорами ARMv7 и ARM64 средств аппаратного ускорения криптографических операций, что позволило существенно ускорить работу алгоритмов aes-256-gcm и sha256 на системах ARM.
  • Для архитектуры powerpc в основной состав включён отладчик LLDB, развиваемый проектом LLVM.
  • Библиотека OpenSSL обновлена до версии 1.1.1o и расширена применением ассемблерных оптимизаций для архитектур powerpc, powerpc64 и powerpc64le.
  • SSH-сервер и клиент обновлены до OpenSSH 8.8p1 с отключением поддержки цифровых подписей rsa-sha и поддержкой двухфакторной аутентификации при помощи устройств на базе протокола FIDO/U2F. Для взаимодействия с устройствами FIDO/U2F добавлены новые типы ключей "ecdsa-sk" и "ed25519-sk", в которых используются алгоритмы цифровой подписи ECDSA и Ed25519, в сочетании с хэшем SHA-256.
  • Обновлены версии входящих в базовую систему сторонних приложений: awk 20210215 (с патчами, отключающими использование локали для диапазонов и улучшающими совместимость с gawk и mawk), zlib 1.2.12, libarchive 3.6.0.

  1. OpenNews: Выпуск FreeBSD 12.3
  2. OpenNews: Дистрибутив Chimera Linux, сочетающий ядро Linux с окружением FreeBSD
  3. OpenNews: Релиз FreeBSD 13.0
  4. OpenNews: Выпуск дистрибутива helloSystem 0.5, использующего FreeBSD и напоминающего macOS
  5. OpenNews: Для FreeBSD развивается механизм изоляции, похожий на pledge и unveil
Обсуждение (246 +33) | Тип: Программы |
·17.05.2022 Выпуск редактора векторной графики Inkscape 1.2 (169 +28)
  После года разработки опубликован релиз свободного векторного графического редактора Inkscape 1.2. Редактор предоставляет гибкие инструменты для рисования и обеспечивает поддержку чтения и сохранения изображений в форматах SVG, OpenDocument Drawing, DXF, WMF, EMF, sk1, PDF, EPS, PostScript и PNG. Готовые сборки Inkscape подготовлены для Linux (AppImage, ожидается публикация Snap и Flatpak), macOS и Windows.

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

  • Добавлена поддержка многостраничных документов, позволяющих размещать в одном документе несколько страниц, импортировать их из многостраничных PDF-файлов и отдельно выбирать страницы при экспорте.
  • Переделано отображение палитры и образцов цветов. Добавлен новый диалог для настройки оформления панели с палитрой, позволяющий динамически и c мгновенным предпросмотром результата менять размер, число элементов, раскладку и отступы в палитре.
  • Объединены диалоги Слои ('Layers') и Объекты ('Objects').
  • Добавлен новый контурный Live-эффект (Tiling) для создания узоров и мозаичных структур, позволяющий быстро скопировать/продублировать большое число объектов или создать необычные шаблоны и вариации из повторяющихся структур.
  • Все опции выравнивания и расстановки перемещены в один общий диалог "Выровнять и расставить" ("Align and Distribute").
  • Добавлен новый интерфейс для управления привязкой к границам имеющихся фигур (Snapping to guides, прилипание к направляющим), позволяющий выравнивать объекты непосредственно на холсте, минимизируя обращение к инструментам выравнивания и расстановки.
  • Переделана панель для работы с градиентами. Управление градиентами объединено с диалогом управления заливкой и обводкой. Упрощена тонкая настройка параметров градиентов. Добавлен список цветов опорных точек для упрощения выбора опорной точки градиента.
  • Добавлен новый интерфейс редактирования маркеров и штриховых текстур.
  • Предоставлена возможность настройки содержимого панели инструментов. Инструменты можно группировать перетаскиванием за край, разносить по категориям и размещать в несколько столбцов.
  • Добавлена поддержка экспорта в пакетном режиме, позволяющего сохранить результат сразу в нескольких форматах, включая SVG и PDF.
  • Добавлена поддержка дизеринга (Dithering), позволяющая увеличить качество экспорта и отображения изображений с палитрой ограниченного размера (отсутствующие цвета воссоздаются путём перемешивания имеющихся цветов).
  • Предложено расширение Clipart Importer для поиска и загрузки материалов в формате SVG, размещённых на разных сайтах, включая Wikimedia, Open Clipart и коллекцию сообщества Inkscape.


  1. OpenNews: Выпуск редактора векторной графики Inkscape 1.1
  2. OpenNews: Выпуск редактора векторной графики Inkscape 1.0
  3. OpenNews: Объявлено о скором открытии кода векторного графического редактора Gravit
  4. OpenNews: Выпуск векторного графического редактора sK1 2.0RC2
  5. OpenNews: Выпуск экспериментального векторного графического редактора VPaint 1.7
Обсуждение (169 +28) | Тип: Программы |
·16.05.2022 Доступен PAPPL 1.2, фреймворк для организации вывода на печать (50 +9)
  Майкл Свит (Michael R Sweet), автор системы печати CUPS, представил выпуск PAPPL 1.2, фреймворка для разработки приложений для печати на базе протокола IPP Everywhere, которые рекомендуется использовать вместо традиционных драйверов для принтеров. Код фреймворка написан на языке Си и распространяется под лицензией Apache 2.0 с исключением, разрешающим связывание с кодом под лицензиями GPLv2 и LGPLv2.

Среди изменений в новой версии:

  • Добавлена полная поддержка локализации. Базовые наборы локализации предложены для английского, французского, немецкого, итальянского, японского и испанского языков.
  • Улучшена поддержка платформы macOS. Обеспечена интеграция с верхним глобальным меню macOS. Добавлена возможность выполнения приложений вывода на печать в режиме сервера.
  • Добавлена поддержка интерполяции при выводе на печать JPEG-изображений или при использовании функции papplJobFilterImage с включённым сглаживанием.
  • Реализованы дополнительные возможности протокола IPP (Internet Printing Protocol) и добавлены новые API: papplDeviceGetSupplies для определения уровня чернил и тонера, papplSystemAddEvent/papplSubscriptionXxx для обработки IPP-уведомлений, papplSystemGet/SetMaxClients для ограничения числа клиентов. В функциях papplPrinterDisable и papplPrinterEnable добавлена поддержка IPP-атрибута "printer-is-accepting-jobs".
  • Добавлена возможность задания собственных размеров листов в миллиметрах.
  • Добавлена поддержка библиотек OpenSSL и LibreSSL.
  • Обновлён код USB Gadget, используемый для создания клиентских USB-устройств и программной симуляции USB-устройств.
  • Обеспечена привязка к пользователю каталога со спулом печати, применяемым по умолчанию.
  • Улучшена совместимость с библиотекой libcups3.

Фреймворк PAPPL был изначально разработан для поддержки системы печати LPrint и драйверов Gutenprint, но может быть использован для реализации поддержки любых принтеров и драйверов при выводе на печать на настольных, серверных и встраиваемых системах. Предполагается, что PAPPL сможет способствовать ускорению продвижения технологии IPP Everywhere вместо классических драйверов и упрощению поддержки других программ на основе IPP, таких как AirPrint и Mopria.

PAPPL включает встроенную реализацию протокола IPP Everywhere, предоставляющего средства для доступа к принтерам локально или по сети и обработки запросов по выводу на печать. IPP Everywhere работает в бездрайверном режиме ("driverless") и в отличие от драйверов PPD не требует создания статических файлов конфигурации. Поддерживается взаимодействие с принтерами как напрямую через локальное подключение принтера по USB, так и обращение по сети при помощи протоколов AppSocket и JetDirect. Данные могут отправляться на принтер в форматах JPEG, PNG, PWG Raster, Apple Raster и "raw".

PAPPL может быть собран для POSIX-совместимых ОС, включая Linux, macOS, QNX и VxWorks. Из зависимостей отмечается Avahi (для поддержки mDNS/DNS-SD), CUPS, GNU TLS, JPEGLIB, LIBPNG, LIBPAM (для аутентификации) и ZLIB. На базе PAPPL проектом OpenPrinting развивается универсальное приложение PostScript Printer Application, способное работать как с современными IPP-совместимыми принтерами (используется PAPPL), поддерживающими PostScript и Ghostscript, так и со старыми принтерами, для которых имеются драйверы PPD (применяются фильтры cups-filters и libppd).

  1. OpenNews: Доступен PAPPL 1.1, фреймворк для организации вывода на печать
  2. OpenNews: Проект OpenPrinting выпустил систему печати CUPS 2.4.0
  3. OpenNews: Проект OpenPrinting взял на себя разработку системы печати CUPS
  4. OpenNews: Автор CUPS выпустил PAPPL 1.0, фреймворк для организации вывода на печать
  5. OpenNews: Проект OpenPrinting начал развитие форка системы печати CUPS
Обсуждение (50 +9) | Тип: Программы |
·15.05.2022 Состояние поддержки Wayland в драйверах NVIDIA (186 +33)
  Аарон Плaттнер (Aaron Plattner), один из ведущих разработчиков проприетарных драйверов NVIDIA, опубликовал сведения о состоянии поддержки протокола Wayland в проходящей тестирование ветке драйверов R515, для которой компания NVIDIA предоставила исходные тексты всех компонентов, работающих на уровне ядра. Отмечается, что в ряде областей поддержка протокола Wayland в драйвере NVIDIA пока не достигла паритета с поддержкой X11. При этом отставание связано как проблемами в драйвере NVIDIA, так и с общими ограничениями протокола Wayland и композитных серверов на его основе.

Ограничения драйвера:

  • В библиотеке libvdpau, позволяющей задействовать механизмы аппаратного ускорения для пост-обработки, композитинга, отображения и декодирования видео, отсутствует встроенная поддержка Wayland. Библиотека также не может использоваться с Xwayland.
  • Wayland и Xwayland не поддерживаются в библиотеке NvFBC (NVIDIA FrameBuffer Capture), применяемой для захвата содержимого экрана.
  • Модуль nvidia-drm не выдаёт информацию о возможностях, связанных с переменной частотой обновления экрана, таких как G-Sync, что не позволяет использовать их в окружениях на базе Wayland.
  • В окружениях на базе Wayland недоступен вывод на экраны виртуальной реальности, например, поддерживаемые платформой SteamVR, из-за неработоспособности механизма DRM Lease, предоставляющего DRM-ресурсы, необходимые для формирования стереокартинки с разными буферами для левого и правого глаза при выводе на шлемы виртуальной реальности.
  • Для Xwayland не реализована поддержка расширения EGL_EXT_platform_x11.
  • В модуле nvidia-drm не поддерживаются свойства GAMMA_LUT, DEGAMMA_LUT, CTM, COLOR_ENCODING и COLOR_RANGE, необходимые для полноценной поддержки цветокоррекции в композитных менеджерах.
  • При использовании Wayland ограничена функциональность утилиты nvidia-settings.
  • С Xwayland в GLX не работает отрисовка буфера вывода на экран (front-buffer) при двойной буферизации.

Ограничения протокола Wayland и композитных серверов:

  • В протоколе Wayland или композитных серверах не поддерживаются такие возможности как стереовывод, SLI, Multi-GPU Mosaic, Frame Lock, Genlock, Swap Groups и расширенные режимы дисплеев (деформация, смешивание, смещение пикселей и эмуляция YUV420). Судя по всему, для реализации подобной функциональности потребуется создание новых расширений EGL.
  • Отсутствует общепринятый API, позволяющий композитным серверам Wayland обесточивать видеопамять через PCI-Express Runtime D3 (RTD3).
  • В Xwayland отсутствует механизм, который можно было бы использовать в драйвере NVIDIA для синхронизации отрисовки приложением и вывода на экран. Без подобной синхронизации при некоторых обстоятельствах не исключается появление визуальных искажений.
  • В композитных серверах Wayland отсутствует поддержка мультиплексоров экрана (mux), применяемых на ноутбуках с двумя GPU (интегрированным и дискретным) для прямого соединения дискретного GPU c встроенным или внешним экраном. В X11 экран "mux" может автоматически переключаться, когда полноэкранное приложение осуществляет вывод через дискретный GPU.
  • В Xwayland не работает непрямой (indirect) рендеринг через GLX так как реализация архитектуры 2D-акселерации GLAMOR не совместима с реализацией EGL от NVIDIA.
  • В приложениях GLX, выполняемых в окружениях на базе Xwayland, не поддерживаются аппаратные оверлеи (Hardware overlay).

  1. OpenNews: Компания NVIDIA открыла код видеодрайверов для ядра Linux
  2. OpenNews: Доступен проприетарный драйвер NVIDIA 364.12 с поддержкой Wayland, Mir, KMS и Vulkan
  3. OpenNews: Выпуск XWayland 21.1.1.901 с поддержкой аппаратного ускорения на системах с GPU NVIDIA
  4. OpenNews: Выпуск проприетарного драйвера NVIDIA 510.47.03 с поддержкой Vulkan 1.3
  5. OpenNews: В Fedora Linux 36 намечено включение по умолчанию Wayland на системах с проприетарными драйверами NVIDIA
Обсуждение (186 +33) | Тип: Обобщение |
·15.05.2022 Уязвимость в Python, позволяющая вызвать системные команды из изолированных скриптов (127 +23)
  Опубликован метод обхода систем изолированного выполнения кода на языке Python, основанный на использовании давно известной ошибки, появившейся в Python 2.7, выявленной в 2012 году и до сих пор не исправленной в Python 3. Ошибка позволяет при помощи специально скомпонованного кода на языке Python инициировать обращение к уже освобождённой памяти (Use-After-Free) в СPython. Изначально предполагалось, что ошибка не представляет угрозы безопасности и лишь в очень редких случаях, как правило искусственно созданных, может привести к аварийному завершения скрипта.

Исследователь безопасности под псевдонимом kn32 заинтересовался проблемой и сумел подготовить рабочий эксплоит, дающий возможность вызвать любую системную команду, не имея прямого доступа к методам вида os.system. Эксплоит реализован на чистом языке Python и работает без импорта внешних библиотек и без установки обработчика "code.__new__". Из hook-ов используется только "builtin.__id__", который обычно не запрещён. С практической стороны предложенный код может применяться для обхода механизмов изоляции в различных сервисах и окружениях (например, в обучающих средах, online-оболочках, встроенных обработчиках и т.п.), допускающих выполнение кода на языке Python, но ограничивающих доступные вызовы и не позволяющих обращаться к таким методам, как os.system.

Предложенный код представляет собой аналог вызова os.system, работающий через эксплуатацию уязвимости в CPython. Эксплоит работает со всеми версиями Python 3 на системах с архитектурой x86-64 и демонстрирует стабильную работу в Ubuntu 22.04, даже при включении режимов защиты PIE, RELRO и CET. Работа сводится к получению из кода на языке Python сведений об адресе одной из функций в исполняемом коде CPython. На основании этого адреса вычисляется базовый адрес CPython в памяти и адрес функции system() в загруженном в память экземпляре libc. В завершении инициируется прямой переход по определённому адресу system c подстановкой указателя первого аргумента на строку "/bin/sh".

  1. OpenNews: Уязвимость в Python, проявляющаяся при обработке непроверенных дробных чисел в ctypes
  2. OpenNews: Уязвимость в PHP, позволяющая обойти ограничения, заданные в php.ini
  3. OpenNews: Обновление Python 3.8.5 с устранением уязвимостей
  4. OpenNews: В каталоге PyPI выявлены вредоносные библиотеки, использующие CDN PyPI для скрытия канала связи
  5. OpenNews: 46% Python-пакетов в репозитории PyPI содержат потенциально небезопасный код
Обсуждение (127 +23) | Тип: Проблемы безопасности |
Следующая страница (раньше) >>



Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру