| · | 06.12 | Кандидаты в релизы Wine 11 и Wine-staging 11 (48 +7) |
|
Началось тестирование первого кандидата в релизы Wine 11.0, открытой реализации WinAPI. Кодовая база переведена на стадию заморозки перед релизом, который ожидается во второй половине января. По сравнению с выпуском Wine 10.20 закрыто 17 отчётов об ошибках и внесено 175 изменений.
Наиболее важные изменения:
Кроме того, сформирован выпуск проекта Wine Staging 11.0-rc1, предоставляющего расширенные сборки Wine, включающие не полностью готовые или рискованные патчи, пока непригодные для принятия в основную ветку Wine. По сравнению с Wine в Wine Staging предоставляется 253 дополнительных патча. В новом выпуске Wine Staging осуществлена синхронизация с кодовой базой Wine 11.0-rc1 и перенесены свежие изменения из vkd3d.
| ||
|
Обсуждение (48 +7) |
Тип: Программы |
| ||
| · | 06.12 | Сбой в Cloudflare из-за проблемы в коде на языке Lua (125 +13) |
Спустя две недели с момента прошлого глобального сбоя сеть доставки контента Cloudflare, обслуживающая около 20% всего мирового web-трафика, вчера частично оказалась недоступной на 25 минут. Во время инцидента примерно треть запросов через Cloudflare завершалось возвращением пустой страницы с кодом ошибки 500. На этот раз, причиной стала остававшаяся много лет незамеченной проблема в коде на языке Lua, применяемом в системе фильтрации трафика WAF (Web Application Firewall) для блокирования вредоносных запросов.
 Чтобы защитить системы клиентов от критической уязвимости (CVE-2025-55182) в серверных компонентах фреймворка React, после появления в публичном доступе эксплоита, инженеры Cloudflare реализовали защиту на уровне WAF. С внедрением защиты не всё пошло гладко: в процессе внедрения был увеличен размер буфера для проверки трафика на прокси-серверах, но оказалось, что применяемый для тестирования WAF инструментарий не поддерживает выставленный размер буфера. Так как данный инструментарий не влияет на трафик, было решено отключить его. Для отключения инженеры воспользовались подсистемой "killswitch" для быстрого изменения конфигурации и отключения отдельных Lua-обработчиков на прокси-серверах без замены правил. Подобный метод отключения правил периодически применяется для быстрого устранения ошибок и приводит к пропуску выполнения части Lua-кода. При этом инженеры не учли, что для вызова отключаемого тестового инструментария в Lua-правилах применялся метод "execute", запускающий дополнительный набор правил. Ранее режим "killswitch" никогда не применялся с правилами, имеющими вызов "execute", и данная комбинация не тестировалась. Применение "killswitch" привело к тому, что код с определением дополнительного тестового набора правил был отключён, но вызов этого набора правил через "execute" остался. В коде не было дополнительных проверок существования объекта и подразумевалось, что при наличии в наборе правил действия "execute", объект "rule_result.execute" обязательно существует. В итоге, произошла попытка выполнения метода "execute" для неинициализированного объекта, которая привела к аварийному завершению обработчика с ошибкой "attempt to index field 'execute' (a nil value)".
if rule_result.action == "execute" then
rule_result.execute.results = ruleset_results[tonumber(rule_result.execute.results_index)]
end
| ||
|
Обсуждение (125 +13) |
Тип: Обобщение |
| ||
| · | 05.12 | Выпуск пакетного фильтра nftables 1.1.6 (20 +6) |
|
Опубликован выпуск пакетного фильтра nftables 1.1.6, унифицирующего интерфейсы фильтрации пакетов для IPv4, IPv6, ARP и сетевых мостов (нацелен на замену iptables, ip6table, arptables и ebtables). Одновременно опубликован выпуск сопутствующей библиотеки libnftnl 1.3.1, предоставляющей низкоуровневый API для взаимодействия с подсистемой nf_tables.
В пакет nftables входят компоненты пакетного фильтра, работающие в пространстве пользователя, в то время как на уровне ядра работу обеспечивает подсистема nf_tables, входящая в состав ядра Linux начиная с выпуска 3.13. На уровне ядра предоставляется лишь общий интерфейс, не зависящий от конкретного протокола и предоставляющий базовые функции извлечения данных из пакетов, выполнения операций с данными и управления потоком. Непосредственно правила фильтрации и специфичные для протоколов обработчики компилируются в байткод в пространстве пользователя, после чего данный байткод загружается в ядро при помощи интерфейса Netlink и выполняется в ядре в специальной виртуальной машине, напоминающей BPF (Berkeley Packet Filters). Подобный подход позволяет значительно сократить размер кода фильтрации, работающего на уровне ядра и вынести все функции разбора правил и логики работы с протоколами в пространство пользователя. Основные изменения:
| ||
|
Обсуждение (20 +6) |
Тип: Программы |
| ||
| · | 05.12 | В GNOME добавлена поддержка управления восстановлением сеанса (81 +2) |
В кодовую базу, на основе которой формируется релиз GNOME 50, принят набор изменений с реализацией настройки для управления восстановлением приложений, запущенных в прошлом сеансе. В конфигуратор добавлен переключатель, позволяющий отключить режим сохранения списка запущенных приложений во время завершения сеанса и восстановления их окон в последующем сеансе.
 В мае из менеджера сеансов gnome-session был удалён старый код для сохранения сеанса, который был несовместим с компонентами управления сеансом на базе systemd. Старая реализация обеспечивала сохранение списка активных приложений перед завершением сеанса в каталоге ~/.config/gnome-session/saved-session и управлялась через gconf-параметр "auto-save-session", но не работала на системах с systemd. В конце сентября для GNOME была предложена новая система сохранения сеансов, основанная на использовании systemd. Кроме того был добавлен объект GsmSessionSave, обеспечивающий сохранение состояния отдельных приложений. Помимо сохранения позиций окон после восстановления приложения GNOME также могут включать логику для восстановления состояния, например, GNOME Calculator может восстановить выбранный режим вычислений (базовый, расширенный, для программистов), но не восстанавливает историю операций.
| ||
|
Обсуждение (81 +2) |
Тип: К сведению |
| ||
| · | 05.12 | Выпуск дистрибутива Oracle Linux 10.1 (9 +5) |
|
Компания Oracle опубликовала дистрибутив Oracle Linux 10.1, созданный на основе пакетной базы Red Hat Enterprise Linux 10.1 и полностью бинарно совместимый с ней. Для загрузки без ограничений предложены установочные iso-образы, размером 10 ГБ и 1.3 ГБ, подготовленные для архитектур x86_64 и ARM64 (aarch64). Для Oracle Linux 10 открыт неограниченный и бесплатный доступ к yum-репозиторию с бинарными обновлениями пакетов с устранением ошибок (errata) и проблем безопасности. Для загрузки также подготовлены отдельно поддерживаемые репозитории с наборами пакетов Application Stream и CodeReady Builder.
Помимо пакета с ядром из состава RHEL (на базе ядра 6.12) в Oracle Linux предложено собственное ядро Unbreakable Enterprise Kernel 8.1 (UEK 8U1), также основанное на ядре Linux 6.12 и оптимизированное для работы с промышленным программным обеспечением и оборудованием Oracle. В обновлении ядра UEK 8U1 по умолчанию включена опция SECURITY_DMESG_RESTRICT, разрешающая доступа к dmesg только при наличии прав root. Драйверы megaraid_sas, mpi3mr и mpt3sas бэкпортированы из ядра 6.15. Исходные тексты ядра, включая разбивку на отдельные патчи, доступны в публичном Git-репозитории Oracle. Ядро Unbreakable Enterprise Kernel устанавливается по умолчанию, позиционируется в качестве альтернативы штатному пакету с ядром RHEL и предоставляет ряд расширенных возможностей, таких как интеграция DTrace и улучшенная поддержка Btrfs. Кроме дополнительного ядра по функциональности выпуски Oracle Linux 10.1 и RHEL 10.1 полностью идентичны (список изменений можно посмотреть в анонсе RHEL 10.1).
| ||
|
Обсуждение (9 +5) |
Тип: Программы |
| ||
| · | 05.12 | Представлен Proxmox Datacenter Manager 1.0 (33 +21) |
|
Компания Proxmox, известная разработкой продуктов Proxmox Virtual Environment, Proxmox Backup Server и Proxmox Mail Gateway, представила первый стабильный релиз нового дистрибутива - Proxmox Datacenter Manager, включающий интерфейс пользователя и инструментарий для централизованного управления несколькими независимыми кластерами на базе Proxmox Virtual Environment. Серверный бэкенд, утилиты командной строки и новый web-интерфейс написаны на языке Rust и распространяются под лицензией AGPLv3. Для создания web-интерфейса использован собственный набор виджетов, основанный на web-фреймворке Yew. Размер установочного iso-образа 1.5 ГБ.
Proxmox Datacenter Manager позволяет через один web-интерфейс инспектировать все подключённые узлы и кластеры, управлять сложными и распределёнными инфраструктурами с масштабированием от отдельных локальных установок до управления территориально разделёнными датацентрами. Среди прочего возможно централизованное выполнение таких действий, как live-миграция виртуальных машин между разными кластерами. Бэкенд и интерфейс оптимизированы для управления большим числом узлов, например, в тестовом внедрении показана возможность управления более 5 тысячами хостов и 10 тысячами виртуальных машин. Основные возможности:
| ||
|
Обсуждение (33 +21) |
Тип: Программы |
| ||
| · | 05.12 | Релиз http-сервера Apache 2.4.66 с устранением 5 уязвимостей (11 +13) |
|
Представлен релиз HTTP-сервера Apache 2.4.66, в котором устранено 5 уязвимостей и внесено несколько десятков изменений.
Устранённые уязвимости (первые 2 имеют умеренный уровень опасности, а остальные низкий):
Среди не связанных с безопасностью улучшений:
| ||
|
Обсуждение (11 +13) |
Тип: Программы |
| ||
| · | 05.12 | Выпуск операционной системы Solaris 11.4 SRU87 (8 +5) |
|
Компания Oracle опубликовала выпуск операционной системы Solaris 11.4 SRU 87 (Support Repository Update), в котором предложена серия значительных изменений и улучшений для ветки Solaris 11.4. Для установки предложенных в обновлении исправлений достаточно выполнить команду 'pkg update'. Пользователи также могут воспользоваться бесплатной редакцией Solaris 11.4 CBE (Common Build Environment), развиваемой с использованием модели непрерывной публикации новых версий.
Среди изменений в новой версии:
| ||
|
Обсуждение (8 +5) |
Тип: Программы |
| ||
| · | 04.12 | Анализ конфиденциальных данных, захваченных червём Shai-Hulud 2 (49 +18) |
|
Компания Wiz опубликовала результаты анализа следов деятельности червя Shai-Hulud 2, в ходе активности которого в репозитории NPM были опубликованы вредоносные выпуски более 800 пакетов, насчитывающих в сумме более 100 млн загрузок. После установки поражённого пакета, активизировавшийся червь выполняет поиск конфиденциальных данных, публикует новые вредоносные релизы (при обнаружении токена подключения к каталогу NPM) и размещает в открытом доступе найденные в системе конфиденциальные данные через создание новых репозиториев в GitHub.
В GitHub выявлено более 30 тысяч репозиториев с сохранёнными червём перехваченными данными. В около 70% из этих репозиториев размещён файл content.json, в 50% - файл truffleSecrets.json, а в 80% - environment.json, содержащие ключи доступа, конфиденциальные данные и переменные окружения, найденные на системе разработчика, установившего вредоносный пакет с червём. Также в данных репозиториях выявлено около 400 файлов actionsSecrets.json с ключами, найденными в окружениях для выполнения GitHub Actions. В файлах contents.json присутствовало более 500 уникальных учётных данных и токенов для подключения к GitHub. В файлах truffleSecrets.json содержались конфиденциальные данные, найденные в результате выполнения на поражённой системе утилиты TruffleHog, собирающей более 800 типов данных, среди которых ключи доступа, ключи шифрования, пароли и токены, используемые в различных сервисах, облачных окружениях, продуктах и СУБД. Всего в truffleSecrets.json выявлено более 400 тысяч уникальных записей из которых около 2.5% (~10000) было верифицировано. Предполагается, что попавшая в открытый доступ конфиденциальная информация может стать отправной точкой для новой волны атак, так как многие данные остаются актуальны. Например, проверка показала, что 60% токенов доступа к NPM, захваченных с поражённых червём систем, остаются действующими. В отчёте также приводится общая статистика, полученная на основе анализа переменных окружения с поражённых систем. 23% запусков червя произошли на компьютерах разработчиков, а 77% - в окружениях систем непрерывной интеграции (60% GitHub Actions, 5% - Jenkins, 5% - GitLab CI, 3% - AWS CodeBuild). На 87% систем использовался Linux, 12% - macOS и 1% - Windows. 76% запусков было в контейнерах, 13% - в основных системах. 60% всех инфицированний произошло из-за установки вредоносных релизов пакетов @postman/tunnel-agent-0.6.7 и @asyncapi/specs-6.8.3. В 99% проценте случаев червь был активирован при запуске команды "node setup_bun.js", указанной в package.json в секции preinstall (оставшиеся 1% вероятно приходятся на попытки тестирования). 
| ||
|
Обсуждение (49 +18) |
Тип: Проблемы безопасности |
| ||
| · | 04.12 | Выпуск geoip 0.1.0, реализации REST API для определения местоположения по IP (32 +3) |
|
Состоялся первый релиз проекта geoip, реализующего сервис для получения информации о местоположении IP-адресов через REST API. Проект ориентирован на упрощение интеграции GeoIP-функциональности в различные приложения, освобождая разработчика от необходимости самостоятельно управлять обновлениями баз данных и работать с форматом MMDB. Код написан на языке Rust и распространяется под лицензией MIT. Поддерживается работа в Linux и macOS, а также других UNIX-подобных системах.
Основные возможности сервиса:
| ||
| · | 04.12 | Релиз дистрибутива Alpine Linux 3.23 и пакетного менеджера apk 3.0 (47 +11) |
Доступен релиз Alpine Linux 3.23, минималистичного дистрибутива, построенного на базе системной библиотеки Musl и набора утилит BusyBox. Дистрибутив отличается повышенными требованиями к обеспечению безопасности и собран с защитой SSP (Stack Smashing Protection). В качестве системы инициализации используется OpenRC, для управления пакетами применяется собственный пакетный менеджер apk. Alpine применяется для формирования официальных образов контейнеров Docker и используется в проекте PostmarketOS. Загрузочные iso-образы (x86_64, x86, armhf, aarch64, armv7, ppc64le, s390x, riscv64 и loongarch64) подготовлены в шести вариантах: стандартном (344 МБ), загружаемом по сети (361 МБ), расширенном (1 ГБ), для виртуальных машин (67 MB), minirootfs (4 MB) и для гипервизора Xen (1 ГБ).
| ||
|
Обсуждение (47 +11) |
Тип: Программы |
| ||
| · | 04.12 | MinIO прекратил развитие открытой кодовой базы в пользу проприетарного продукта (24 –6) |
|
Разработчики проекта MinIO, развивающего совместимое с API Amazon S3 высокопроизводительное объектное хранилище, объявили о переводе репозитория в режим сопровождения. Отныне в открытую кодовую базу будут включаться только исправления критических уязвимостей, а изменения, связанные с новой функциональностью и исправлением ошибок, будут оставаться в закрытом репозитории, на основе которого разрабатывается коммерческая версия. Пользователям, которым необходима поддержка или активно сопровождаемая версия, рекомендовано перейти на проприетарный продукт MinIO AIStor.
Ранее разработчики MinIO высказывали недовольство использованием их разработок в сторонних проприетарных продуктах без выполнения условий лицензии AGPL и без указания авторства (например, одна из компаний пыталась продавать полный клон MinIO, рекламируя его как более производительный, чем MinIO). Текущая кодовая база остаётся под лицензией AGPL 3.0 и при желании заинтересованные участники могут создать форк и развивать его своими силами. Из существующих открытых альтернатив можно отметить AIStore, Garage, Ambry, SeaweedFS, RustFS, hs5 и Versity S3 Gateway.
| ||
|
Обсуждение (24 –6) |
Тип: К сведению |
| ||
| · | 04.12 | Уязвимость в серверных компонентах React, позволяющая выполнить код на сервере (58 +12) ↻ |
|
В серверных компонентах web-фреймворка React (RSC, React Server Components) устранена уязвимость (CVE-2025-55182), позволявшая через отправку запроса к серверному обработчику выполнить произвольный код на сервере. Проблеме присвоен критический уровень опасности (10 из 10). Уязвимость проявляется в экспериментальных компонентах react-server-dom-webpack,
react-server-dom-parcel и
react-server-dom-turbopack, применяемых для выполнения функций и формирования элементов интерфейса на сервере, а не на стороне клиента.
Проблема вызвана небезопасной десериализацией данных, полученных в HTTP-запросах к серверным обработчикам. Исправление свелось к замене в функции requireModule выражения "return moduleExports[metadata[NAME]];", не исключавшего подстановку прототипа, на вариант с проверкой через hasOwnProperty:
if (hasOwnProperty.call(moduleExports, metadata[NAME])) {
return moduleExports[metadata[NAME]];
}
return (undefined: any);
Подверженность систем уязвимости зависит от применения на них уязвимых серверных компонентов react-server-dom-webpack, react-server-dom-parcel и react-server-dom-turbopack (среди прочего, web-приложение может не использовать их, но установить на сервере). Приложения, не использующие react-server, уязвимость не затрагивает. Степень охвата уязвимостью рабочих систем, в которых используется React, пока не ясна. С одной стороны, React является одним из самых популярных web-фреймворков (используется примерно на 6% web-сайтов), а уязвимые компоненты развиваются в основном репозитории и входят в состав релизов. Уязвимые компоненты также поддерживаются в основанных на React фреймворках, таких как Next.js и react-router. По данным компании Wiz Research уязвимые экземпляры Next.js или React выявлены в 39% проанализированных облачных окружений. С другой стороны, генерация контента на сервере через React Server Components не часто используемая функция (большинство React-сайтов отрисовывают интерфейс только на стороне клиента), а уязвимые компоненты помечены как экспериментальные и не гарантирующие корректную работу. Данные компоненты имеют относительно небольшое число прямых загрузок из репозитория NPM: react-server-dom-webpack - 670 тысяч в неделю, react-server-dom-parcel - 7 тысяч и react-server-dom-turbopack - 32 тысячи, для сравнения NPM-пакет React имеет 45 млн загрузок в неделю. Уязвимость присутствует версиях React 19.0.0, 19.1.0, 19.1.1 и 19.2.0, и устранена в обновлениях React 19.0.1, 19.1.2 и 19.2.1. Уязвимые компоненты также применяются в пакетах react-router (20 млн загрузок в неделю), waku, @parcel/rsc (Parcel RSC plugin), @vitejs/plugin-rsc (Vite RSC plugin) и rwsdk (RedwoodSDK). В React Router проблема проявляется только при использовании экпериментального режима RSC. Аналогичная уязвимость (CVE-2025-66478) выявлена в реализации протокола RSC (React Server Components) во фреймворке Next.js (16 млн загрузок в неделю). Проблема затрагивает приложения, использующие App Router и ветки Next.js 15.x и 16.x. Утверждается, что уязвимость проявляется в конфигурации Next.js по умолчанию (стандартное приложение, создаваемое утилитой create-next-app, подвержено атаке). Пользователям рекомендовано как можно скорее установить обновление Next.js 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 или 16.0.7. Дополнение 1: Пример эксплоита оказался не действующим. Общий принцип эксплуатации и метод атаки через прототипы объектов подтверждены, но привязка к модулям vm, child_process и fs ошибочна (в пока не опубликованном реальном эксплоите задействовано какое-то не привязанное к внешним модулям внутреннее свойство). Дополнение 2: Исследователь, изначально выявивший уязвимость, опубликовал рабочие прототипы эксплоитов. Также доступно несколько сторонних вариантов эксплоитов (1, 2, 3), созданных путём изучения патча. Суть атаки в использовании десериализации $@ для получения ссылки на Chunk и помещения Chunk.prototype.then в качестве свойства "then" корневого объекта. Пример запроса для запуска xcalc:
Content-Disposition: form-data; name="0"
"then":"$1:__proto__:then","status":"resolved_model","reason":-1,"value":"{\"then\":\"$B1337\"}","_response":{"_prefix":"process.mainModule.require('child_process').execSync('xcalc');","_formData":{"get":"$1:constructor:constructor"}}}
Content-Disposition: form-data; name="1"
"$@0"
| ||
|
Обсуждение (58 +12) ↻ |
Тип: Проблемы безопасности |
Интересно
| ||
| · | 03.12 | Консорциум OASIS утвердил OpenDocument (ODF) 1.4 в качестве стандарта (97 +36) |
|
Международный консорциум OASIS, занимающийся разработкой и продвижением открытых стандартов, утвердил финальный вариант спецификации OpenDocument 1.4 (ODF) в качестве стандарта OASIS. Следующим этапом станет продвижение OpenDocument 1.4 в роли международного стандарта ISO/IEC. Формат OpenDocument 1.4 поддерживается в LibreOffice начиная с выпуска LibreOffice 25.2.
ODF представляет собой основанный на XML, независимый от приложений и платформ файловый формат для хранения документов, содержащих текст, электронные таблицы, диаграммы и графические элементы. Спецификации также включают требования к организации чтения, записи и обработки подобных документов в приложениях. Стандарт ODF применим для создания, редактирования, просмотра, обмена и архивирования документов, которые могут представлять собой текстовые документы, презентации, электронные таблицы, растровые графические материалы, векторные рисунки, схемы и другие типы контента. Наиболее заметные изменения в OpenDocument 1.4:
Спецификация состоит из четырёх частей:
Дополнительно можно отметить начало альфа-тестирования офисного пакета LibreOffice 26.2, релиз которого запланирован на февраль 2026 года. Из наиболее заметных новшеств: поддержка импорта и экспорта в формате Markdown, возможность использования горизонтальных вкладок в интерфейсе, расширение возможностей отслеживания изменений в документах, поддержка формата Biff12 для переноса данных через буфер обмена из Excel, расширение диалога сортировки в Calc, поддержка маппинга документов XML и JSON с таблицами в Calc, ускорение отрисовки фигур.
| ||
|
Обсуждение (97 +36) |
Тип: К сведению |
| ||
| · | 03.12 | Ядро Linux 6.18 отнесено к категории выпусков с длительным сроком поддержки (39 +19) |
|
Ядру Linux 6.18 присвоен статус ветки с длительным сроком поддержки. Обновления для ветки 6.18 будут выпускаться как минимум до декабря 2027 года, но не исключено, что, как и в случае с прошлыми LTS-ветками, время сопровождения будет продлено до шести лет. Для обычных выпусков ядра обновления выпускаются только до выхода следующей стабильной ветки (например, обновления для ветки 6.17 выпускались до выхода 6.18).
Одновременно объявлено о завершении цикла сопровождения ветки ядра Linux 5.4, для которой опубликован финальный выпуск 5.4.302 (больше в серии 5.4.x обновления публиковаться не будут). Ветка 5.4 была сформирована в ноябре 2019 года, сопровождалась 6 лет и использовалась в Ubuntu 20.04 LTS и в Oracle Unbreakable Enterprise Kernel 6. Продукты, поставляемые с ядром 5.4, рекомендуется перевести на более актуальные LTS-выпуски. Продолжается сопровождение longterm-веток:
Отдельно на базе ядер 4.4, 4.19, 5.10, 6.1 и 6.12 организацией Linux Foundation предоставляются ветки SLTS (Super Long Term Support), которые сопровождаются отдельно и поддерживаются 10-20 лет. Сопровождение SLTS-веток осуществляется в рамках проекта Civil Infrastructure Platform (CIP), в котором участвуют такие компании, как Toshiba, Siemens, Renesas, Bosch, Hitachi и MOXA, а также вовлечены мэйнтейнеры LTS-веток основного ядра, разработчики Debian и создатели проекта KernelCI. Ядра SLTS ориентированы на применение в технических системах гражданской инфраструктуры и в важных промышленных системах.
| ||
|
Обсуждение (39 +19) |
Тип: Программы |
| ||
| Следующая страница (раньше) >> | ||
