| · | 07.02.2026 | Инициатива по встраиванию моделей машинного обучения в ядро Linux (148 –27) |
|
Вячеслав Дубейко из компании IBM запустил в списке рассылки разработчиков ядра Linux обсуждение использования в ядре моделей машинного обучения, а также предложил для тестирования набор патчей с библиотекой для интеграции ML-моделей в ядро и примером символьного драйвера, использующего библиотеку.
Интеграция ML-моделей в ядро может быть полезной для изменения логики работы подсистем с учётом обрабатываемых данных, оптимизации работы и изменения конфигурации в зависимости от внутреннего состояния систем. Применение машинного обучения, способного выявлять закономерности и строить прогнозы без ручной реализации алгоритмов, упростит подбор наиболее эффективной конфигурации ядра c учётом сложности и изменчивости современных рабочих нагрузок, а также позволит решать такие проблемы, как предсказание сбоев систем хранения. Помимо движка для выполнения моделей рассматривается разработка инструментов сбора данных для обучения ML-моделей, непосредственно обучения модели и тестирования результата. Так как для выполнения ML-модели требуются операции с плавающей запятой, а в ядре не допускается прямое использование FPU, предложенный прототип представляет собой прослойку для обращения из различных подсистем ядра к ML-моделям, выполняемым в пользовательском пространстве, по аналогии с выносом в пользовательское пространство обработчиков SPDK, DPDK и ublk. Вынос выполнения и обучения модели в пространство пользователя упрощает сопровождение и изолирует ядро от проблем в коде выполнения модели. На стадии обучения данные о состоянии и параметрах ядра могут как запрашиваться обработчиком из пользовательского пространства, так и передаваться прослойкой, выполняемой на уровне ядра. Для управления взаимодействия компонентами в ядре и пользовательском пространстве применяется sysfs. Возможно адаптивное обучение ML-модели, при котором подсистема ядра получает рекомендацию от ML-модели, применяет рекомендуемое изменение и оценивает эффективность рекомендации по изменению состояния.
| ||
|
Обсуждение (148 –27) |
Тип: К сведению |
| ||
| · | 07.02.2026 | Anthropic опубликовал Си-компилятор, созданный AI-моделью Claude Opus и способный собрать ядро Linux (298 –13) |
|
В качестве демонстрации возможности автономно создавать крупные проекты при помощи новой AI-модели Claude Opus 4.6, компания Anthropic сгенерировала компилятор для языка Си - claudes-c-compiler, пригодный для сборки ядра Linux, PostgreSQL, SQLite, Redis, FFmpeg, GNU coreutils, Busybox, CPython, QEMU, LuaJIT и ещё около 150 протестированных известных открытых проектов. Результирующие сборки успешно прошли предоставляемые проектами тестовые наборы. Собранное ядро Linux успешно загружается и даёт возможность запустить игру Doom. Код компилятора сгенерирован на языке Rust и опубликован как общественное достояние (CC0). Поддерживается компиляция проектов для архитектур x86_64, i686, AArch64 и RISC-V 64.
Весь код и документация к компилятору сгенерированы моделью Claude Opus 4.6. Участие человека свелось к определению тестовых сценариев, которым должен удовлетворять итоговый продукт. Интерактивный режим для разработки, отладки и контроля над качеством не применялся, Модель Claude Opus сама выполнила всю работу на основе поставленной задачи. Ручное рецензирование корректности работы компилятора не проводилось, поэтому он не рекомендован для использования помимо экспериментов. Степень прохождения тестовых наборов компиляторов, включая GCC Torture Tests, составляет 99%. Для разработки компилятора было привлечено 16 AI-агентов, которые после двух недель работы и около двух тысяч сеансов в Claude Code сгенерировали 100 тысяч строк кода на Rust, выполняющих задачу сборки ядра Linux 6.9 для архитектур x86, ARM и RISC-V. При генерации кода использовался новый режим работы "agent teams", позволяющий организовать параллельную работу нескольких AI-агентов Claude над одной общей кодовой базой, осуществляемую автономно без вмешательства человека. По стоимости доступа к API создание компилятора оценено в 20 тысяч долларов (передано 2 миллиарда входных токенов и сгенерировано 140 миллионов выходных токенов). Компилятор самодостаточен и не требует внешних зависимостей, кроме стандартной библиотеки Rust. Все компоненты созданы с нуля, включая фронтэнд, промежуточное представление (IR) на базе SSA, оптимизатор, генератор кода, ассемблер, компоновщик и генератор отладочной информации в формате DWARF. Фронтэнд совместим на уровне опций с GCC и может использоваться в качестве прозрачной замены GCC. На выходе генерируются исполняемые файлы в формате ELF. Поддерживается только платформа Linux (задача поддержки macOS и Windows не ставилась). Из ограничений отмечается отсутствие раздельных уровней оптимизации (уровни с -O0 по -O3, -Os и -Oz приводят к одинаковой оптимизации), имеются проблемы с использованием _Atomic и _Complex, частично поддерживается ключевое слово __attribute__ и частично реализовано использование инструкций NEON. Помимо ограничений, описанных в подготовленной AI документации к компилятору, в статье с анонсом проекта упоминаются некоторые дополнительные проблемы:
| ||
|
Обсуждение (298 –13) |
Интересно
| ||
| · | 06.02.2026 | Выпуск свободного звукового редактора Ardour 9.0 (35 +19) |
|
Опубликован релиз свободного звукового редактора Ardour 9.0, предназначенного для многоканальной записи, обработки и микширования звука. В Ardour предоставляется мультитрековая шкала времени, неограниченный уровень отката изменений на всем протяжении работы с файлом (даже после закрытия программы), поддержка разнообразных аппаратных интерфейсов. Программа позиционируется как свободный аналог профессиональных средств ProTools, Nuendo, Pyramix и Sequoia. Код распространяется под лицензией GPLv2. В ближайшее время неофициальные сборки для Linux будут сформированы в формате Flatpak.
Ключевые изменения:
| ||
|
Обсуждение (35 +19) |
Тип: Программы |
| ||
| · | 06.02.2026 | Защита от мусорных AI-изменений на GitHub. Оценка влияния вайб-кодинга на экосистему открытого ПО (174 +27) |
|
Камилла Мораес (Camilla Moraes), менеджер по продукту из компании GitHub, начала обсуждение добавления в GitHub возможности для автоматической блокировки мусорных pull-запросов, сгенерированных в AI-ассистентах, отправленных без ручной проверки и не соответствующих требованиям качества. Подобные изменения создают дополнительную нагрузку на сопровождающих, которые вынуждены тратить время на разбор бесполезного кода.
В качестве краткосрочных путей решения проблемы рассматривается возможность быстрого удаления pull-запросов через web-интерфейс (удаления без оседания в истории вместо пометки закрытыми) и использование настраиваемых прав на отправку pull-запросов, позволяющих владельцам репозиториев разрешать передачу изменений только участникам, ранее вносившим изменения. Из решений в долгосрочной перспективе упоминается расширение модели полномочий и предоставление сопровождающим инструментов для гибкого задания правил, определяющих кто имеет право создавать и рецензировать pull-запросы и каким требованиям должны соответствовать pull-запросы. Кроме того, предлагается задействовать AI для определения соответствия отправленного изменения правилам и стандартам качества каждого проекта (например, заданным в файле CONTRIBUTING.md), а также выявления и специальной пометки изменений, подготовленных при помощи AI. Из высказанных в процессе обсуждения предложений также можно отметить создание фильтра, запрещающего отправку pull-запросов без предварительного открытия issue-обсуждений с пояснением причин реализации изменений, а также информирование сопровождающих о поступлении pull-запросов от новичков только после успешного прохождения тестов в системе непрерывной интеграции. По статистике одного из ключевых разработчиков фреймворка genkit лишь одно из десяти изменений, подготовленных в AI, соответствует критериям для открытия pull-запроса. Один из участников проекта Azure Core Upstream подытожил основные опасения сопровождающих:
Дополнительно можно отметить проведённое несколькими европейскими университетами исследование влияния вайб-кодинга на экосистему открытых проектов. Исследователи разработали модель равновесия экосистемы открытого кода, которая показала, что обратные связи, ранее отвечавшие за взрывной рост открытых проектов, после распространения вайб-кодинга создают обратный эффект - уменьшается число разработчиков готовых делиться кодом, сокращается разнообразие открытых проектов и снижается качество. Одним из вариантов решения проблемы упоминается внедрение модели финансирования, напоминающей Spotify, при которой AI‑платформы перераспределяют доходы от подписок на сервисы для разработчиков среди сопровождающих, в зависимости от степени использования проектов. При вайб-кодинге разработчики перестают анализировать доступные решения, читать документацию, отправлять сообщения об ошибках и взаимодействовать с командами, развивающими открытые библиотеки. Открытые проекты теряют обратную связь с пользователям. Новым проектам становится сложнее пробиться, так как AI-ассистенты сами подбирают необходимые открытые библиотеки на основе информации, имевшейся на момент обучения модели. Из-за снижения прямого взаимодействия с пользователями страдает монетизация отрытых проектов, завязанных на услугах поддержки и показе рекламы/сборе пожертвований на сайтах. Из-за снижения обратной связи страдает качество. С другой стороны, вайб-кодинг повышает производительность труда при создании новых продуктов, основанных на чуждом коде, и упрощает внедрение новых библиотек. Как пример приведён проект Tailwind CSS, число загрузок которого из репозитория NPM продолжает расти, но трафик к документации с начала 2023 года снизился на 40%, а доходы упали на 80%. Также отмечено снижение активности обсуждений на Stack Overflow примерно на 25%, спустя 6 месяцев после запуска ChatGPT. ![]() ![]()
| ||
|
Обсуждение (174 +27) |
Тип: К сведению |
| ||
| · | 06.02.2026 | Девятый экспериментальный выпуск среды рабочего стола Orbitiny (85 +12) |
|
Опубликован девятый выпуск среды рабочего стола Orbitiny Desktop, написанной с нуля с использованием фреймворка Qt. Проект пытается совместить некоторые инновационные идеи, которые раньше не встречались в пользовательских окружениях, с традиционными элементами, такими как панель с поддержкой плагинов, меню приложений и рабочий стол, на котором можно размещать ярлыки. Работа пока сосредоточена на запуск в окружениях на базе X-сервера, но в будущем не исключается добавление поддержки Wayland. Код написан на языке C++ и распространяется под лицензией GPL.
Из специфичных для Orbitiny возможностей отмечается: вызов действий через экранные жесты (очерчивание мышью определённого контура на пустой области рабочего стола); метки на пиктограммах (показываются для новых, изменённых, пустых или перемещённых через буфер обмена файлов, а также пустых каталогов); возможность вставки файла одновременно в несколько выбранных каталогов; поддержка размещения содержимого рабочего стола в любом каталоге (не только в $HOME/Desktop); использование отдельных десктоп-каталогов для каждого виртуального рабочего стола и монитора. Список типовых возможностей Orbitiny можно посмотреть в прошлом анонсе. ![]() Среди изменений:
| ||
|
Обсуждение (85 +12) |
Тип: Программы |
| ||
| · | 05.02.2026 | Microsoft развивает открытую систему sandbox-изоляции Litebox (77 +6) |
|
Джеймс Моррис (James Morris), мэйнтенер подсистемы обеспечения безопасности ядра Linux, возглавляющий в компании Microsoft команду "Linux Emerging Technologies", представил проект Litebox, позиционируемый как сфокусированная на безопасности операционная система в форме библиотеки (Library OS). Litebox может использоваться в программах или ядрах как дополнительный слой изоляции, блокирующий доступ к излишней функциональности ядер или API для снижения поверхности атак. Код проекта написан на языке Rust и открыт под лицензией MIT.
Идея "Library OS" в том, что сервисы операционной системы напрямую встраиваются в приложение вместо обращения к внешнему ядру ОС при помощи системных вызовов. В контексте Litebox к приложениям подключается изолирующая прослойка, предоставляющая минимальную платформу, транслирующую запросы к внешнему полнофункциональному программному интерфейсу. В качестве подобных внешних интерфейсов могут выступать ядро Linux, защищённые изолированные окружения OP-TEE (Open Portable Trusted Execution Environment), Webassembly-окружения или стандартная библиотека RustStd. ![]() Формируемая через Litebox минимальная платформа применима для запуска приложений Linux, Windows и FreeBSD, вложенных ядер Linux и LVBS (Linux Virtualization Based Security). В качестве возможных областей применения Litebox упоминается обеспечения запуска немодифицированных Linux-программ в Windows, изоляция выполнения Linux-приложений на системах с ядром Linux, запуск программ поверх AMD SEV SNP для шифрования памяти, выполнение OP-TEE-программ в Linux и изоляция с использованием концепции LVBS. Проект LVBS, представители которого участвуют в разработке Litebox, развивает методы для защиты компонентов ядра Linux, использующие возможности гипервизоров и аппаратной виртуализации. Например, при помощи гипервизора могут изолироваться операции контроля подлинности модулей, верификации, управления доступом к паролям, ключам, структурам ядра и другим критически важным ресурсам. В случае эксплуатации уязвимости и компрометации ядра, атакующий не сможет получит доступ к подобным ресурсам, так как их обработчики выполняются вне текущего уровня привилегий. Litebox рассматривается в контексте проекта LVBS как "безопасное ядро", защищающая обычное ядро гостевой системы при помощи аппаратной виртуализации.
| ||
|
Обсуждение (77 +6) |
Тип: К сведению |
| ||
| · | 05.02.2026 | JetBrains переводит IDE IntelliJ на использование Wayland по умолчанию (137 –1) |
|
Компания JetBrains объявила о решении включить по умолчанию поддержку работы с использованием протокола Wayland в интегрированных средах разработки на базе будущего выпуска IntelliJ 2026.1. До релиза протестировать поддержку Wayland можно воспользовавшись EAP-сборками IntelliJ IDEA (Early Access Program). IDE, основанные на IntelliJ, теперь смогут напрямую запускаться в средах рабочего стола на базе Wayland без использования XWayland. Поддержка бэкенда XToolkit для X11 будет оставлена в качестве опции.
Отмечается, что с момента прошлого тестирования прямой работы поверх Wayland в 2024 году, в реализации повышена стабильность работы поверх различных композитных серверов, добавлена функциональность drag-and-drop, обеспечена поддержка методов ввода и обеспечено естественно выглядящее декорирование окон. Из отличий поведения от сборки на базе X11 отмечается отсутствие центрирования или восстановления прошлого положения некоторых окон и диалогов, невозможность выноса некоторых всплывающих окон за пределы основного окна, отдельные несоответствия элементов декодирования окон (заголовок, кнопки управления оконном, тени, скругление углов) активной теме оформления рабочего стола. Разработанный для IntelliJ Wayland-бэкенд WLToolkit открыт под лицензией GPLv2 и включён в состав JetBrainsRuntime (редакция OpenJDK). Со временем подготовленный Wayland-бэкенд может быть перенесён в основной состав OpenJDK. JetBrains также участвует в разработке проекта Wakefield, развивающего компоненты для поддержки Wayland в OpenJDK, позволяющие напрямую запускать графические Java-приложения в окружениях на базе Wayland.
| ||
|
Обсуждение (137 –1) |
Тип: К сведению |
| ||
| · | 05.02.2026 | В VirtualBox добавлена предварительная поддержка работы поверх гипервизора KVM (102 +29) |
|
В репозиторий системы виртуализации VirtualBox добавлены изменения, позволяющие использовать встроенный в ядро Linux гипервизор KVM вместо специфичного модуля ядра VirtualBox (vboxdrv). Реализация подготовлена сотрудниками Oracle и развивается отдельно от набора патчей VirtualBox-KVM, поддерживаемого компанией Cyberus Technology. Отмечается, что Oracle начала работу над KVM-бэкендом несколько лет назад, но из-за нехватки инженерных ресурсов его разработка затянулась.
Начиная с коммита 5cb05ca, бэкэнд KVM находится в более или менее рабочем состоянии, по крайней мере для более "современных" гостевых систем. Старые и экзотические ОС, такие как MS-DOS, ещё не поддерживаются или не оттестированы. Если VirtualBox не может получить доступ к собственным драйверам ядра, он переключится на работу с использованием KVM, если он доступен. Сохранённые состояния между родным гипервизором и KVM должны быть совместимы. Тестовых сборок пока нет, и код доступен только в текущем GIT-срезе. Реализованный бэкенд решит проблемы с запуском VirtualBox в дистрибутивах с поддержкой UEFI Secure Boot, таких как Fedora и RHEL, которые отказываются подписывать сторонние драйверы. Поддержка KVM также позволит запускать VirtualBox в Linux-системах, ещё не поддерживаемых в драйвере vboxdrv, использовать VirtualBox одновременно с другими системами виртуализации на базе KVM и задействовать расширенные механизмы аппаратного ускорения виртуализации, поддерживаемые в KVM, но не применяемые в VirtualBox (например, расширение APICv для виртуализации контроллера прерываний).
| ||
| · | 04.02.2026 | Выпуск офисного пакета LibreOffice 26.2 (105 +29) |
|
Организация The Document Foundation опубликовала релиз офисного пакета LibreOffice 26.2. Готовые установочные пакеты подготовлены для различных дистрибутивов Linux, Windows и macOS. В версии 26.2 проект прекратил поставляться с меткой "Community" (LibreOffice Community) и
вернулся к поставке просто как LibreOffice.
Ранее метка "Community" добавлялась, чтобы подчеркнуть, что сборка поддерживается энтузиастами и не нацелена на применение на предприятиях. Несколько лет назад наименование LibreOffice Community было введено для более явного разделения с продуктами для предприятий семейства LibreOffice Enterprise, для которых партнёрскими компаниями предоставляется коммерческая поддержка, возможность получать обновления длительное время (LTS) и дополнительные функции, такие как SLA (Service Level Agreements). В конечном счёте решено убрать метку "Community", так как её наличие при загрузке сбивало с толку и вводило пользователей в замешательство - некоторые считали, что это только версия для некоммерческого применения, в то время как она была без ограничений доступна бесплатно всем без исключения, в том числе корпоративным пользователям. Наиболее заметные изменения:
| ||
|
Обсуждение (105 +29) |
Тип: Программы |
| ||
| · | 04.02.2026 | Грегу Кроа-Хартману присуждена премия за вклад в открытое ПО (79 +26) |
|
Европейская академия открытого ПО (EOSA, European Open Source Academy) присудила Грегу Кроа-Хартману (Greg Kroah-Hartman) премию "Excellence in Open Source 2026", вручаемую европейским сообществом за выдающийся вклад в разработку открытого ПО. Грег отвечает за поддержку стабильной и "staging" веток ядра Linux, занимает пост мэйнтейнера в 16 подсистемах ядра, среди которых USB, TTY и Driver core, а также является создателем openSUSE Tumbleweed, udev и инициативы по разработке драйверов для Linux (Linux driver project). Последние годы Грег проживает в Нидерландах.
Помимо главной премии учреждены 4 специальные награды (Special Recognitions), присуждённые 5 участникам:
Европейская академия открытого ПО создана при поддержке Европейской комиссии для популяризации и признания выдающихся людей и организаций, занимающихся развитием открытого программного и аппаратного обеспечения в Европе. Целью является продвижение преимуществ открытых проектов, налаживание сотрудничества и отстаивание общественной и экономической ценности открытых программных и аппаратных технологий. Организация находится на стадии преобразования в независимый некоммерческий фонд, зарегистрированный в Бельгии. Премию вручил Дэниел Cтенберг (Daniel Stenberg), президент Европейской академии открытого ПО, автор утилиты curl и участник рабочих групп IETF, развивающих протоколы HTTP и QUIC. Помимо Дэниела членами академии являются:
![]() ![]()
| ||
|
Обсуждение (79 +26) |
Тип: К сведению |
| ||
| · | 03.02.2026 | Выпуск системы управления исходными текстами Git 2.53 (100 +8) |
|
Представлен релиз распределенной системы управления исходными текстами Git 2.53. Git отличается высокой производительностью и предоставляет средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, а также удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. Код Git распространяется под лицензией GPLv2+.
По сравнению с прошлым выпуском в новую версию принято 466 изменений, подготовленных при участии 70 разработчиков (21 впервые приняли участие в разработке Git). Основные новшества:
В состав прошлого выпуска было добавлено предупреждение о включении по умолчанию сборки компонентов на языке Rust в Git 2.53. Тем не менее, фактически в версии Git 2.53 лишь добавлены отдельные улучшения поддержки Rust (возможность сборки без GNU sed), но сборка с Rust при использовании Makefile оставлена по умолчанию отключённой (требует выставления флага WITH_RUST), а при использовании Meson автоматически активируется при наличии компилятора rustc. В версии Git 3.0 инструментарий Rust намерены включить в число обязательных сборочных зависимостей.
| ||
|
Обсуждение (100 +8) |
Тип: Программы |
| ||
| · | 02.02.2026 | Проект Linux From Scratch прекращает поддержку SysVinit в пользу systemd (277 –35) |
|
Брюс Дуббс (Bruce Dubbs), главный редактор проекта Linux From Scratch, объявил о прекращении обновления версий руководств Linux From Scratch (LFS) и Beyond Linux From Scratch (BLFS) в конфигурации с системой инициализации SysVinit. Доступ к руководству LFS/BLFS 12.4 с SysVinit будет сохранён, но намеченный на 1 марта выпуск LFS/BLFS 13.0 будет сформирован только в варианте с системным менеджером systemd.
В Linux From Scratch приведены инструкции по созданию с нуля базовой Linux-системы, используя лишь исходные тексты необходимого программного обеспечения. Beyond Linux From Scratch дополняет инструкции LFS информацией о сборке и настройке прикладных программных пакетов, охватывающих различные области применения, от СУБД и серверных систем, до графических оболочек и медиапроигрывателей. В качестве причин отказа от развития руководств с SysVinit упоминается нехватка ресурсов и прекращение поддержки SysVinit крупными проектами, такими как GNOME и KDE Plasma. Проект поддерживается небольшой командой добровольцев, которая не справляется с обработкой потока изменений в 88 пакетах LFS и более 1000 пакетов в BLFS, в условиях необходимости проверки всех пакетов на работоспособность в окружениях на базе System V и systemd. Помимо этого последние версии GNOME и KDE Plasma требуют для работы функциональности systemd, которую можно было бы реализовать перейдя на OpenRC, но миграция не решит проблему с перегруженностью редакторов книги. Брюс также отметил, что это вынужденное решение, которым он не доволен. Systemd включает 1678 файлов на языке C, плюс множество файлов с данными, в то время как SysVinit содержит 22 файла на языке C и около 50 небольших bash-скриптов и файлов с данными. Несмотря на значительный перевес systemd в функциональности, по мнению Брюса, после прекращения поддержки SysVinit книга потеряет составляющие, важные для понимания того, как работает система.
| ||
|
Обсуждение (277 –35) |
Тип: К сведению |
| ||
| · | 02.02.2026 | Набор подсказок для рецензирования изменений в ядре Linux и systemd при помощи AI (68 +3) |
|
Крис Мейсон (Chris Mason), создатель и мэйнтейнер файловой системы Btrfs, опубликовал проект review-prompts, содержащий коллекцию скриптов и подсказок для настройки процесса рецензирования изменений в ядре Linux и системном менеджере systemd, используя AI-ассистенты, такие как Сlaude Code. В состав включены файлы для уточнения особенностей работы различных подсистем и протоколов, позволяющие AI-ассистенту лучше понимать контекст при рецензировании, отладке и проверке изменений.
Также предоставляются шаблоны и списки проверок для выявления и классификации типовых ошибок (примеры для dbus и сетевой подсистемы) и инструкции по формированию через AI автоматизированных отчётов. После рецензирования патчей на выходе формируется файл review-inline.txt, оформленный в виде заготовки email для отправки в список рассылки разработчиков ядра. Отмечается, что многие ложные срабатывания при анализе изменений через AI вызваны непониманием специфики кодовой базы и опубликованные подсказки нацелены на предоставление AI необходимой информации для принятия верных решений. В настоящее время уровень ложных срабатываний при использовании предложенного набора составляет примерно 10%.
| ||
|
Обсуждение (68 +3) |
Тип: К сведению |
| ||
| · | 02.02.2026 | Первый публичный релиз ANet, стека для создания защищённых туннелей (124 +40) |
|
Проект ANet (ANet Secure Transport Protocol) развивает альтернативный стек для организации защищённых туннелей, предназначенный для объединения частных сетей в условиях, когда стандартные решения (WireGuard, OpenVPN) в силу разных обстоятельств не применимы. Проект позиционируется не как очередной форк WireGuard, а как "Сеть Друзей" (Friends-to-Friends VPN) с упором на использование зарекомендовавших себя криптоалгоритмов и автономную работу в режиме "Dead Man's Hand". В ANet используется собственный транспортный протокол ASTP (ANet Secure Transport Protocol), обеспечивающий полное сквозное шифрование, устойчивый к высокой потере пакетов и неотличимый от случайного UDP-трафика. Код написан с нуля на языке Rust и распространяется под лицензией MIT, но с явным запретом на включение в проект зависимостей под GPL 2.0 и 3.0.
Основные особенности:
В отличии от WireGuard c узнаваемым handshake (Magic number + Noise Protocol) и OpenVPN с характерным TLS-отпечатком, в протоколе ASTP каждый пакет начинается со случайной затравки (nonce 12 байт), за которым идёт шифротекст переменной длины с добавочным заполнением до ближайшего размера блока (настраивается). Для внешнего наблюдателя трафик неотличим от случайного. ANet преподносится как попытка вернуть в VPN "физичность" эпохи флоппинет (HDD у друга), но в цифре: PSK (pre-shared keys), ручное управление маршрутами, "zero-knowledge proof" через fingerprint. Проект сопровождается кодексом поведения (Code of Conduct), подготовленным в соответствии с принципом "радикальной честности". В правилах прописано "право на посыл" (право послать любого разработчика при плохом коде), "зеркальный ответ" (жалобы на токсичность игнорируются), первостепенность кода (неважно, кто автор, а важно качество кода) и бан за попытки навязывания политкорректности.
| ||
| · | 02.02.2026 | Атака на проект Notepad++, приведшая к выборочной подмене обновлений (128 +22) |
|
Разработчики Notepad++, открытого редактора кода для платформы Windows, опубликовали разбор инцидента, в результате которого была скомпрометирована сетевая инфраструктура провайдера и некоторые пользователи Notepad++ получили подменённые исполняемые файлы, загружаемые с использованием системы автоматической доставки обновлений WinGUp.
Атака была проведена через выборочное перенаправление трафика между пользователем и сервером загрузки обновлений. Подмена оказалась возможной из-за уязвимости в механизме верификации и проверки целостности загружаемого обновления. Атакующий, способный вклиниться в транзитный трафик, мог подменить манифест обновления и инициировать вывод запроса на загрузку своего фиктивного обновления и связанных с ним метаданных для проверки целостности. Дополнительный разбор показал, что атака была реализована на уровне инфраструктуры хостинг-провайдера, что позволило злоумышленникам перехватывать и перенаправлять трафик, адресованный домену notepad-plus-plus.org. Перенаправление осуществлялось выборочно только для определённых пользователей, которым отдавался подменённый манифест с информацией об обновлениях. Первые следы активности атакующих датированы июнем 2025 года, а последние - 10 ноября, но возможность совершения атаки сохранялась до 2 декабря. Судя по предоставленной провайдером информации, атака стала возможна благодаря взлому сервера виртуального хостинга, на котором размещался сайт notepad-plus-plus.org. 2 сентября после обновления ПО лазейка была прикрыта, но атакующие до этого получили учётные данные для подключения к одному из внутренних сервисов, что позволяло им до 2 декабря перенаправлять запросы к скрипту "https://notepad-plus-plus.org/getDownloadUrl.php" на свои серверы. 2 декабря подмена обновлений была замечена и провайдер блокировал доступ атакующих. После инцидента сайт Notepad++ был переведён к другому хостинг-провайдеру, более тщательно заботящемуся о безопасности. В версии Notepad++ 8.8.9 для блокирования подмены обновлений в состав Notepad++ и WinGUp были добавлены обязательные проверки не только цифровых подписей, но и сертификатов для загружаемых файлов, а также реализована блокировка применения обновления при неудачной проверке. В ожидаемом в течение месяца выпуске 8.9.2 дополнительно будет добавлена проверка цифровой подписи для XML-манифеста (XMLDSig), возвращаемого сервером доставки обновлений.
| ||
|
Обсуждение (128 +22) |
Тип: Проблемы безопасности |
| ||
| Следующая страница (раньше) >> | ||
|
Закладки на сайте Проследить за страницей |
Created 1996-2026 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |