| · | 04.06 | Атака на реализации HTTP/2, приводящая к исчерпанию доступной памяти (48 +7) |
|
Раскрыта информация об уязвимости "HTTP/2 Bomb", затрагивающей различные реализации протокола HTTP/2 и позволяющей добиться отказа в обслуживании через исчерпание всей доступной процессу памяти. Наличие проблемы подтверждено в HTTP-серверах nginx, Apache httpd (CVE-2026-49975), Microsoft IIS, Envoy (CVE-2026-47774) и Cloudflare Pingora в конфигурации по умолчанию.
Уязвимость использует метод, напоминающий zip-бомбу, применяемую к функциональности сжатия заголовков в HTTP/2. Идея в том, что запрос может содержать тысячи сжатых заголовков, таких как "Cookie", без прикреплённых данных, каждый из которых в запросе представлен однобайтовой ссылкой в индексе HPACK, но на сервере требует полноценного выделения памяти под весь заголовок. Уровень расходования памяти в различных HTTP-серверах варьируется от примерно 70 байт на каждый байт в индексе для nginx, IIS и Pingora, до 4000 байт в Apache httpd и 5700 в Envoy. При атаке с потребительского компьютера, имеющего канал связи 100Mbps, для исчерпания 32 ГБ памяти требуется примерно 10 секунд при атаке на сервер с Envoy 1.37.2, 18 секунд - Apache httpd 2.4.67 и 45 секунд - nginx 1.29.7. Для блокирования уязвимости в выпуске nginx 1.29.8 из проекта freenginx была перенесена директива max_headers, по умолчанию допускающая обработку не более 1000 заголовков. В Envoy исправление включено в состав выпусков 1.35.11 и 1.36.7, в которых реализованы лимиты mutable_max_request_headers_kb и max_headers_count. В Apache httpd исправление предложено в выпуске модуля mod_http2 2.0.41, который ещё не вошёл в релизы Apache httpd. Для Microsoft IIS и Cloudflare Pingora исправления пока отсутствуют. В качестве обходного пути защиты можно отключить использование протокола HTTP/2 и выставить ограничение на размер памяти, доступный для рабочих процессов. Дополнение: HTTP-сервер Angie не подвержен уязвимости, поскольку перенес защиту от этой атаки из freenginx ещё в версии 1.8.0, вышедшей в 2024 году.
| ||
|
Обсуждение (48 +7) |
Тип: Проблемы безопасности |
| ||
| · | 04.06 | Уязвимость в libinput, позволяющая повысить свои привилегии в системе (41 +10) |
|
В библиотеке libinput, предоставляющей унифицированный стек ввода для Wayland и X.Org Server, выявлена уязвимость (CVE не назначен), позволяющая добиться выполнения кода с правами root через подключение локальным пользователем виртуального устройства ввода, сэмулированного в пользовательском пространстве через uinput или uhid. Проблема устранена в выпусках 1.31.3 и 1.30.4.
Уязвимость присутствует в udev-обработчике libinput-device-group и вызвана отсутствием должного экранирования спецсимволов в атрибутах, получаемых от устройств и передаваемых в подсистему udev в форме "ключ=значение". Через подстановку символа перевода строки ("\n") в атрибут, можно добиться добавления своего правила udev, например, через выполнение uinput-команды UI_SET_PHYS("poc\n<SECOND_KEY>=<value>"). Для выполнения произвольных команд с правами root достаточно подобным способом подставить udev-правило со свойством "REMOVE_CMD", запускающем указанную команду после отключения устройства. Для эксплуатации уязвимости атакующий должен иметь доступ к устройству /dev/uinput или /dev/uhid. Обычно доступ к uinput и uhid имеет только пользователь root, но в некоторых дистрибутивах поставляются udev-правила, позволяющие непривилегированным пользователям использовать uinput. Например, в Fedora подобные правила выставляются при установке пакетов steam-devices, antimicrox и kdeconnectd. Доступен прототип эксплоита.
| ||
|
Обсуждение (41 +10) |
Тип: Проблемы безопасности |
| ||
| · | 04.06 | Выпуск фильтрующего прокси Privoxy 4.2.0 (9 +8) |
|
Опубликован релиз прокси-сервера Privoxy 4.2.0, предназначенного для создания персональных фильтров web-контента. При помощи Privoxy можно вырезать рекламные вставки, отбрасывать отслеживающие Cookie, удалять всплывающие диалоги, блокировать загрузку стороннего JavaScript-кода и вносить необходимые пользователю произвольные изменения в web-страницы. Privoxy поддерживает установку как на локальные системы отдельных пользователей, так и на серверы для создания централизованной инфраструктуры фильтрации контента в локальной сети. Код проекта написан на языке Си и распространяется под лицензией GPLv2+. Готовые сборки подготовлены для Linux (deb) и Windows.
Из расширенных возможностей Privoxy можно отметить: возможность привязки тегов для изменения поведения фильтров в зависимости от отдельных клиентских и серверных HTTP-заголовков; режим инспектирования HTTPS, позволяющий фильтровать HTTPS-запросы и ответы; использование регулярных выражений в файлах конфигурации; возможность замены анимированных gif-ов на урезанные статические картинки. Privoxy может использоваться для блокирования рекламы и нежелательного контента на устройствах, на которых невозможно установить соответствующие браузерные дополнения. Среди изменений в новом выпуске:
| ||
|
Обсуждение (9 +8) |
Тип: Программы |
| ||
| · | 04.06 | Fedora Linux помог выявить проблему с безопасностью в почтовом клиенте Outlook (25 +14) |
|
Администраторы почтовых серверов на базе Fedora Linux обратили внимание на возникновение проблем с работой почтового клиента Microsoft Outlook после обновления дистрибутива. Диагностика проблемы показала, что в новой версии пакета с IMAP/POP3-сервером Dovecot 2.4.3 в настройках по умолчанию была запрещена аутентификация по протоколам IMAP и POP3 с передачей пароля в открытом виде в сеансах без применения шифрования.
У пользователей Outlook была включена опция для обращения к почтовому серверу с использованием шифрования, но почтовый клиент при её выставлении продолжал использовать сетевой порт 110 для POP3, вместо смены номера порта на 995, применяемого для TLS-сеанса к серверу POP3, и не использовал расширение STARTTLS для переключения на TLS-сеанс. Некоторые старые конфигурации Outlook без вывода предупреждения игнорировали флаг включения TLS-шифрования в случае явного указания порта 110 и сразу отправляли команды USER и PASS открытым текстом. Наиболее старый выпуск Microsoft Outlook в котором замечено проявление проблемы датирован 2007 годом.
| ||
|
Обсуждение (25 +14) |
Тип: К сведению |
| ||
| · | 03.06 | Регрессии в rsync 3.4.3 и принятие изменений, подготовленных с использованием AI (147 +15) |
|
После выхода обновления утилиты для синхронизации файлов rsync 3.4.3 с исправлением 6 уязвимостей отмечено появление регрессий, нарушающих работоспособность ранее используемых конфигураций. Помимо этого непонимание и недовольство вызвало добавление за последние две недели в репозитории rsync около 50 изменений, подготовленных с использованием AI-модели Claude. Некоторые пользователи связали появление регрессий с генерацией низкокачественных исправлений уязвимостей при помощи AI.
Некоторые из регрессий в rsync 3.4.3:
Эндрю Триджелл (Andrew Tridgell), основатель проектов samba и rsync, два года назад вернувшийся к сопровождению rsync и добавивший проблемные коммиты, опубликовал заметку с пояснением сложившейся ситуации. По словам Эндрю, проект rsync столкнулся с лавиной отчётов об уязвимостях, многие из которых были сгенерированы через AI. В релизе rsync 3.4.3 появление регрессий стало ценой устранения уязвимостей. Эндрю сознательно предпочёл исправить уязвимости, несмотря на то, что исправления могли нарушить работу некоторых редких, но корректных сценариев использования rsync. Подобные сценарии не покрывались старым тестовым набором и ручными проверками, поэтому регрессии остались не замеченными и будут устранены в следующим выпуске 3.4.4. Возникшая ситуация побудила Эндрю модернизировать тестовый набор, ввести проверку покрытия кода и реализовать тестирование в системе непрерывной интеграции на разных платформах, а также выполнить анализ потенциальных уязвимостей. Так как Эндрю уже почти 60 лет и он предпочёл бы путешествовать на яхте, а не тратить своё время на устранение уязвимостей в rsync, он решил привлечь AI-ассистенты для выполнения рутинных задач в условиях свалившейся лавины сообщений об уязвимостях. Эндрю разработал архитектуру, план проверки и структуру нового тестового набора, после чего при помощи AI сгенерировал его на Python и заменил им ранее применявшийся тестовый shell-скрипт. При разработке использовалась модель Claude с ручной проверкой результата и перекрёстной проверкой в Codex и Gemini.
| ||
|
Обсуждение (147 +15) |
Тип: Тема для размышления |
| ||
| · | 03.06 | Microsoft представил Coreutils для Windows, эмулятор терминала Intelligent Terminal и контейнеры в WSL (197 –12) |
|
Компания Microsoft представила порт набора утилит Coreutils для платформы Windows. В состав входит несколько десятков утилит, включая sort, cat, chmod, chown, cp, find, sleep, sort, tee, echo, uptime и ls. Инструментарий позволяет напрямую использовать в Windows типовые утилиты, доступные в Linux и macOS, без использования прослойки WSL. Целью проекта заявлено упрощение перехода между Unix-подобными системами, WSL, контейнерами и Windows, и предоставление единого набора команд, флагов и методов, позволяющих переносить существующие скрипты из других систем без переписывания. Код написан на Rust и PowerShell, и распространяется под лицензией MIT.
Реализация основана на коде проекта uutils (Rust Coreutils), развивающего вариант GNU Coreutils на языке Rust, а также реализациях утилит find и grep на Rust. Утилиты собраны в виде одного универсального исполняемого файла "C:\Program Files\coreutils\coreutils.exe", отдельные команды к которому привязаны при помощи жёстких ссылок в NTFS. Из-за конфликта с имеющимися штатными утилитами Windows или привязки к специфичным возможностям из поставки исключены утилиты dd, dir, dircolors, shred, sync, uname, expand, kill, more, paste, timeout и whoami. Из состава также исключены утилиты, завязанные на не поддерживаемые в Windows концепции POSIX: chcon, chgrp, chmod, chown, chroot, groups, hostid, id, install, logname, mkfifo, mknod, nice, nohup, pathchk, pinky, runcon, stdbuf, stty, tty, users, who. Из ограничений и особенностей отмечается необходимость использовать NUL вместо /dev/null, отсутствие поддержки сигналов (SIGHUP, SIGPIPE, SIGUSR), возможность создания символических ссылок только после включения режима для разработчика, недоступность некоторых операций с правами доступа. При работе с каталогами принимаются как пути с символом "/", так и c "\". Одновременно представлен первый выпуск эмулятора терминала Intelligent Terminal, представляющего собой форк Windows Terminal с интегрированным AI-агентом. Поддерживается подключение AI-агентов, поддерживающих протокол ACP (Agent Client Protocol), таких как gitHub Copilot, Claude, Codex и Gemini. Код терминала написан на языках C++ и Rust, и открыт под лицензией MIT. По функциональности терминал близок к Windows Terminal и также поддерживает вкладки, темы оформления, профили, комбинации клавиши разделение экрана на отдельные области. Из отличий выделяется отдельная статусная строка с состоянием AI-агента и возможностью быстрого обращения к нему, а также привязанная к контексту закрепляемая панель для взаимодействия с AI-агентом. Имеется возможность просмотра истории действий AI-агентов и переключения между разными AI-агентами. Упоминается возможность отправки в Microsoft телеметрии с информацией об использовании программы.   Дополнительно анонсирован проект по созданию системы для запуска Linux-контейнеров в Windows, реализованной на базе прослойки WSL (Windows Subsystem for Linux). Инструментарий предоставляет типовой интерфейс командной строки wslc и API для создания, развёртывания и запуска контейнеров на базе Linux из окружения Windows, а также для обращения к запущенным контейнерам из Windows. Первую ознакомительную версию WSL-контейнеров намерены опубликовать в ближайшие месяцы в составе одного из обновлений WSL. Так как WSL является открытым проектом, отслеживать разработку можно уже сейчас на GitHub.
| ||
|
Обсуждение (197 –12) |
Тип: К сведению |
| ||
| · | 03.06 | Расширение системной памяти через подкачку в видеопамяти NVIDIA (100 +40) |
|
Опубликован инструментарий nbd-vram, позволяющий разместить область подкачки в видеопамяти графической карты NVIDIA. Подобный манёвр даёт возможность виртуально увеличить размер памяти в системе, работающей на ноутбуках с впаянной нерасширяемой оперативной памятью и GPU NVIDIA. Код написан на языке Си и распространяется под лицензией MIT.
Например, на ноутбуке с 16 ГБ ОЗУ и видеокартой NVIDIA GeForce RTX 3070 с 8 ГБ VRAM через раздел подкачки можно задействовать дополнительные 7 ГБ памяти. В сочетании с применением модуля ядра zram для сжатого хранения раздела подкачки и подключением дополнительного раздела подкачки на SSD-накопителе общий размер адресуемой памяти в тестовой конфигурации доведён до 46 ГБ (при нехватке ОЗУ начинает использоваться видеопамять, затем привлекается сжатие при помощи zram и на последнем этапе задействуется подкачка на SSD). Производительность работы с видеопамятью при последовательном чтении оценивается примерно в 1.3 GB/s и задержками ниже NVMe из-за обращения к GPU по шине PCIe. Реализация основана на применении фонового процесса nbd-vram, который выделяет VRAM через API драйвера CUDA и предоставляет системе доступ к полученной видеопамяти в форме блочного устройства на базе протокола NBD (Network Block Device). В ядре Linux используется встроенный драйвер nbd без загрузки собственных специализированных модулей. После создания блочного устройства /dev/nbdX, связанного с выделенной видеопамятью, на нём штатными утилитами создаётся раздел подкачки. Для автоматизации запуска конфигурации с nbd-vram подготовлен инсталлятор и сервис systemd "vram-swap-nbd.service". Настройка сводится к заданию размера выделяемой видеопамяти и приоритета подкачки через переменные VRAM_SETUP_SIZE_MB и VRAM_SWAP_PRIORITY. Имеется опция для активации подкачки в видеопамяти только при подключении ноутбука к стационарному источнику питания, позволяющая экономить энергию в автономном режиме. Для работы nbd-vram требуется NVIDIA GPU c поддержкой CUDA (например, серии GeForce RTX и GTX), драйвер NVIDIA с библиотекой libcuda.so.1 (установка CUDA Toolkit не требуется), ядро Linux новее 3.0 и пакет nbd-client.
| ||
|
Обсуждение (100 +40) |
Тип: К сведению |
| ||
| · | 03.06 | Выпуск дистрибутива Ubuntu Sway Remix 26.04 LTS (42 +1) |
|
Доступен выпуск дистрибутива Ubuntu Sway Remix 26.04 LTS, предоставляющего преднастроенный и готовый к использованию рабочий стол на основе мозаичного композитного менеджера Sway. Дистрибутив является неофициальной редакцией Ubuntu 26.04, созданной с оглядкой как на опытных пользователей GNU/Linux, так и новичков, желающих попробовать окружение мозаичных оконных менеджеров без необходимости в их долгой настройке. Для загрузки подготовлены сборки для архитектур amd64, arm64 и компьютеров Raspberry Pi.
Окружение дистрибутива построено на основе Sway - композитного менеджера, использующего протокол Wayland и полностью совместимого с мозаичным оконным менеджером i3, а также панели Waybar, файлового менеджера Thunar, и утилит из проекта NWG-Shell, таких как менеджер обоев рабочего стола Azote, полноэкранного меню приложений nwg-drawer, утилиты для вывода содержимого скриптов на экран nwg-wrapper (используется для отображения подсказки по горячим клавишам на рабочем столе), менеджера настройки тем GTK, курсора и шрифтов nwg-look и скрипта Autotiling, автоматически компонующего окна открытых приложений на манер динамических мозаичных оконных менеджеров. В состав дистрибутива входят программы как с графическим интерфейсом, такие как Firefox, Qutebrowser, Audacious, Transmission, Libreoffice, Pluma и MATE Calc, так и консольные приложения и утилиты, такие как музыкальный проигрыватель Musikcube, видеопроигрыватель MPV, утилита для просмотра изображений Swayimg, утилита для просмотра документов PDF Zathura, текстовый редактор Neovim, файловый менеджер Ranger и другие. Другой особенностью дистрибутива является полный отказ от использования пакетного менеджера Snap, все программы поставляются в виде обычных deb-пакетов, в том числе веб-браузер Firefox, для установки которого задействован официальный PPA-репозиторий Mozilla Team. Установщик дистрибутива основан на фреймворке Calamares.  Основные изменения:
| ||
| · | 02.06 | Первый выпуск редактора Vim Classic, продолжающего развитие ветки Vim 8.2 (71 +9) |
|
Дрю ДеВолт (Drew DeVault), автор пользовательского окружения Sway, почтового клиента Aerc, языка программирования Hare и платформы совместной разработки SourceHut, опубликовал первый выпуск Vim Classic, форка текстового редактора Vim 8.2, продолжающего сопровождение прошлой ветки. В качестве причин создания форка указано непринятие политики Vim в отношении использования AI. По задумке Дрю ДеВолта, Vim Classic 8.3 можно рассматривать как то, как мог бы выглядеть выпуск Vim 8.3, если бы разработчики Vim не создали ветку Vim 9 с новым скриптовым языком Vim9 Script, имеющим синтаксис, близкий к JavaScript, TypeScript и Java. От Vim 8.2 выпуск Vim Classic 8.3 отличается исправлением ошибок и портированием некоторых возможностей из новых веток Vim.
| ||
|
Обсуждение (71 +9) |
Тип: Программы |
| ||
| · | 02.06 | Доступна библиотека устранения шума на изображениях Open Image Denoise 2.5 (51 +12) |
|
Компания Intel опубликовала выпуск проекта oidn 2.5 (Open Image Denoise), развивающего коллекцию фильтров для устранения шумов на изображениях, подготовленных с использованием систем рендеринга на основе трассировки лучей. Open Image Denoise развивается как часть более крупного проекта oneAPI Rendering Toolkit, нацеленного на разработку средств программной визуализации научных расчётов (SDVis (Software Defined Visualization), включающих библиотеку трассировки лучей Embree, систему фотореалистичной отрисовки GLuRay, платформу распределённой трассировки лучей OSPRay и систему программной растеризации OpenSWR. Код написан на языке С++ и опубликован под лицензией Apache 2.0.
Целью проекта является предоставление высококачественных, эффективных и простых в использовании функций шумоподавления, которые можно применять для повышения качества результатов трассировки лучей. Предложенные фильтры позволяют на основании результата сокращённого цикла трассировки лучей получить итоговый уровень качества, сопоставимый с результатом более затратного и длительного процесса детализированного рендеринга. Open Image Denoise обеспечивает отсеивание случайного шума, возникающего, например, при трассировке лучей на основе численного интегрирования по методу Монте-Карло (MCRT). Для достижения высокого качества рендеринга в подобных алгоритмах требуется проведение трассировки очень большого числа лучей, иначе на результирующем изображении появляются заметные артефакты в виде случайного шума. Применение Open Image Denoise позволяет на несколько порядков сократить количество необходимых вычислений при расчёте каждого пикселя. В итоге, можно значительно быстрее сгенерировать изначально зашумлённое изображение, но затем довести его до приемлемого качества при помощи быстрых алгоритмов подавления шумов. При наличии соответствующего оборудования предложенный инструментарий можно применять даже для интерактивной трассировки лучей c устранением шумов на лету. Библиотека может применяться на различных классах устройств, от ноутбуков и ПК, до узлов в кластерах. Реализация оптимизирована для различных классов 64-разрядных CPU Intel с поддержкой инструкций SSE4, AVX2, AVX-512 и XMX (Xe Matrix Extensions), чипов Apple Silicon и систем с GPU Intel Xe (серии Arc, Flex и Max), NVIDIA (на базе архитектур Turing, Ampere, Ada Lovelace, Hopper и Blackwell) и AMD (на базе архитектур RDNA2 (Navi 21), RDNA3 (Navi 3x), RDNA 3.5 и RDNA4). В качестве минимального требования заявлена поддержка SSE4.1.   Основные изменения в выпуске Open Image Denoise 2.5:
| ||
|
Обсуждение (51 +12) |
Тип: Программы |
| ||
| · | 02.06 | Проблемы с соблюдением авторского права при переписывании ScanCode на Rust при помощи AI (166 +24) |
|
Сопровождающий открытый инструментарий ScanCode Toolkit, предназначенный для сканирования кода на предмет пересечений с чужими авторскими правами, выявления используемых лицензий и обнаружения неисправленных уязвимостей, раскритиковал проект, создавший при помощи AI клон продукта ScanCode, переписанный с Python на Rust (название клона не упоминается, но, судя по всем признакам, речь про проект Provenant). Утверждается, что в переписанном проекте нарушена торговая марка ScanCode и удалены упоминания об авторских правах и лицензиях. Претензии объясняются тем, что в переписанном клоне продолжено использование ключевых алгоритмов ScanCode, сохранена архитектура проекта и структура кода.
По мнению сопровождающего ScanCode успешному созданию клона способствовало наличие у проекта исчерпывающего автоматизированного тестового набора, включающего более 90 тысяч тестов, из которых 40 тысяч посвящены обнаружению использования тех или иных лицензий в коде. Авторы переписанной версии заявили о существенном повышении производительности (в 10-100 раз), но, по словам сопровождающего ScanCode, ценой ускорения стало неполное прохождение тестового набора, а также снижение корректности работы и полноты предоставляемой информации (клон выдавал некорректные результаты и находил не всю информацию при анализе). Если в специальных тестах производительности Rust-порт существенно опережал ScanCode, то при прохождении стандартного тестового набора клон оказался медленнее, несмотря на то, что в нём пропускались некоторые проверки. После внесения в ScanCode оптимизаций, таких как кэширование, производительность ScanCode при сканировании кода стала не хуже, чем в клоне на Rust, при полном сохранении корректности работы. Авторам клона также вменяется нарушение авторских прав и лицензии Apache 2.0, под которой распространяется код ScanCode. Отмечается, что в процессе переписывания были нарушены 4 основных требования лицензии: оставление оригинального файла с примечанием (NOTICE), сохранение упоминаний об авторских правах, выделение совершённых изменений и смена имени в производной работе. После замечания авторы клона разместили файл NOTICE и переименовали свой проект, но два нарушения пока остаются неустранёнными. Сопровождающий ScanCode считает, что сообщество должно выработать критерии для разделения того, что при использовании AI считать производной работой, а что независимой реализацией. По его мнению, после переписывания кода на другом языке с сохранением алгоритмов и структуры результат продолжает оставаться производной работой, даже если в процессе были переименованы переменные и переделаны или удалены комментарии. Заявления авторов Rust-порта о независимой переработке, лишь вдохновлённой проектом ScanCode, в этом случае некорректно, так как работа нацелена на создание видимости оригинальной разработки, что даже хуже чем прямое копирование, так как подобные манипуляции сложнее обнаружить. Значительной проблемой при генерации кода через AI называется отсутствие отслеживания происхождения кода, который был использован для получения результата. По умолчанию AI-агенты, использующие код из открытых проектов, игнорируют информацию об авторах, если специально не реализованы средства выявления и сохранения метаданных о лицензиях и авторстве. Проблема атрибуции затрагивает не только работу по переписыванию кода с одного языка на другой, но и генерацию кода в общем виде - результат в этом случае может достаточно точно повторять шаблоны из существующего открытого кода, используемого в процессе обучения модели.
| ||
|
Обсуждение (166 +24) |
Тип: К сведению |
| ||
| · | 02.06 | Canonical опубликовал утилиту workshop для развёртывания окружений для разработки (34 –2) |
|
Компания Canonical представила инструментарий workshop, позволяющий одной командной быстро создавать в Ubuntu изолированные окружения для применения при разработке ПО и решения задач, связанных с машинным обучением и вовлечением AI-агентов. Начинка окружения определяется в одном файле конфигурации в формате YAML, который позволяет точно воспроизвести описанное окружение на любых компьютерах. Предполагается, что благодаря workshop разработчик может сосредоточиться на том, что он хочет получить, не тратя своё время на разбор зависимостей и настройку начинки. Инструментарий устанавливается в виде snap-пакета. Код проекта написан на языке Go и распространяется под лицензией GPLv3.
Окружение формируется из независимых подключаемых элементов, оформляемых в виде SDK, которыми можно делиться с другими пользователями через каталог SDK Store. Комбинируя свои и уже существующие SDK разработчик может задействовать в окружении желаемые языки программирования, библиотеки и инструменты. Например, предоставляются SDK для использования Ollama, OpenCode, NVIDIA CUDA и AMD ROCm. Для низкоуровневого управления окружениями в workshop задействован инструментарий управления контейнерами LXD 6.8.  
| ||
|
Обсуждение (34 –2) |
Тип: Программы |
| ||
| · | 02.06 | Обновление X.Org Server 21.1.23 с устранением 9 уязвимостей (101 +24) |
|
Опубликованы корректирующие выпуски X.Org Server 21.1.23 и DDX-компонента (Device-Dependent X) xwayland 24.1.12, обеспечивающего запуск X.Org Server для организации выполнения X11-приложений в окружениях на базе Wayland. В новых версиях устранены 9 уязвимостей. Некоторые уязвимости потенциально могут быть эксплуатированы для повышения привилегий в системах, в которых X-сервер выполняется с правами root, а также для удалённого выполнения кода в конфигурациях, в которых для доступа используется перенаправление сеанса X11 при помощи SSH.
Исправленные уязвимости (CVE-идентификаторы не назначены):
| ||
|
Обсуждение (101 +24) |
Тип: Программы |
| ||
| · | 01.06 | Атакующие встроили вредоносное ПО в 32 NPM-пакета Red Hat (85 +23) |
|
В результате компрометации процесса формирования релизов на базе GitHub Actions в принадлежащих компании Red Hat репозиториях RedHatInsights, злоумышленники смогли опубликовать в каталоге NPM 64 вредоносные версии, охватывающие 32 NPM-пакета для платформы Red Hat Cloud Services. Для каждого из поражённых NPM-пакетов были выпущены по две вредоносные версии, в которые был интегрирован код для активации нового варианта червя mini-shai-hulud, выполняющего поиск токенов и учётных данных в текущем окружении.
Червь размещался в файле index.js и активировался через preinstall-обработчик, вызываемый при установке поражённого пакета. После активации червь выполнял поиск в системе токенов к NPM (~/.npmrc), PyPI, CircleCI, AWS, GCP, Docker, Azure, HashiCorp и KubernetesK8s, а также закрытых ключей SSH. Найденные данные отправлялись злоумышленникам. В случае обнаружения токена для подключения к каталогу NPM червь автоматически публиковал новые вредоносные релизы для разрабатываемых в текущем окружении пакетов, поражая дерево зависимостей. Доступ к GitHub Actions был получен в результате компрометации учётной записи одного из сотрудников Red Hat, что позволило атакующим напрямую отправить коммиты в репозитории javascript-clients, frontend-components и platform-frontend-ai-toolkit, без прохождения стадии рецензирования. Через коммиты в систему непрерывной интеграции подставлялся файл ci.yaml, который при запуске сборочной работы запускал при помощи платформы bun скрипт _index.js. Скрипт использовал полномочие "id-token: write" для запроса у GitHub токена OIDC (OpenID Connect), который затем применялся для аутентификации в NPM при помощи механизма "trusted publishing". NPM-пакеты, содержащие вредоносный код:
| ||
|
Обсуждение (85 +23) |
Тип: Проблемы безопасности |
| ||
| · | 01.06 | Разработаны правила использования AI в проекте Rust (74 +15) |
|
Разработчики языка программирования Rust готовят к публикации правила применения AI-ассистентов в проекте. Предложенные правила отточены в ходе обсуждения, насчитывающего более 3000 сообщений, одобрены 4 сопровождающими и ожидают публикации. За отдельными исключениями, правила запрещают передачу кода, сгенерированного через AI, в основной репозиторий rust-lang/rust, но не распространяются на субмодули, подветки и зависимости из каталога crates.io, а также другие репозитории организации. При этом правила разрешают использование AI для анализа, изучения, рецензирования и проверки кода.
Применение AI допускается в случаях, когда полученная через AI информация в частном порядке используется только одним разработчиком и не распространяется публично. Например, когда разработчик задаёт AI вопросы по коду, формирует для себя сводку по комментариям к PR или issue, привлекает AI для рецензирования изменений, создаёт через AI инструменты для личного использования, консультируется через AI о возможных вариантах выбора решения. Также допускается создание через AI экспериментальных изменений, не подлежащих рецензированию другими участниками. Запрещено применение AI для формирования комментариев, отчётов о проблемах и описаний изменений, публикуемых от имени участника. При этом разрешено цитирование выдачи от AI с явной пометкой, что контент сформирован через AI (например, прикрепление результатов диагностики через AI). Запрещено создание документации через AI. При рецензировании запрещено рассмотрение выводов AI как достаточных для приёма или отклонения изменений - результаты проверки через AI могут носить только рекомендательный характер. С оговорками и явным упоминанием, что результат получен через AI, разрешено применение AI для машинного перевода на другие языки, поиска и верификации ошибок, а также внесения незначительных изменений в код и тексты (например, правка опечаток и подбор синонимов). В рамках эксперимента допускается передача заранее согласованных, некритичных, досконально проверенных и хорошо протестированных изменений, изначально сгенерированных через AI. Перед отправкой pull-запроса c подобным изменением, разработчик должен заранее договориться с рецензирующими. Предлагаемые изменения должны помечаться меткой "ai-assisted" и могут затрагивать вторичные инструменты, такие как tidy и linkchecker, но не должны касаться ключевых возможностей и элементов языка. Для отслеживания результатов эксперимента изменения предписано отправлять в отдельный приватный Zulip-канал, доступ к которому предоставлен только участникам проекта.
| ||
|
Обсуждение (74 +15) |
Тип: К сведению |
| ||
| Следующая страница (раньше) >> | ||
