Состоялся выпуск Lanemu P2P VPN 0.13 - реализации децентрализованной виртуальной частной сети, работающей по принципу Peer-To-Peer, при котором участники подключены друг к другу, а не через центральный сервер. Участники сети могут находить друг друга через BitTorrent-трекеры или BitTorrent DHT, либо через других участников сети (peer exchange). Приложение является бесплатным и открытым аналогом VPN Hamachi, написано на языке Java (c отдельными компонентами на языке Си) и распространяется под лицензией GNU LGPL 3.0. Поддерживается запуск в Windows, GNU/Linux, FreeBSD и Mac OS.
Изменения в версии 0.13:
Добавлена экспериментальная поддержка macOS для архитектур x86_64 и arm64. Работа в macOS требует дополнительную установку драйвера tap в отличии от Linux или FreeBSD.
Улучшена безопасность: для шифрования трафика используются разные ключи AES для отправки/принятия пакетов. Размер RSA-ключа увеличен с 2048 до 4096, что делает эту версию не совместимой с предыдущими версиями.
Улучшен алгоритм определения "вредоносных пиров" в DHT сети: добавлена возможность определения таких пиров одновременно.
Улучшено выпадающее меню для вкладки "Известные IP": добавлены пункты для копирования IP-адреса и ID пира.
Добавлена кнопка для переподключения ко всем адресам из вкладки "Известные IP" (Known IPs).
Для улучшения работы приложения с некоторыми играми метрика для сетевого интерфейса в Windows изменена с 10 на 1.
Добавлены цвета для нод пиров во вкладке "График пиров" (Peer graph). Цвета адаптируются к теме интерфейса.
Добавлен пункт меню "отключить пира" (Disconnect peer) в выпадающее меню в главном окне приложения.
Исправлена ошибка из-за которой пустые поля в таблице пиров нарушали работу фильтра.
Обновлены зависимости приложения.
Внесены мелкие улучшения и исправления в интерфейс.
Хакерская группа Crimson Collective заявила о получении доступа к одному из внутренних GitLab-серверов компании Red Hat и загрузке с него 570ГБ сжатых данных, содержащих информацию из 28 тысяч репозиториев. Среди прочего в захваченных данных присутствовало около 800 CER-отчётов (Customer Engagement Report), содержащих конфиденциальную информацию о платформах и сетевых инфраструктурах клиентов Red Hat, которым предоставлялись консалтинговые услуги.
В представленных атакующими скриншотах и примерах упоминается о получении данных, связанных с около 800 клиентами Red Hat, среди которых Vodafone, T-Mobile, Siemens, Boeing, Bosch, 3M, Cisco, DHL, Adobe, American Express, Verizon, JPMC, HSBC, Ericsson, Merrick Bank, Telefonica, Bank of America, Delta Air Lines, Walmart, Kaiser, IBM, SWIFT, IKEA и AT&T, а также Центр разработки надводного вооружения ВМС США, Федеральное управление гражданской авиации США, Федеральное агентство по управлению в чрезвычайных ситуациях США, Военно-воздушные силы США, Агентство национальной безопасности США, Ведомство по патентам и товарным знакам США, Сенат США и Палата представителей США.
Утверждается, что захваченные репозитории содержат сведения об инфраструктуре клиентов, конфигурацию, токены аутентификации, профили VPN, данные инвентаризации, Ansible playbook, настройки платформы OpenShift, CI/CD runner-ы, резервные копии и другие данные, которые могут быть использованы для организации атаки на внутренние сети клиентов. Злоумышленники пытались связаться с Red Hat с целью вымогательства, но получили лишь шаблонный ответ с предложением отправить в службу безопасности отчёт об уязвимости.
Компания Red Hat подтвердила инцидент с безопасностью, но не привела подробности и не прокомментировала информацию о содержимом утечки. Упоминается только то, что взломанный GitLab-сервер использовался в консалтинговом подразделении и компания предприняла шаги, необходимые для проверки и восстановления. Представители Red Hat утверждают, что у них нет оснований полагать, что взлом затронул другие сервисы и продукты компании, кроме одного сервера GitLab.
Представлен выпуск P2P-платформы Radicle 1.5, нацеленной на создание децентрализованного сервиса совместной разработки и хранения кода, похожего на GitHub и GitLab, но не привязанного к конкретным серверам, не подверженного цензуре и работающего с использованием ресурсов участников P2P-сети. Платформа поддерживает типовые элементы социального взаимодействия разработчиков, такие как issue, патчи и рецензии на код. Наработки проекта написаны на языке Rust и распространяются под лицензиями Apache 2.0 и MIT. Сборки подготовлены для Linux и macOS. Дополнительно развиваются десктоп-клиент, web-интерфейс и консольный интерфейс.
Radicle позволяет не зависеть при разработке и распространении кода от централизованных платформ и корпораций, привязка к которым вносит дополнительные риски (единая точка отказа, компания может закрыться или изменить условия работы). Для управления кодом в Radicle используется привычный Git, расширенный средствами определения репозиториев в P2P-сети. Все данные в первую очередь сохраняются локально (концепция local-first) и всегда доступны на компьютере разработчика, независимо от состояния сетевого подключения.
Участники предоставляют доступ к своему коду и связанным с кодом артефактам, таким как патчи и обсуждения исправления ошибок (issues), которые сохраняются локально и реплицируются на узлы других заинтересованных разработчиков, подключённые к общей децентрализованной P2P-сети. В итоге формируется глобальный децентрализованный Git-репозиторий, данные которого реплицированы и продублированы на разных системах участников.
Для определения соседних узлов в P2P-сети применяется протокол Gossip, а для репликации данных между узлами протокол Heartwood, основанный на Git. Так как протокол основан на Git, платформу легко интегрировать с существующими инструментами для разработки на Git. Для идентификации узлов и верификации репозиториев используется криптография на основе открытых ключей, без применения учётных записей. Аутентификация и авторизация осуществляется на основе открытых ключей без централизованных удостоверяющих серверов.
Каждый репозиторий в P2P-сети имеет свой уникальный идентификатор и самосертифицирован (self-certifying), т.е. все действия в репозитории, такие как добавление коммитов и оставление комментариев к issue, заверяются владельцем цифровой подписью, позволяющей убедиться в корректности данных на других узлах без использования централизованных удостоверяющих центров. Для получения доступа к репозиторию достаточно, чтобы в online находился хотя бы один узел, на котором имеется его реплицированная копия.
Узлы в P2P-сети могут подписываться на определённые репозитории и получать обновления. Возможно создание приватных репозиториев, доступных только определённым узлам. Для управления и владения репозиторием используется концепция "делегатов" (delegates). Делегатом может быть как отдельный пользователь так и бот или группа, привязанные к специальному идентификатору. Делегаты могут принимать в репозиторий патчи, закрывать issue и задавать права доступа к репозиторию. К каждому репозиторию может быть привязано несколько делегатов.
Radicle-репозитории хранятся на системах пользователей в виде обычных git-репозиториев, в которых присутствуют дополнительные пространства имён для хранения данных пиров и форков, с которыми осуществляется текущая работа. Обсуждения, предлагаемые патчи и компоненты для организации рецензирования тоже сохраняются в git-репозитории в виде совместных объектов (COB - Collaborative Objects) и реплицируются между пирами.
В новом выпуске:
Улучшена поддержка bare-репозиториев, не содержащих рабочего каталога с копией файлов проекта, а хранящих только историю изменений и метаданные, такие как ветки и теги. В команду "rad clone" добавлена опция "--bare", позволяющая клонировать репозиторий в представление без рабочего дерева. В утилите "git-remote-rad" улучшена работа с bare-репозиториями при использовании команд "git push" и "git fetch" при обращении к внешнему rad-серверу.
Добавлена настройка "patch.branch", которую можно использовать в утилите git-remote-rad ("git-remote-rad -o patch.branch[=<name>]")
при добавлении патча для автоматического создания ветки в upstream-репозитории, без необходимости использования команды "rad patch checkout".
Улучшен вывод команды "rad patch show", которая теперь показывает исходную версию патча, выводимую ранее только при указании флага "--verbose". Все ревизии теперь выводится в единой хронологии без разделения на изменений от оригинального автора и других участников.
Добавлена возможность вывода логов в структурированном представлении, включаемом через опции "--log-logger structured" и "--log-format json".
Состоялся релиз библиотеки OpenSSL 3.6.0, предлагающей с реализацию протоколов SSL/TLS и различных алгоритмов шифрования. OpenSSL 3.6 отнесён к выпускам с обычным сроком поддержки, обновления для которых выпускаются в течение 13 месяцев. Поддержка прошлых веток OpenSSL 3.5 LTS, 3.4, 3.3, 3.2 и 3.0 LTS продлится до апреля 2030 года, октября 2026 года, апреля 2026 года, ноября 2025 года и сентября 2026 года соответственно. Код проекта распространяется под лицензией Apache 2.0.
Добавлена поддержка структуры EVP_SKEY (Symmetric KEY) для представления симметричных ключей как непрозрачных (opaque) объектов. В отличие от raw-ключей, представленных массивом байтов, в EVP_SKEY структура ключа абстрагируется и содержит дополнительные метаданные. Допустимо применение EVP_SKEY в функциях шифрования, обмена ключами и формирования ключей (KDF). Для работы с ключами EVP_SKEY добавлены функции EVP_KDF_CTX_set_SKEY(), EVP_KDF_derive_SKEY() и EVP_PKEY_derive_SKEY().
Добавлена поддержка верификации цифровых подписей на базе схемы LMS (Leighton-Micali Signatures), использующей хэш-функции и древовидное хэширование в форме дерева Меркла (Merkle Tree, каждая ветка верифицирует все нижележащие ветки и узлы). Цифровые подписи LMS устойчивых к подбору на квантовом компьютере и разработаны для заверения целостности прошивок и приложений.
Добавлена поддержка категорий безопасности NIST для параметров объектов PKEY (открытые и закрытые ключи). Выставление категории безопасности осуществляется через настройку
"security-category". Для проверки уровня безопасности добавлена функция EVP_PKEY_get_security_category(). Уровень безопасности отражает стойкость к подбору на квантовых компьютерах и может принимать целые значения от 0 до 5:
0 - реализация, не стойкая ко взлому на квантовых компьютерах;
1/3/5 - реализация не исключает поиск на квантовом компьютере ключа в блочном шифре со 128/192/256-битным ключом;
2/4 - реализация не исключает поиск на квантовом компьютере коллизии в 256/384-битном хэше).
Добавлена команда "openssl configutl" для обработки файла конфигурации. Утилита позволяет на основе многофайловой конфигурации с include-включениями сформировать сводный файл со всеми настройками.
В криптопровайдер FIPS добавлена поддержка детерминированного формирования цифровых подписей ECDSA (при одних и тех же входных данных генерируется одна и та же подпись), в соответствии с требованиями стандарта FIPS 186-5.
Повышены требования к сборочному окружению. Для сборки OpenSSL теперь недостаточно инструментария с поддержкой ANSI-C и требуется компилятор, совместимый со стандартом C-99.
CVE-2025-9230 - уязвимость в коде дешифровки CMS-сообщений, зашифрованных с использованием пароля (PWRI). Уязвимость может привести к записи и чтению данных вне выделенного буфера, что позволяет инициировать аварийное завершение или повреждение памяти в приложении, использующем OpenSSL для обработки CMS-сообщений. Не исключается эксплуатация уязвимости для организации выполнения своего кода, но опасность проблемы снижает то, что шифрование CMS-сообщений с использованием пароля на практике применяется крайне редко. Кроме версии OpenSSL 3.6.0 уязвимость устранена в выпусках OpenSSL 3.5.4, 3.4.3, 3.3.5, 3.2.6 и 3.0.18. Проблема также исправлена в обновлениях библиотеки LibreSSL 4.0.1 и 4.1.1, развиваемой проектом OpenBSD.
CVE-2025-9231 - реализация алгоритма SM2 подвержена атаке по сторонним каналам, позволяющей на системах с 64-разрядными CPU ARM воссоздать закрытый ключ, анализируя изменение времени выполнения отдельных вычислений. Потенциально атака может быть проведена удалённо. Опасность атаки снижает то, что OpenSSL напрямую не поддерживает использование сертификатов с ключами SM2 в TLS.
CVE-2025-9232 - уязвимость в реализации встроенного HTTP-клиента, приводящая к чтению данных из области вне буфера при обработке в функциях HTTP Client специально оформленного URL. Проблема проявляется только при выставленной переменной окружения "no_proxy" и может привести к аварийному завершению приложения.
Спустя более 10 лет после публикации прошлого значительного релиза сформирован выпуск проекта Cairo-Dock 3.6, нацеленного на создание визуально привлекательной, быстрой и настраиваемой панели запуска программ. Cairo-Dock может использоваться как самостоятельная оболочка или применяться для замены или дополнения панелей, штатных для десктоп-окружений. Код проекта написан на языке Си и распространяется под лицензией GPLv3. Готовые пакеты сформированы для Ubuntu и Fedora, в процессе подготовки пакет для Arch Linux.
Для ускорения отрисовки используется OpenGL, но на устаревших системах панель может работать в без визуальных эффектов в упрощённом режиме, потребляя минимум ресурсов. Предоставляются бэкенды для работы в окружениях на базе Wayland и X11. На системах с X11 поддерживается работа с любым оконным менеджером, а с Wayland - с композитными менеджерами, поддерживающими протокол wlr-layer-shell. Через официальные и разработанные сообществом плагины могут добавляться эффекты, макеты панели, анимации и апплеты. Через апплеты могут реализовываться дополнительные действия, такие как отображение состояния почтового ящика, приём и отправка мгновенных сообщений, контроль за работой медиаплеера, слежение за RSS-лентами, просмотр состояния загрузки торрентов, отображение погоды и вывод заданий из календаря-планировщика. Апплеты могут интегрироваться в панель и отсоединяться для превращения в десктоп-виджеты.
Ключевые новшества:
Реализована полноценная возможность работы в сеансах на базе протокола Wayland. Поддерживаются только композитные серверы с реализацией Wayland-протокола wlr-layer-shell, развиваемого разработчиками библиотеки wlroots и предназначенного для позиционирования панели на экране. Для функционирования также требуется поддержка одного из Wayland-протоколов для управления окнами верхнего уровня (wlr-foreign-toplevel-management, plasma-window-managementcosmic-toplevel-management).
Протестирована работа с композитными серверами Wayfire, labwc, KDE KWin, Cosmic, Sway и Hyprland, но потенциально Cairo-Dock может использоваться с любыми проектами на базе wlroots. Не поддерживается работа с композитным менеджером Mutter - Cairo-Dock не совместим с GNOME и не может применяться с рабочим столом, предлагаемым по умолчанию в Ubuntu Desktop. Из ограничений также отмечается отсутствие поддержки глобальных комбинаций клавиш, ограничения одним экранном в многомониторных конфигурациях и проблемы с размещением десклетов и отслеживанием содержимого виртуальных рабочих столов.
Добавлена поддержка экранов с высокой плотностью пикселей (HiDPI). Решена проблема с размыванием элементов при отрисковке с масштабированием для экранов с очень большим разрешением.
Переработан код для определения приложений, что решило проблемы с неверной идентификацией приложений.
Обновлён апплет для показа прогноза погоды, который переведён на нового провайдера, предоставляющего данные о погоде.
Обеспечена интеграция с системным менеджером systemd. Cairo-Dock теперь может запускаться как сервис systemd, а для каждого запускаемого через Cairo-Dock приложения может создаваться отдельный slice в systemd.
Состоялся релиз дистрибутива openSUSE Leap 16.0, построенного на технологиях следующей значительной ветки коммерческого дистрибутива SLES 16, переходящего на новую платформу SLFO (SUSE Linux Framework One), ранее известную под именем ALP (Adaptable Linux Platform). openSUSE Leap 16 сохранил черты классического дистрибутива, использующего традиционные пакеты, а для тех кому необходима атомарно обновляемая система с базовой начинкой в режиме только для чтения следует использовать редакцию openSUSE Leap Micro. Для загрузки доступна универсальная DVD-сборка, размером 4.2 ГБ (x86_64, aarch64, ppc64le, 390x) и урезанный образ для установки с загрузкой пакетов по сети (600 МБ).
Время формирования обновлений для выпусков openSUSE Leap 16.x продлено с полутора до двух лет (два полных цикла подготовки релизов). Промежуточные выпуски в ветке openSUSE Leap 16, сопровождаемой параллельно с коммерческим дистрибутивом SUSE Linux Enterprise 16, будут формироваться до осени 2031 года - финальным станет выпуск openSUSE Leap 16.6, обновления для которого будут выпускаться до осени 2033 года. Как и раньше новые значительные выпуски дистрибутива будут публиковаться раз в год.
Задействован новый инсталлятор Agama, примечательный отделением пользовательского интерфейса от внутренних компонентов YaST и поставкой фронтенда для управления установкой через web-интерфейс.
В инсталляторе для установки предложены только среды рабочего стола, использующие Wayland.
Вместо традиционного стека YaST для управления системой задействован пакет Cockpit, а вместо YaST Software GUI предложен новый пакет Myrlyn.
По умолчанию включена система мандатного контроля доступа SELinux. Поддержка AppArmor сохранена в качестве опции.
Прекращена поддержка скриптов инициализации SysV. Возможно использование только unit-ов systemd.
Прекращена поддержка архитектуры x86-64-v1. Работа возможна только на системах x86 с архитектурой x86_64-v2, которая поддерживается процессорами примерно с 2009 года (начиная с Intel Nehalem) и отличается наличием таких расширений, как SSE3, SSE4_2, SSSE3, POPCNT, LAHF-SAHF и CMPXCHG16B.
По умолчанию в ядре отключена поддержка 32-разрядных систем x86 и запуска 32-разрядных исполняемых файлов. Для продолжения использования приложения Steam, которое существует только в 32-разрядной версии и требует для запуска наличия в системе установленных 32-битных зависимостей, в openSUSE реализован пакет grub2-compat-ia32, выставляющий параметр "ia32_emulation=1" при загрузке ядра Linux. Для работы Steam также потребуется установка пакета selinux-policy-targeted-gaming, не входящего в базовую поставку.
Пакет Wine доступен только в 64-разрядных сборках, использующих режим Wow64 (64-bit Windows-on-Windows) для выполнения 32-разрядных Windows-приложений в 64-разрядных Unix-системах.
Для управления репозиториями задействован сервис на базе протокола RIS (Repository Index Service). Для сокращения размера метаданных репозитории разделены для каждой поддерживаемой архитектуры. Вместо нескольких репозиториев задействован один общий репозиторий пакетов repo-oss, включающий как пакеты из SUSE Linux Enterprise, так и пакеты, сопровождаемые сообществом.
В пакетном менеджере Zypper реализована возможность распараллеливания загрузки пакетов и метаданных, а также предложен новый бэкенд, более оптимально повторно использующий уже установленные соединения и повышающий эффективность обработки метаданных. При обновлении 250 пакетов суммарным размером 100 МБ время загрузки после включения нового бэкенда и параллельного режима сократилось с 68.7 секунд до 13.1 секунды, а при обновлении 407 пакетов размером 1 ГБ - с 281.1 секунды до 119.6 секунд.
Добавлены варианты популярных библиотек, таких как boost, openjpeg2, sqlite3, libgcrypt, openssl и zlib, собранные с оптимизациями для новых CPU. Загрузка оптимизированных вариантов на системах с новыми CPU осуществляется компоновщиком из подкаталогов glibc-hwcaps, созданных в областях ФС, просматриваемых при поиске библиотек.
Для систем с видеокартами NVIDIA по умолчанию задействованы открытые модули ядра и обеспечена автоматическая установка компонентов пространства пользователя, необходимых для ускорения графических операций.
По умолчанию вместо PulseAudio задействован мультимедийный сервер PipeWire.
Для настройки сетевых подключений оставлен только NetworkManager.
Для применения исправлений к библиотекам в пространстве пользователя без остановки их работы задействован инструментарий libpulp. Live-патчи применяются для устранения критических ошибок и уязвимостей в glibc и openssl на системах с архитектурами x86-64 и ppc64le.
Для сетевых интерфейсов задействована схема с предсказуемым выбором имён, при которой сетевому адаптеру назначается фиксированное имя, которое не изменится при добавлении/удалении других адаптеров.
Применяемые по умолчанию настройки systemd перенесены из каталога /etc в /usr.
По умолчанию отключён доступ по SSH с пользователем root при аутентификации по паролю.
В состав включён фоновый процесс tuned, выполняющий автоматическую оптимизацию настроек оборудования и ядра в зависимости от текущей нагрузки.
Добавлена поддержка NFS поверх TLS.
Для хранения раздела /tmp задействована ФС tmpfs, хранящая данные в памяти и не сохраняющая содержимое между перезапусками.
Обновлены пользовательские окружения: GNOME 48 (в прошлом выпуске был GNOME 45), KDE 6.4 (был 5.27), Cinnamon 6.4 (был 6.0), LxQt 2.2 (был 1.2), Xfce 4.20 (был 4.18), MATE 1.28 (был 1.26), Sway 1.10 (был 1.6). Компоненты графического стека обновлены до Mesa 24.3 и Qt 6.9. Предоставлена возможность использования варианта Xfce 4.20 поверх композитного менеджера labwc, использующего Wayland. Для организации работы экрана входа в систему вместо LightDM реализована возможность использования greetd и gtkgreet. Добавлен Wayland-сеанс на базе LXQt.
Компания Google опубликовала релиз web-браузера Chrome 141. Одновременно доступен стабильный выпуск свободного проекта Chromium, выступающего основой Chrome. Браузер Chrome отличается от Chromium использованием логотипов Google, наличием системы отправки уведомлений в случае краха, модулями для воспроизведения защищённого от копирования видеоконтента (DRM), системой автоматической установки обновлений, постоянным включением Sandbox-изоляции, поставкой ключей к Google API и передачей RLZ-параметров при поиске. Для тех, кому необходимо больше времени на обновление, отдельно поддерживается ветка Extended Stable, сопровождаемая 8 недель. Следующий выпуск Chrome 142 запланирован на 28 октября.
Для части пользователей активирован интегрированный в браузер чат-бот Gemini, который может пояснять содержимое просматриваемой страницы и отвечать на связанные со страницей вопросы, не переключаясь с текущей вкладки. Для вызова Gemini в верхний правый угол экрана добавлена кнопка, при нажатии на которую выводится диалог, позволяющий задавать вопросы на естественном языке и выбирать вкладки, содержимое которых должен учитывать AI при формировании ответа. Поддерживается текстовое и голосовое общение с ботом. Возможность доступна для пользователей из США, имеющих доступ к приложению Gemini и использующих платформы macOS, iOS и Windows.
Включена защита от обращения к локальной системе (loopback, 127.0.0.0/8) или внутренней сети (192.168.0.0/16, 10.0.0.0/8 и т.п.) при взаимодействии с публичными сайтами. При попытке загрузки внутренних ресурсов браузер теперь станет выводить пользователю диалог с запросом подтверждения операции. Обращение к внутренним ресурсам используются злоумышленниками для осуществления CSRF-атак на маршрутизаторы, точки доступа, принтеры, корпоративные web-интерфейсы и другие устройства и сервисы, принимающие запросы только из локальной сети. Кроме того, сканирование внутренних ресурсов может использоваться для косвенной идентификации или сбору сведений о локальной сети.
Начался переход на более гранулированную модель изоляции процессов - "Origin Isolation", при которой каждый источник контента (origin - связка из протокола, домена и порта, например, "https://foo.example.com"), изолируется в отдельном процессе отрисовки. Так как увеличение дробления изоляции может привести к повышению потребления памяти и росту нагрузки на CPU, новый режим изоляции включается только на системах, имеющих больше 4 ГБ ОЗУ. На маломощном оборудовании продолжит использоваться старый подход к изоляции, при котором в отдельном процессе изолируются все разные источники контента, связанные с одним сайтом (например, foo.example.com и bar.example.com). Возможность пока активирована для части пользователей, постепенно охват будет увеличиваться.
Включено применение политики "Same Origin" для API Storage Access API. Вызов "document.requestStorageAccess()" из кода, загруженного через iframe c другого сайта, по умолчанию теперь будет охватывать только сайт, с которого загружен этот iframe, а не сайт, на котором размещён iframe.
Добавлена эвристика для выявления на стороне клиента перехвата или перенаправления на внешние сайты поисковых запросов, вводимых в адресной строке или на странице, показываемой при открытии новой вкладки. Подобный перехват применяется некоторыми вредоносными дополнениями. Проверка осуществляется через сопоставление вводимых пользователем запросов с появлением страницы с результатами поиска. При выявлении подмены в режиме Safe Browsing на сервер Google отправляется телеметрия для более детального анализа, учитывающего телеметрию от разных пользователей.
На странице открытия новой вкладки в нижней панели, на которой показывается информация о дополнениях, влияющих на содержимое страницы новой вкладки, обеспечен показ сведений о работе на устройстве, к которому применяется централизованное управление.
На системах с профилями пользователей, привязанными к сторонним провайдерам аутентификации, реализована возможность выполнения удалённых команд администрирования, например, для очистки кэша или Cookie.
В API IndexedDB реализован метод getAllRecords(), позволяющий извлечь все записи из хранилища объектов (IDBObjectStore) и индекса (IDBIndex). getAllRecords() сочетает в себе функциональность методов getAllKeys() и getAll() для извлечения как первичных ключей, так и связанных с ними значений. В методы getAll() и getAllKeys() добавлен параметр "direction" для определения направления извлечения данных, что позволяет ускорить определённые операции чтения по сравнению с применением курсоров.
Добавлен API "WebRTC Encoded Transform" для обработки закодированных мультимедийных данных, передаваемых через RTCPeerConnection.
Добавлена поддержка атрибутов "width" и "height" для вложенных элементов <SVG>, размером которых можно управлять через CSS или SVG-разметку.
Внесены улучшения в инструменты для web-разработчиков.
Добавлен экспериментальный MCP (Model Context Protocol) сервер, позволяющий обращаться к возможностям Chrome DevTools из внешних AI-ассистентов.
Информация об исправленных уязвимостях в анонсе и трекере изменений на момент написания новости отсутствует.
Дополнение: Спустя сутки после релиза раскрыты сведения об исправленных уязвимостях. В Chrome 141 устранена 21 уязвимость. Многие из уязвимостей выявлены в результате автоматизированного тестирования инструментами AddressSanitizer, MemorySanitizer, Control Flow Integrity, LibFuzzer и AFL. Критических проблем, которые позволяют обойти все уровни защиты браузера и выполнить код в системе за пределами sandbox-окружения, не выявлено. В рамках программы по выплате денежного вознаграждения за обнаружение уязвимостей для текущего релиза компания Google выплатила 12 премии на сумму 50 тысяч долларов США (по одной премии $25000, $5000, $4000 и $2000, четыре премии $3000 и две $1000). Размер одного вознаграждения пока не определён.
Под покровительство организации Linux Foundation переведён движок симуляции физических процессов Newton, совместно разработанный компаниями NVIDIA, Disney Research и Google DeepMind. Отмечается, что перевод Newton на независимую нейтральную площадку, не контролируемую отдельными компаниями, позволит привлечь к разработке новых участников. К совместной работе над проектом уже подключились компании Lightwheel и Style3D, а также исследователи из Мюнхенского и Пекинского университетов. Код Newton написан на языке Python и распространяется под лицензией Apache 2.0.
Движок создан для быстрой и масштабируемой симуляции процессов и проведения исследований в области робототехники. Среди прочего, Newton позволяет симулировать сложное поведение роботов с большим числом взаимодействий, такое как ходьба по снегу или манипуляции с хрупкими объектами. Среди ключевых достоинств проекта отмечено задействование GPU для ускорения операций и быстрой масштабируемой симуляции, а также расширяемая архитектура, позволяющая подключать и заменять компоненты.
Для ускорения моделирования процессов и пространственных вычислений с использованием GPU задействован фреймворк NVIDIA Warp, а для переносимого представления иерархически связанных данных, образующих графическую сцену, применена платформа OpenUSD.
Для проведения моделирования можно использовать разные бэкенды проведения расчётов физических процессов (solver). В качестве основного бэкенда задействован движок MuJoCo (Multi-Joint dynamics with Contact), а в качестве опций доступны бэкенды, реализующие методы Euler, Featherstone, ImplicitMPM, SemiImplicit, Style3D, VBD и XPBD. Возможна загрузка моделей в форматах URDF, MJCF и USD.
Поддерживается дифференцируемая симуляция, позволяющая использовать градиентные методы и вычислять производные от выходных параметров симуляции по отношению к входным параметрам для оптимизации параметров симуляции или применения в машинном обучении. Например, можно использовать движок для оптимизации процессов и обучения роботов точным манипуляциям в симулированной среде. Поддерживается визуализация процесса симуляции в режиме реального времени.
Представлен четвёртый экспериментальный выпуск клиента для мгновенного обмена сообщениями Pidgin 3.0 (2.93). Выпуск отмечен как имеющий уровень качества предварительной альфа-версии, не рассчитанной на повседневное применение. Сборки подготовлены в формате Flatpak (пока доступен только архив с кодом).
Ветка Pidgin 3 разрабатывается с 2011 года, а до этого ещё три года обсуждалась на уровне концепций и идей. В Pidgin 3 выполнен переход на систему типов GObject, библиотеки GTK4 и Adwaita, сборочную систему Meson, GPlugin для обработки плагинов, SQLite для хранения истории чатов и GSettings для работы с настройками. Полностью переработан API. Для определения элементов интерфейса задействован GTK Builder XML, а для отображения истории чатов создана собственная библиотека виджетов Talkatu.
В интерфейсе Pidgin 3 объединены в одном окне список контактов и чат. Прекращена поставка консольного клиента Finch (не исключено, что его могут вернуть в будущем). Из протоколов пока поддерживается только IRCv3, а также развиваются новые реализации протоколов XMPP, SIP и Bonjour, которые пока поддерживаются частично. Ветка Pidgin 3 несовместима с Pidgin 2 и ранее созданными плагинами, но может быть установлена параллельно с имеющимися сборками Pidgin 2.
Среди изменений в представленном тестовом выпуске:
Реализована концепция бэкендов для постоянного хранения данных, таких как история переписки и активные чаты. Доступен бэкенд на базе SQLite.
При закрытии приложения по умолчанию обеспечено сохранение всех открытых чатов, без необходимости вручную добавлять канал в список контактов и активировать автоподключение к каналу. Подобные операции теперь выполняются автоматически для личных сообщений, групповых сообщений и чат-каналов, открытых на момент закрытия программы.
Представлена новая пиктограмма приложения.
Добавлены настройки цветовой схемы, через которые можно переключаться между тёмными и светлыми режимами или активировать системную тему оформления.
Доступен корректирующий выпуск Firefox 143.0.3, в котором устранено несколько проблем:
Откорректировано время срабатывания закрепления вкладки в форме постоянно видимого ярлыка после перетаскивания вкладки мышью в начало панели вкладок. Поведение перетаскивания для закрепления приближено к операции перетаскивания группы вкладок.
Решена проблема, не позволявшая обновить некоторые дополнения через Add-ons Manager.
Устранено регрессивное изменение, из-за которого перестало работать сворачивание и раскрытие секций на странице Firefox View.
Устранена ошибка в реализации хранилища для WebExtensions, приводившая к аварийному завершению во время запуска при установке некоторых дополнений, таких как Notefox.
Исправлена проблема, приводившая к нарушению работы интерфейса настройки содержимого панели (Application Menu [≡] > More Tools > Customize Toolbar) и некоторых клавиатурных комбинаций после открытия страницы с настройками дополнения ("Extension settings") после его установки.
Устранены длительные задержки (~5 секунд) при загрузке некоторых сайтов при работе из сетей, блокирующих UDP-пакеты.
Исправлена уязвимость (CVE-2025-11152), позволяющая обойти sandbox-изоляцию из-за целочисленного переполнения в компоненте Canvas2D.
Устранена уязвимость (CVE-2025-11153), приводящая к неверной генерации машинного кода JIT-компилятором в JavaScript-движке.
Представлена прошивка Ubuntu Touch 24.04-1.0, развиваемая проектом UBports, взявшим в свои руки разработку мобильной платформы Ubuntu Touch, после того как от неё отстранилась компания Canonical. Это первый выпуск Ubuntu Touch, основанный на пакетной базе Ubuntu 24.04. Проектом также развивается экспериментальный порт рабочего стола Unity 8, который переименован в Lomiri.
Обновление Ubuntu Touch 24.04-1.0 в ближайшие дни будет сформировано для устройств
Asus Zenfone Max Pro M1, F(x)tec Pro1 X, Fairphone 3/3+/4, Google Pixel 3a/3a XL, JingPad A1, Oneplus 5/5T/6/6T, OnePlus Nord N10 5G/N100, Sony Xperia X, Vollaphone X/22/X23, Xiaomi Poco X3 NFC / X3, Xiaomi Poco M2 Pro, Xiaomi Redmi Note 9 Pro/Pro Max/9S, Volla Phone Quintus, Volla Tablet, Lenovo Tab M10 HD 2nd Gen, Rabbit R1 и Xiaomi Redmi 9/9 Prime. По сравнению с прошлым выпуском добавлены сборки для устройства Fairphone 5.
Среди изменений в Ubuntu Touch 24.04-1.0:
Осуществлён переход на пакетную базу Ubuntu 24.04. С марта 2023 года в качестве базовой платформы использовалась ветка Ubuntu 20.04.
Задействован новый логотип.
Реализован светлый вариант оформления пользовательской оболочки, который можно включить в настройках "System Settings > Background & Appearance".
Добавлена экспериментальная поддержка переключения тем оформления в live-режиме.
Добавлена экспериментальная поддержка шифрования персональных данных, позволяющая защитить информацию пользователя в случае кражи устройства. Пользовательские данные шифруются с использованием заданного пароля или кода доступа, который необходимо вводить во время загрузки. Поддержка шифрования доступна не на всех устройствах и может быть включена через настройку "System Settings > Security & Privacy > Encryption (Experimental)".
Добавлен новый вариант интерфейса приложения для осуществления звонков, оптимизированный для больших экранов смартфонов и поддерживающий отображение в ландшафтном режиме.
Добавлен интерфейс "System Settings > USB" для переключения режимов работы USB, в котором можно включить раздачу доступа к интернету через кабель USB или передачу файлов поверх USB.
В настройках Bluetooth обеспечен показ MAC-адреса устройства и реализована опция для повторного сканирования близлежащих устройств.
В экранной клавиатуре отключены по умолчанию режимы автоматической вставки заглавных букв, автокоррекции и автопунктуации.
Улучшена работа в режиме рабочего стола, активируемого при подключении смартфона к стационарному монитору.
Для перемещения приложений между виртуальными рабочими столами добавлены комбинации клавиш Ctrl + Alt + Shift + клавиши управления курсором.
Предоставлена возможность выбора информации, показываемой в меню индикатора с датой и временем. Можно настроить показ календаря, номеров недель, событий и будильников.
В настройках звука (System Settings > Sound) добавлена возможность выбора звука, применяемого для напоминаний в календаре-планировщике.
В настройках Wi-Fi обеспечен показ дополнительной информации об используемой беспроводной сети.
Представлен релиз дистрибутива MiniOS Flux 5.1, работающего напрямую с USB-накопителя. MiniOS Flux представляет собой минималистичную редакцию с оконным менеджером Fluxbox, вдохновлённую дистрибутивом Slax. Дистрибутив использует модульную архитектуру, позволяющую создавать специализированные конфигурации для адаптации системы под конкретные задачи.
Релиз доступен в виде компактных образов на базе разных версий Debian, поддерживающих архитектуры amd64 и i386:
Восстановлено меню SYSLINUX для загрузки через BIOS с многоязычной поддержкой и встроенной справочной документацией на всех поддерживаемых языках (английский, немецкий, испанский, французский, индонезийский, итальянский, португальский, португальский (Бразилия), русский). Устранены проблемы совместимости со старым оборудованием.
Улучшена работа с постоянным хранилищем (persistent storage):
Добавлена поддержка единиц измерения размера для параметра "perchsize": MB, GB, TB (например, "perchsize=4GB" или "perchsize=1T");
Установлен максимальный размер DynFileFS в 1 ТБ для предотвращения избыточного выделения дискового пространства;
Улучшены сообщения при работе с режимом постоянного хранения, объединённой файловой системой и несоответствии версий/редакций.
Восстановлена нормальная загрузка в среде Ventoy с добавлением необходимых символических ссылок для совместимости.
Оптимизирована условная загрузка шрифтов в GRUB в зависимости от статуса lockdown.
Обновлены пользовательские утилиты:
MiniOS Installer - добавлена поддержка многоязычных конфигураций SYSLINUX, улучшена логика определения и установки загрузчиков, добавлены переводы на французский и португальский (Португалия);
MiniOS Tools - улучшено автоматическое определение типа загрузчика в "sb2iso", добавлена поддержка bash-автодополнения для "dir2sb", "rmsbdir", "savechanges" и "sb2dir";
MiniOS Kernel Manager - расширена поддержка многоязычности;
Flux Tools - добавлена поддержка переводов через gettext, интегрированы Session Manager и Kernel Manager.
Улучшена совместимость встроенных утилит со старыми версиями bash (понижено требование до версии 4.4).
Эрик Рэймонд (Eric S. Raymond), один из основателей организации OSI (Open Source Initiative), стоявший у истоков движения открытого ПО, высказался по поводу кодексов поведения:
Я собираюсь сделать то, чего, по-моему, никогда раньше не делал, а именно: использовать весь свой авторитет как человека, который открыл и записал правила открытого исходного кода.
После десяти лет драмы и идиотизма многие люди, помимо меня, теперь готовы публично заявить, что «кодексы поведения» оказались катастрофой — своего рода заразным социальным безумием, порождающим драму, политические интриги, сплетни и отрицательную полезную работу.
Вот мой совет по поводу кодексов поведения:
Откажитесь от него. Если у вашего проекта есть такой кодекс, удалите его. Единственная реальная функция, которую он выполняет, — это инструмент в руках тех, кто любит подливать масла в огонь.
Если вы вынуждены иметь такой кодекс по бюрократическим причинам, замените его следующим предложением или чем-то подобным: «Если вы доставляете больше хлопот, чем оправдывают ваши вклады, вы будете отстранены».
Попытки делать кодексы более конкретными и подробными не работают. Они только дают провокаторам возможность манипулировать.
Да, мы должны стараться быть добрыми друг к другу. Но мы должны быть безжалостными и беспощадными по отношению к людям, которые пытаются превратить «Давайте быть добрее!» в оружие. Потакание им никогда не заканчивается хорошо.
Проект F-Droid, развивающий каталог открытых приложений для Android, заявил, что не сможет существовать в прежнем виде в случае введения обязательной регистрации в Google разработчиков и приложений. Представители F-Droid призвали сообщество, надзорные структуры и антимонопольные органы не допустить введения ограничений на установку Android-программ, и тем самым поддержать существование альтернативных каталогов приложений и защитить разработчиков, которые не могут или не хотят предоставлять Google свои персональные данные. Кроме того, вводимые ограничения нарушают ключевой элемент свободы пользователей - возможность устанавливать на своих устройствах любые программы на своё усмотрение.
В конце августа компания Google анонсировала переход на использование на сертифицированных Android-устройствах только зарегистрированных приложений от верифицированных разработчиков. Установка приложений из сторонних каталогов будет возможна только, если разработчики зарегистрируют свои пакеты в Google и подтвердят свои персональные данные.
Отличием F-Droid от коммерческих каталогов приложений является то, что он работает в интересах пользователей, а не в интересах распространителей приложений. F‑Droid выполняет проверку, что размещаемое приложение является полностью открытым и не содержит недокументированных антифункций, таких как показ рекламы или отслеживание установок.
Введение регистрации Android-приложений не позволит F-Droid продолжить свою работу так как каталог сам собирает пакеты из исходного кода и не может регистрировать их от имени разработчиков. Собирая пакеты самостоятельно, F-Droid выступает гарантом, что пакет собран из кода, предложенного в официальном репозитории. Исключение предоставляется лишь для проектов, поддерживающих воспроизводимую сборку - в этом случае F-Droid может разместить предоставляемый разработчиками пакет, проверив воспроизводимость его сборки.
В случае самостоятельной сборки пакет заверяется цифровой подписью F-Droid, а при поставке воспроизводимого пакета - подписью разработчика приложения. После введения обязательной регистрации поставка программ, упаковываемых силами F-Droid, станет невозможной - F-Droid не может регистрировать сторонние приложения от своего имени, так как это обозначало бы захват идентификаторов и присвоение исключительных прав на распространение чужих программ. Для пакетов, поддерживающих воспроизводимые сборки, поставка через F-Droid может быть продолжена, если разработчик зарегистрирует себя и приложение в Google. При этом F‑Droid не может обязать разработчиков производить подобную регистрацию.
Компания Google оправдывает введение ограничений желанием усложнить распространение вредоносных приложений с использованием мошеннических схем, предлагающих загрузить и установить apk-пакет в обход каталога Google Play Store. Подобное решение не является панацеей и регулярное выявление в Google Play вредоносного ПО показывает, что корпоративная проверка не гарантирует защиту пользователей. Кроме того, на всех сертифицированных Android‑устройствах с каталогом Google Play уже поставляется сервис Play Protect, который проверяет и блокирует вредоносные приложения, независимо от того, как они были установлены. По мнению представителей F‑Droid, регистрация разработчиков в Google мотивирована не заботой о безопасности, а желанием консолидировать власть и ужесточить контроль над экосистемой.
F‑Droid продвигает модель безопасности, основанную на обеспечении прозрачности процессов - каждое размещаемое приложение поставляется с открытым исходным кодом, аудит которого может быть проведён любым желающим; сборочные логи и процессы публично доступны; воспроизводимые сборки гарантируют, что публикуемые результаты полностью соответствуют исходному коду. Подобная модель формирует более прочную основу для доверия, чем закрытые платформы, предоставляя при этом свободу выбора для пользователя.
Команда модераторов, отвечавшая за поддержание порядка в форумах и репозиториях проекта NixOS, объявила о снятии с себя полномочий в знак протеста против действий управляющего комитета (SC - Steering Committee), вмешивающегося в работу модераторов и пытающегося влиять на принимаемые решения. Действия комитета рассматриваются модераторами как превышение полномочий и, так как правила проекта не регламентируют подобные ситуации, команда модераторов решила, что в сложившихся условиях не может добросовестно выполнять свою работу.
Разногласия возникли из-за того, что управляющий комитет и сложившийся состав модераторов придерживаются разных взглядов на управление сообществом. Комитет болезненно относится к критике и не приветствует обсуждение назревших в сообществе фундаментальных конфликтов. Модераторы же считают, что подобные обсуждения необходимы для роста проекта и нужно не избегать острых тем и не подавлять их, а поддерживать ход дискуссий в здоровом и конструктивном русле, без перехода на личности.
Среди примеров недопустимых действий управляющего комитета упоминаются попытки отменить некоторые решения модераторов, оказание давления на модераторов для совершения действий против отдельных участников и тем обсуждений, требование отчётности и обоснований действий от модераторов, попытки назначения и удаления модераторов без голосования (комитет пояснял свои действия попыткой добиться разнообразия мнений и исключения предвзятости в команде модераторов).
Протестующие модераторы призвали управляющий комитет подать в отставку, не дожидаясь выборов, которые должны пройти с 15 октября по 1 ноября, и уступить свои места новым членам, выбранным сообществом в ходе голосования. Сообществу рекомендовано добиваться прозрачности и подотчётности в работе управляющего совета, а также введения механизмов сдержек и противовесов для недопущения превышения полномочий.
Дополнение: Роберт Хенсинг (Robert Hensing) из управляющего комитета пояснил, что комитет пытался сотрудничать с командой модераторов для понимания модераторских решений, чтобы направить поведение модераторов в объективное русло, а также сделать модерацию справедливой. Основное недовольство модераторами было связано с тем, что модерация проводилась не на основе кодекса поведения, а на личных мнениях и компромиссах. Более решительные меры были предприняты так как модераторы не хотели отчитываться перед управляющим комитетом, которому они напрямую подчинены в иерархии проекта.
