· | 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%.
| ||
Обсуждение (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) ссылок и переменных по умолчанию, предлагает сильную статическую типизацию для минимизации логических ошибок. Основные новшества:
Дополнительно можно отметить статью "Rust: A Critical Retrospective" с обобщением впечатлений о языке Rust после написания на нём 100 тысяч строк кода в процессе разработки микроядерной операционной системы Xous, используемой в прошивках. Из недостатков отмечается трудный для восприятия синтаксис, незавершённость и продолжение развития языка, отсутствие повторяемых сборок, типовые проблемы с доверием к зависимостям в Crates.io, необходимость соблюдения определённой дисциплины для написания безопасного кода. Из возможностей превзошедших ожидания упоминаются средства для рефакторинга кода и переделки "хаков", добавленных при быстром создании прототипов.
| ||
Обсуждение (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:
| ||
Обсуждение (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).
| ||
Обсуждение (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 и примечателен отсутствием каких-либо привязок к коду, аффилированному с зарубежными компаниями, а также использованием полностью альтернативного стека технологий.
| ||
· | 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" и изолированных друг от друга.
| ||
Обсуждение (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), графикой и интерфейсом пользователя.
| ||
Обсуждение (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-файлов без необходимости использования файловой системы.
| ||
Обсуждение (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.
![]()
| ||
Обсуждение (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 в своих продуктах и информировать потребителей о правах, которые предоставляют копилефт лицензии. Производитель, использующий в своих продуктах код под копилефт лицензиями, для сохранения свободы ПО обязан предоставить исходные тексты, включая код производных работ и инструкции по установке. Без подобных действий пользователь теряет контроль над программным обеспечением, не может самостоятельно исправить ошибки, добавить новые возможности и удалить лишнюю функциональность. Внесение изменений может потребоваться для защиты своей конфиденциальности, устранения своими силами проблем, которые отказывается устранить производитель, и продления жизненного цикла устройства после прекращения его официальной поддержки или искусственного устаревания для стимулирования покупки новой модели.
| ||
Обсуждение (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.
В новой версии:
| ||
Обсуждение (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.
| ||
Обсуждение (169 +28) |
Тип: Программы |
| ||
· | 16.05.2022 | Доступен PAPPL 1.2, фреймворк для организации вывода на печать (50 +9) |
Майкл Свит (Michael R Sweet), автор системы печати CUPS, представил выпуск PAPPL 1.2, фреймворка для разработки приложений для печати на базе протокола IPP Everywhere, которые рекомендуется использовать вместо традиционных драйверов для принтеров. Код фреймворка написан на языке Си и распространяется под лицензией Apache 2.0 с исключением, разрешающим связывание с кодом под лицензиями GPLv2 и LGPLv2.
Среди изменений в новой версии:
Фреймворк 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).
| ||
Обсуждение (50 +9) |
Тип: Программы |
| ||
· | 15.05.2022 | Состояние поддержки Wayland в драйверах NVIDIA (186 +33) |
Аарон Плaттнер (Aaron Plattner), один из ведущих разработчиков проприетарных драйверов NVIDIA, опубликовал сведения о состоянии поддержки протокола Wayland в проходящей тестирование ветке драйверов R515, для которой компания NVIDIA предоставила исходные тексты всех компонентов, работающих на уровне ядра. Отмечается, что в ряде областей поддержка протокола Wayland в драйвере NVIDIA пока не достигла паритета с поддержкой X11. При этом отставание связано как проблемами в драйвере NVIDIA, так и с общими ограничениями протокола Wayland и композитных серверов на его основе.
Ограничения драйвера:
Ограничения протокола Wayland и композитных серверов:
| ||
Обсуждение (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". ![]()
| ||
Обсуждение (127 +23) |
Тип: Проблемы безопасности |
| ||
Следующая страница (раньше) >> |
Закладки на сайте Проследить за страницей |
Created 1996-2022 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |