| · | 15.06.2026 | В GCC утверждено добавление бэкенда для WebAssembly (3) |
|
Комитет, управляющий разработкой набора компиляторов GCC (GCC Steering Committee), утвердил включение в кодовую базу GCC бэкенда для WebAssembly. Решение касается общего одобрения поставки WebAssembly-бэкенда в составе GCC. Вопросы утверждения реализации и принятия переданного кода будет отдельно решать команда, отвечающая за рецензирование.
Бэкенд позволит использовать GCC для компиляции исходного кода на языках C/C++ в промежуточный код WebAssembly. Компиляцию в WebAssembly можно использовать для интеграции с JavaScript-проектами, запуска в web-браузере, использования в Node.js или создания обособленных многоплатформенных приложений, запускаемых при помощи WASM runtime. Бэкенд выступает генератором кода, использующим промежуточный код, подготовленный штатными фронтэндами GCC, выполняющими разбор исходного кода на поддерживаемых языках программирования и предоставляющими специфичные для них оптимизации. Предложенная для включения в GCC реализация использует в качестве внешних зависимостей инструментарий wabt, реализацию libc для WebAssembly (wasi-libc) и компоновщик wasm-ld. Не вся запланированная функциональность реализована, например, отсутствует поддержка отладочной информации, ссылочных типов, таблиц, исключений, структуризации и операций setjump/longjump.
| ||
|
Обсуждение (3) |
Тип: К сведению |
| ||
| · | 15.06.2026 | Вычислительный кластер из 2000 смартфонов Google Pixel (61 +21) |
|
Компания Google рассказала о разработке в Калифорнийском университете в Сан-Диего вычислительного кластера, построенного из двух тысяч материнских плат бывших в употреблении смартфонов Google Pixel. Использование отслуживших своё смартфонов вместо покупки нового оборудования позволит почти без затрат построить рабочий кластер для экспериментов исследователей и студентов. Подобный подход рассматривается как один из способов снижения углеродного следа за счёт возможности обойтись без производства новых серверов для вычислительной инфраструктуры.
В среднем пользователи меняют смартфон каждые четыре года, при том, что смена вызвана социальными факторами и желанием получить новую модель, а не выходом из строя или устареванием вычислительных возможностей. Получается, что без дела остаются миллионы устройств с относительно мощными процессорами. Google предлагает давать подобным устройствам вторую жизнь и создавать из них кластеры для облачных вычислений. Отмечается, что производительность процессорных ядер современных смартфонов при выполнении однопоточных задач сопоставима или превосходит производительность ядер современных серверов. Например, в большинстве проведённых однопоточных тестов SPEC 2017 высокопроизводительные ядра смартфона 2023 Pixel Fold превзошли по производительности (на графике синий) ядра типового сервера ASUS RS720A-E11 (на графике прозрачная рамка) при оценке производительности отдельных процессорных ядер. Ключевое отличие в том, что серверные процессоры оснащены большим числом высокопроизводительных многопоточных ядер, в то время как SoC смартфонов сочетают небольшое число высокопроизводительных и энергоэффективных ядер. С учётом числа ядер вычислительные возможности 25-50 смартфонов рассматриваются как эквивалент современному серверу.
![]() При построении кластера использованы только материнские платы из смартфонов, а вместо Android установлен один из серверных дистрибутивов Linux. Так как смартфоны комплектуются относительно небольшим размером ОЗУ, возможности кластера ограничиваются задачами, для которых достаточно имеющейся в одном устройстве памяти. Для упрощения оркестровки выполнения задач образующие кластер смартфоны разделены на группы по 25–50 устройств, на которых запуск приложений производится в изолированных контейнерах, управляемых через Kubernetes. Кластер планируют ввести в строй осенью этого года и использовать для сопровождения курсов по параллельным вычислениями и системному программированию. Проведённые эксперименты показали, что кластер из 20 смартфонов выдерживает нагрузку по сопровождению курсов для более чем 75 студентов, обеспечивая задержки ниже, чем у ранее применяемого бэкенда на базе AWS. Предполагается, что кластер из 2000 смартфонов будет способен предоставить вычислительные ресурсы для сопровождения сотен курсов.
| ||
|
Обсуждение (61 +21) |
Тип: К сведению |
| ||
| · | 14.06.2026 | Релиз ядра Linux 7.1 (133 +25) |
|
После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 7.1. Среди наиболее заметных изменений: новый драйвер ntfsplus, первая стадия прекращения поддержки CPU i486, удаление старых Ethernet-адаптеров, удаление протоколов ISDN и AX.25, включение по умолчанию механизма Intel FRED, поддержка BPF-обработчиков в io_uring, оптимизация подсистемы подкачки, поддержка субпланировщиков в sched_ext, ввод/вывод в режиме zero-copy в драйвере ublk, ioctl-операция "shutdown" в Btrfs, динамическое переключение режима производительности в драйвере amd-pstate, поддержка xattr для Unix-сокетов.
В новую версию принято 17275 исправлений от 2589 разработчиков, размер патча - 57 МБ (изменения затронули 13528 файлов, добавлено 751785 строк кода, удалено 405916 строк). В прошлом выпуске было 15624 исправлений от 2477 разработчиков, размер патча - 56 МБ. Около 41% всех представленных в 7.1 изменений связаны с драйверами устройств, примерно 12% изменений имеют отношение к обновлению кода, специфичного для аппаратных архитектур, 14% связано с сетевым стеком, 5% - с файловыми системами и 3% c внутренними подсистемами ядра. Основные новшества в ядре 7.1 (1, 2, 3):
| ||
|
Обсуждение (133 +25) |
Тип: Программы |
Интересно
| ||
| · | 14.06.2026 | Истекает время жизни сертификата, которым заверен загрузчик для UEFI Secure Boot в дистрибутивах Linux (98 +2) |
|
Разработчики Fedora Linux прояснили ситуацию, связанную с истечением в конце июня срока действия сертификата Microsoft, применяемого для заверения цифровой подписью прослойки Shim, используемой для верифицированной загрузки дистрибутивов Linux в режиме UEFI Secure Boot. Переход на новый сертификат должен пройти незаметно для пользователей так как фактически завершение времени жизни сертификата приведёт лишь к невозможности его использования для создания новых подписей. Во время загрузки UEFI Secure Boot срок действия сертификата не проверяется и имеет значение только отзыв скомпрометированных сертификатов.
Существующие системы без установки обновления shim продолжат загрузку до тех пор, пока открытый ключ сертификата не будет удалён из прошивки или не помещён в список отозванных сертификатов UEFI (DBX). Ключом Microsoft заверяется только загрузочная прослойка shim, в которой присутствует публичный ключ дистрибутива, применяемый для заверения загружаемых компонентов, таких как загрузчик GRUB2, ядро Linux, модули ядра и используемые при загрузке процессы, такие как fwupd. Подобный подход позволяет заверять в Microsoft только изменения в прослойке shim и самостоятельно обеспечивать верификацию процесса загрузки дистрибутива. Сертификат Microsoft для заверения сторонних прошивок для UEFI Secure Boot действует с 2011 года. В 2023 году ему на смену сгенерирован новый сертификат, который стал применяться для формирования подписей с октября 2025 года. В репозиторий Fedora Rawhide, на базе которого формируется релиз Fedora 45, уже добавлен обновлённый shim, заверенный несколькими ключами для обеспечения максимальной совместимости с оборудованием (может использоваться как на старых прошивках без открытого ключа нового сертификата, так и на прошивках без открытого ключа старого сертификата). Несмотря на то, что истечение срока действия сертификата Microsoft не должно повлиять на работоспособность загрузки, разработчики Fedora рекомендуют пользователям обновить БД c ключами для Secure Boot при появлении новых версий прошивок для их оборудования. Для определения факта загрузки системы в режиме UEFI Secure Boot можно использовать команду "mokutil --sb-state", а для отображения списка имеющихся в прошивке открытых ключей - "mokutil --db --short". Для просмотра ключей, которыми подписана прослойка shim можно запустить команду "sudo pesign -S -i /boot/efi/EFI/fedora/shimx64.efi", предварительно установив пакет pesign. Для проверки наличия обновления прошивки и его установки можно выполнить команду "sudo fwupdmgr update". Следующая версия прослойки shim будет заверена только новым сертификатом Microsoft и обновление прошивки необходимо для подготовки своих систем к этому изменению. Обновление shim будет выпущено в случае выявления уязвимостей и серьёзных ошибок, что может произойти как через месяц, так и через год. За время существования shim в проекте находили критические уязвимости, при этом последний отчёт о проблемах c безопасностью в shim был выпущен лишь несколько дней назад. В отчёте отмечены две недавно выявленные уязвимости CVE-2026-8863 и CVE-2026-10797, позволяющие добиться выполнения своего кода на раннем этапе загрузки до передачи управления операционной системе, обойти защиту UEFI Secure Boot и реализовать загрузку незаверенных цифровой подписью компонентов ядра. Проблемы затрагивают версии shim до выпуска 0.9 включительно, сформированные до 2016 года. Атаке подвержены очень старые системы, такие как RedHat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2, ROSA Linux R10/R9 и openSUSE c shim 0.9. Прослойки shim до версии 0.9 включительно добавлены в базу отозванных цифровых подписей DBX (UEFI Forbidden Signature Database) и в случае обновления DBX в системе не смогут использоваться для загрузки в режиме UEFI Secure Boot.
| ||
|
Обсуждение (98 +2) |
Тип: Обобщение |
| ||
| · | 13.06.2026 | Удостоверяющий центр GlobalSign начал отзыв EV-сертификатов у компаний, находящихся под санкциями (22 +18) |
|
Удостоверяющий центр GlobalSign, зарегистрированный в Бельгии и принадлежащий японской корпорации GMO Group, начал отзыв SSL-сертификатов, ранее выданных российским компаниям, подпадающим под действующие в Евросоюзе санкции. В письме к партнёрам компании GlobalSign, отправленном директором российского представительства, сказано, что отзыв сертификатов начался 13 июня в 04:10 (MSK) и будет проводиться поэтапно. В качестве причины указано утверждение консорциумом CA/Browser Forum, выступающим площадкой для совместного принятия решений с учётом интересов производителей браузеров и удостоверяющих центров, новых требований по проверке организаций при выдаче сертификатов.
Речь ведётся о расширенных TLS-сертификатах уровня EV (Extended Validation), подтверждающих заявленные параметры идентификации и требующих не только проверки владения доменом, но и проведения удостоверяющим центром проверки существования и легального статуса компании, получающей сертификат. В браузерах при работе с сайтами, имеющими EV-сертификаты и сертификаты, полученные только через подтверждение домена, отображается одинаковый значок. Указано, что во вступившей в силу 4 мая новой версии регламента выдачи EV-сертификатов содержится прямой запрет для удостоверяющих центров выдавать сертификаты компаниям из санкционных списков, а проверка по спискам блокировки стала не рекомендательной, а обязательной. Данная информация не соответствует действительности, так как упомянутые требования были добавлены CA/Browser Forum в более ранней версии регламента (как минимум прослеживаются в версии 1.7.0 от 2019 года). В пункты 3.2.2.12.2 и 4.1.1.1, предписывающие проверку в санкционных списках, в новой версии документа изменения не вносились (версия 2.0.2 от 4 мая 2026 года, версия 2.0.1 от 6 мая 2024 года). В пункте 4.1.1.1 среди условий прохождения проверки при получении EV-сертификата упомянуто отсутствие проверяемой компании в списках запрещённых организаций или организаций, подпадающих под эмбарго, в соответствии с законодательством страны, в которой зарегистрирован удостоверяющий центр. В пункте 3.2.2.12.2 указано, что удостоверяющий центр обязан проверить наличие запросившей сертификат организации в списках запрещённых персон и организаций, действующих в стране, в юрисдикции которой находится удостоверяющий центр, а также в странах, в которых удостоверяющий центр осуществляет свою деятельность. Удостоверяющий центр обязан не выдавать EV-сертификат, если запросившая сертификат организация присутствует в подобных списках или если она ведёт деятельность или зарегистрирована в стране, с которой запрещено ведение бизнеса законодательством страны, в которой зарегистрирован удостоверяющий центр. Компания GlobalSign зарегистрирована в Бельгии и обязана выполнять санкционные ограничения, действующие в Евросоюзе. Помимо индивидуальных санкций, в Евросоюзе также действует введённый в 14 пакете санкций запрет на предоставление корпоративного ПО и оказание IT-услуг российским юридическим лицам. Предполагается, что GlobalSign до сегодняшнего дня не выполнял данные требования, пользуясь введённым в законодательство исключением, позволявшим предоставлять подсанкционным компаниям услуги для обеспечения безопасности всего интернета. Теперь выдача SSL-сертификатов квалифицирована юристами GlobalSign или регулирующими органами как оказание коммерческих IT-услуг, что подпадает под санкционные запреты.
| ||
|
Обсуждение (22 +18) |
Тип: К сведению |
| ||
| · | 13.06.2026 | Власти США предписали Anthropic приостановить доступ к AI-моделям Fable 5 и Mythos 5 (65 +13) |
|
Компания Anthropic объявила об отключении доступа к AI-моделям Fable 5 и Mythos 5 для всех пользователей после получения от правительства США директивы об экспортном контроле, изданной с упоминанием полномочий в области национальной безопасности и без предоставления детальных пояснений. Директива запрещает доступ к моделям Fable 5 и Mythos 5 любым иностранным гражданам как на территории США, так и за её пределами, включая иностранных сотрудников компании Anthropic, в результате чего для соблюдения требований компания была вынуждена полностью отключить модели. Выполнение требования не повлияло на доступ к остальным моделям Anthropic.
По предположению Anthropic, поводом для предписания послужило обнаружение метода обхода защитных механизмов (jailbreak) модели Fable 5. В Anthropic заявили, что изучили продемонстрированную технику и пришли к выводу, что речь идёт об узкоспециализированном неуниверсальном обходе, позволяющем выявлять лишь небольшое число ранее известных незначительных уязвимостей, которые могут быть найдены и другими общедоступными моделями, например GPT-5.5, без какого-либо обхода ограничений. Компания Anthropic подчинилась юридически обязательной директиве, но не согласна с тем, что обнаружение узкоспециализированного потенциального обхода защиты является основанием для отзыва коммерческой модели, развёрнутой для сотен миллионов пользователей, считает произошедшее недоразумением и работает над восстановлением доступа. До урегулирования ситуации новые сеансы в продуктах Claude будут запускаться с Opus 4.8 или выбранной пользователем AI-моделью, а существующие сеансы с Fable 5 будут завершены с выводом ошибки.
| ||
| · | 12.06.2026 | В Chrome 151 будет удалён обходной путь для установки uBlock Origin (142 –40) |
|
В намеченном на 30 июня выпуске Chrome 150 будет удалена поддержка флага kExtensionManifestV2Disabled, позволявшего вернуть возможность установки из каталога Chrome Web Store дополнений, использующих вторую версию манифеста Chrome. Позавчера из кодовой базы Chromium, на основе которой формируется выпуск Chrome 151, запланированный на 28 июля, дополнительно был удалён код с реализацией параметра AllowLegacyMV2Extensions, позволявшего вручную в режиме разработчика загружать дополнения на базе второй версии манифеста. За несколько дней до этого из кодовой базы Chromium также были удалены параметры kExtensionManifestV2Unsupported и ExtensionManifestV2Availability, которые около года назад были объявлены неподдерживаемыми.
Участники проекта uBlock Origin рекомендовали пользователям Chrome перейти на другие браузеры или переключиться на дополнение uBlock Origin Lite, которое развивается автором uBlock Origin и представляет собой вариант uBlock Origin, переведённый на предложенный в третьей версии манифеста Chrome декларативный API (declarativeNetRequest). Поддержка второй версии манифеста Chrome присутствует в Firefox и Safari, а также будет сохранена в браузерах Brave и Opera на базе движка Chromium. Третья версия манифеста Chrome, определяющего возможности и ресурсы, доступные для дополнений, написанных с использованием API WebExtensions, разработана в рамках инициативы по упрощению создания безопасных и высокопроизводительных дополнений. Основное недовольство третьей версией манифеста вызвано переводом в режим только для чтения API webRequest, позволявшего подключать собственные обработчики, имеющие полный доступ к сетевым запросам и способные на лету модифицировать трафик. Вместо API webRequest в третьей версии манифеста добавлен ограниченный по своим возможностям API declarativeNetRequest, предоставляющий доступ к встроенному движку для фильтрации, самостоятельно обрабатывающему правила блокировки, не разрешающему использовать собственные алгоритмы фильтрации. Дополнение uBlock Origin Lite (uBOL) реализует лишь часть функциональности uBlock Origin. В uBlock Origin Lite оказалось проблематично перенести динамические фильтры контента и URL, фильтры HTTP-заголовков, средства для отключения скриптов, шрифтов и мультимедийных элементов большого размера в привязке к отдельным сайтам, многие опции фильтров (strict1p, strict3p, domain, redirect-rule, removeparam), защиту от манипуляций с DNS для обхода блокировки. Из-за необходимости получения дополнительных полномочий в uBlock Origin Lite по умолчанию отключены косметические фильтры для замены содержимого на странице ("##"), подстановки скриптов на сайты ("##+js"), фильтров для перенаправления запросов ("redirect="), фильтров заголовков CSP (Content Security Policy) и фильтров для удаления параметров запросов ("removeparam=").
| ||
|
Обсуждение (142 –40) |
Тип: К сведению |
| ||
| · | 12.06.2026 | Атакующие скомпрометировали 1577 пакетов в репозитории AUR (153 +42) ↻ |
|
Зафиксирована массовая компрометация пакетов в репозитории AUR (Arch User Repository), применяемом в Arch Linux для распространения приложений от сторонних разработчиков. Атакующие получили контроль над Атакующие взяли на себя сопровождение пакетов, имеющих статус "orphaned" и оставшихся без сопровождающих. В качестве имени указывалось имя последнего сопровождающего, но другой email, после чего добавлялся один коммит и публиковалось обновление. Коммит добавлял "npm" в список зависимостей PKGBUILD и вставлял в post_install-блок скрипта install.sh строку для установки нескольких NPM-пакетов. В числе устанавливаемых NPM-пакетов присутствовали один или несколько популярных легитимных пакетов и пакет atomic-lockfile или js-digest, содержащие скрытое вредоносное ПО. Добавление установки NPM-пакетов производилось во все скомпрометированные проекты, даже если в них не используется JavaScript и NPM. После активации вредоносное ПО закреплялось в системе в виде сервиса systemd со случайным именем и при выполнении камуфлировалось под поток ядра. При запуске с правами root сервис создавался на системном уровне (/etc/systemd/system) и дополнительно активировал работающий на уровне ядра rootkit, а при выполнении с правами пользователя - запускался от имени пользователя (~/.config/systemd/user). Вредоносное ПО осуществляло сканирование и отправку на внешний сервер ключей и учётных данных VPN, Docker, Podman и SSH, а также извлечённых из браузера конфиденциальных данных, истории команд в shell, ключей криптовалютных кошельков, токенов доступа к Slack, Microsoft Teams, Discord, GitHub, NPM и Vault. Дополнение 1: число пакетов в AUR, в которые была внедрена загрузка вредоносного NPM-пакета js-digest достигла 879. Общее число захваченных пакетов оценивается в 1577. Разработчики Arch Linux принимают меры для остановки волны захвата пакетов. До выработки окончательного решения могут наблюдаться проблемы с созданием новых учётных записей в AUR, отправкой обновлений пакетов и созданием новых пакетов. Дополнение 2: Реализованных мер оказалось недостаточно и в AUR осуществлена подстановка вредоносного кода ещё в 54 пакета. На этот раз в зависимости добавлен bun, а в функцию post_install вставлена обфусцированная строка для установки вредоносных пакетов командой "bun add".
| ||
|
Обсуждение (153 +42) ↻ |
Тип: Проблемы безопасности |
| ||
| · | 11.06.2026 | Выпуск X-сервера yserver 1.0.0, написанного на Rust и пригодного для запуска MATE, Xfce и Cinnamon (87 +36) |
|
Опубликован первый значительный выпуск X11-сервера yserver, написанного с нуля на языке Rust и поддерживающего актуальные расширения протокола X11. Проект не ставит перед собой цель повторить все возможности Xorg Server и ограничивается только функциональностью, необходимой для запуска современных сред рабочего стола, оконных менеджеров, приложений и графических библиотек (GTK, Qt, SDL, GLFW). Из протестированных окружений отмечены MATE, Xfce и Cinnamon, а также оконные менеджеры FVWM3, e16 и wmaker. Код проекта распространяется под лицензией MIT.
В yserver решено не поддерживать устаревшие и специфичные возможности, такие как обработка нескольких X11-экранов в одном сервере (многомониторный вывод поддерживается), отличные от TrueColor режимы цветности, непрямой рендеринг (indirect GLX), API драйверов DDX, старые методы работы со шрифтами и подключение клиентов с другим порядком следования байтов (трансляция между big-endian и little-endian). Вывод графики организован через DRM/KMS и Vulkan-драйверы Mesa. Для управления сеансом и организации доступа к совместно используемым устройствам ввода и вывода используется библиотека libseat. Помимо обособленного X-сервера поставляется ynest - бэкенд для вложенного запуска, поддерживающий работу из Xwayland или другого X11-сервера. Работа протестирована на системах в GPU AMD Ryzen 9 6900HX (Rembrandt, RDNA2, mesa-драйвер RADV), AMD RX580 (Polaris/GCN4, RADV), Intel i5-7200U (Kaby Lake, mesa-драйвер ANV), NVIDIA GTX 1050, Snapdragon X1 X1E80100 (Adreno X1, Turnip), Apple M1 MBA, M2 MBP, а также в системах виртуализации с virtio-gpu и виртуальным GPU Venus. В настоящее время поддерживается только работа в Linux, но в планах отмечено добавление поддержки FreeBSD. Поддерживаемые расширения X11:
| ||
|
Обсуждение (87 +36) |
Тип: Программы |
| ||
| · | 11.06.2026 | В Fedora выявлена подмена взломанного участника AI-агентом для продвижения сомнительных изменений (75 +38) |
|
Адам Уильямсон (Adam Williamson) из компании Red Hat, возглавляющий команду контроля качества в проекте Fеdora, обратил внимание на подозрительную активность Натана Джованнини (Nathan Giovannini), присоединившегося к проекту Fedora в 2016 году и некоторое время участвовавшего в работе команды Fedora Infrastructure Team. Не исключается, что деятельность, совершаемая за последние два месяца от имени Натана, была направлена на завоевание доверия через накопление истории принятых изменений и участие в исправлении ошибок, перед совершением вредоносных действий, как в инциденте с подстановкой бэкдора в пакет xz.
Подозрение вызвало то, что ранее особо не проявлявший себя разработчик в мае стал активно участвовать в обсуждении ошибок и отправлять патчи, при том, что в подобной активности прослеживались шаблоны, свойственные использованию AI. Например, в комментариях встречались созданные через AI обобщения, после которых Натана просили не злоупотреблять копированием выводов от AI-ассистента. Кроме того, отмечались не несущие какого-то смыла переназначения на себя отчётов о проблемах в подсистемах, в которых Натан не является сопровождающим (1, 2, 3), изменения статуса или приоритета исправления проблем (1, 2), публикации созданных через AI рекомендаций авторам сообщений об ошибках (1, 2, 3) и отправки сгенерированных в AI патчей. В обход правил проекта Натан закрывал отчёты об ошибках сразу после передачи AI-патчей в вышестоящие проекты, не дожидаясь их принятия, или просто закрывал с флагом "NOTABUG" и рекомендацией перепроверить проявление проблемы. Адам Уильямсон предположил, что Натан задействовал для работы AI-агента для исправления ошибок в Fedora и попросил прекратить использование AI-агента в автономном режиме. Натан ответил, что это не его AI-агент, его учётные данные были скомпрометирваны и кто-то посторонний действует от его имени. Следом Натан опубликовал сообщение, что он восстановил доступ к учётным записям в Fedora и GitHub, а также написал, что его официальный аккаунт в GitHub - "nathangiovannini99". Сообщение вызвало ещё больше вопросов, так как отмеченная учётная запись была создана за час до публикации письма и в GitHub всплыли ещё как минимум две учётные записи, ассоциированные с Натаном (leurus27-boop, nathan9513-aps). Не исключалось, что с разработчиками Fedora продолжает общаться злоумышленник, получивший доступ к email Натана. Доступ учётной записи Натана к Bugzilla был заблокирован и была запущена проверка всех совершённых им изменений. Выяснилось, что подозрительная деятельность началась 7 апреля и некоторые отправленные Натаном патчи лишь создавали видимость исправления. При этом подобные патчи были приняты в состав инсталлятора Anaconda и вошли в состав релиза Anaconda 45.5. Сопровождающий Anaconda отменил внесённые изменения и опубликовал релиз Anaconda 45.6 без этих патчей. Помимо этого, отправленные от имени Натана исправления были приняты разработчиками утилиты osc (openSUSE Commander) с реализацией интерфейса командной строки для сборочной системы Open Build Service. Ещё один патч был передан для включения в пакет lxqt-policykit с привязкой к исправлению проблемы в Fedora, но разработчики Fedora успели предупредить сопровождающего до его принятия. Патчи не включали вредоносных действий, но предполагается, что они могли быть подготовкой к внесению вредоносных изменений в компоненты сборочной системы и сервиса, обеспечивающего выполнение привилегированных операций. Отправленные Натаном исправления также были замечены в проектах gwenview и easyeffects.
| ||
|
Обсуждение (75 +38) |
Тип: К сведению |
Интересно
| ||
| · | 10.06.2026 | Первый стабильный выпуск открытого офисного пакета Euro-Office (126 –7) |
|
Опубликован первый стабильный выпуск проекта Euro-Office, развивающего платформу для совместного редактирования документов, электронных таблиц и презентаций. В основе Euro-Office лежит серверный компонент DocumentServer, предоставляющий online-редакторы, открываемые на клиентских системах в браузере. Проект является форком кодовой базы продукта ONLYOFFICE DocumentServer и полностью повторяет его функциональность. Как и исходный продукт Euro-Office распространяется под лицензией AGPLv3. Готовые сборки сформированы для архитектур x86_64 и ARM64 в форматах deb и rpm.
К разработке Euro-Office подключилось 12 европейских компаний и организаций, среди которых Nextcloud, IONOS, Eurostack, XWiki, OpenProject, Soverin, Abilian и BTactic. Проект преподносится как открытая, прозрачно развиваемая и независимая платформа для совместной работы с документами, рассчитанная на использование через Web и интеграцию со сторонними продуктами, такими как системы обмена файлами, wiki и инструментами управления проектами. Заявлена совместимость с форматами MS Office и OpenDocument (DOCX, PPTX, XLSX, ODT, ODS, ODP). Среди причин создания собственного форка вместо присоединения к разработке открытого проекта ONLYOFFICE упоминаются:
Организация The Document Foundation, курирующая разработки офисного пакета LibreOffice, опубликовала открытое письмо с критикой проекта Euro-Office и методов его продвижения. Недовольство вызывает то, что в Euro-Office по умолчанию применяется формат OOXML, подконтрольный компании Microsoft. По мнению The Document Foundation, использование по умолчанию проприетарного формата OOXML вместо открытого стандарта OpenDocument расходится с заявленной целью формирования европейского цифрового суверенитета, так как Euro-Office укрепляет привязку к одному американскому производителю, не способствующему предоставлению пользователям свободы полностью контролировать собственный контент. Также подвергаются критике заявления о том, что Euro-Office стал первым открытым офисным пакетом, разработанным в Европе. Первым европейскими открытыми офисными пакетами являются OpenOffice.org и LibreOffice, основанные на исходном коде StarOffice, разработанном немецкой компанией Star Division. Euro-Office же создан на волне роста популярности идей цифрового суверенитета в результате ребрендинга сторонней кодовой базы. ![]() ![]() ![]() ![]()
| ||
|
Обсуждение (126 –7) |
Тип: Программы |
| ||
| · | 10.06.2026 | Уязвимость в процессорах ARM, позволяющая обойти изоляцию виртуальных машин (47 +19) |
|
Компания ARM раскрыла информацию об уязвимости (CVE-2025-10263) в своих процессорах, позволяющей осуществить запись в ресурсы, принадлежащих более высокому уровню исключений (Exception Level), что потенциально позволяет добиться повышения привилегий в системе. В контексте гипервизора Xen уязвимость даёт возможность из гостевой системы осуществить запись в память, принадлежащую гипервизору.
Проблема проявляется только на многоядерных процессорах Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse N2, Neoverse N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76AE и NVIDIA Olympus. Для блокирования проблемы обходным путём для ядра Linux предложен патч, который пока не вошёл в состав корректирующих обновлений. Исправление также выпущено для гипервизора Xen. Уязвимость возникает в процессе выполнения операции TLBI (TLB Invalidation) для очистки записи в кэше трансляции виртуальных адресов в физические. Инструкция DSB (Data Synchronization Barrier), фиксирующая выполнение операции TLBI, на одном ядре может завершиться раньше, чем операция записи на другом ядре станет глобально видна всем ядрам. Таким образом, операция записи может быть завершена после того, как права доступа были изменены через TLBI. Данная рассинхронизация состояния может применяться для обхода запрета доступа на уровне таблиц трансляции виртуальных адресов в физические (Stage 1) и трансляция адресов виртуальной машины (Stage 2), а также обхода механизма защиты целостности памяти GPT (Granule Protection Table). Например, гипервизор может выполнить инструкцию TLBI для запрета доступа к памяти для виртуальной машины, но гостевая система сможет продолжить писать в эту память, несмотря на подтверждение прекращения доступа.
| ||
|
Обсуждение (47 +19) |
Тип: Проблемы безопасности |
| ||
| · | 10.06.2026 | Lets Encrypt добавил в пользовательское соглашение запрет на выдачу сертификатов для стран под санкциями США (124 –37) |
|
Некоммерческий удостоверяющий центр Let's Encrypt, контролируемый сообществом и предоставляющий сертификаты безвозмездно всем желающим, внёс изменение в пользовательское соглашение, определяющее права и обязанности получателей сертификатов. В секцию с условиями запроса и использования сертификатов добавлен пункт, не допускающий выдачу сертификатов для физических лиц и организаций, постоянно проживающих или зарегистрированных в странах или на территориях, на которые распространяются полномасштабные (comprehensive) санкции США.
Помимо этого под запрет подпадают лица и организации, являющиеся объектом персональных санкций и ограничений экспортного контроля США, а также организации, контролируемые лицами, подпадающими под санкции, или действующие от их имени. Отмечается, что организация Let's Encrypt зарегистрирована в США и обязана выполнять правила экспортного контроля и санкции, действующие в США. До сих пор в Let's Encrypt применялись точечные блокировки, не позволяющие получить сертификат для конкретных доменов, перечисленных в санкционных списках управления по контролю за иностранными активами США (OFAC, Office of Foreign Assets Control). Полномасштабные санкции США введены против Крыма, ДНР, ЛНР, Ирана, КНДР и Кубы. Против РФ введены жёсткие санкции, но пока не применяется полное эмбарго. В данный момент запросы к Let's Encrypt на получение сертификатов из РФ для доменов, не упомянутых в санкционных списках, принимаются без ограничений. Комментируя изменение пользовательского соглашения, директор организации ISRG (Internet Security Research Group), которая является учредителем проекта Let's Encrypt, пояснил, что сертификаты продолжат выдаваться для частных лиц и негосударственных компаний из Ирана и России, но не будут доступны для российских и иранских госучреждений. По словам представителя Let's Encrypt, изменения лишь документируют давно сложившуюся практику для выполнения юридических формальностей и никаких новых блокировок не последует. Возможность предоставлять сертификаты для негосударственных учреждений и частных лиц на подсанкционных территориях обеспечивается благодаря действующим в США законам о защите частной переписки и послаблениям, принятым Управлением по контролю за иностранными активами (OFAC) для содействия соблюдению прав человека и свобод в интернете.
![]()
| ||
|
Обсуждение (124 –37) |
Тип: К сведению |
| ||
| · | 09.06.2026 | Выпуск ядра Asterinas 0.18, написанного на языке Rust и совместимого с Linux (138 +30) |
|
Представлен релиз проекта Asterinas 0.18, развивающего ядро, написанное на языке Rust и предназначенное для использования в операционных системах общего назначения. Ядро предоставляет ABI (Application Binary Interface), совместимый с ядром Linux и способный использоваться вместо него. Параллельно развивается дистрибутив Asterinas NixOS, сочетающий ядро Asterinas с системным окружением NixOS. Код проекта распространяется под лицензией MPL (Mozilla Public License).
В настоящее время в ядре реализовано около 240 системных вызовов Linux. В дистрибутиве Asterinas NixOS верифицирована работа поверх ядра Asterinas более 100 пакетов из NixOS. Среди поддерживаемых пакетов: Xfce, Firefox, bash, systemd, Podman, QEMU, rsync, Apache httpd, nginx, SQLite, Redis, Clang, GCC, Go, Lua, Node.js, OpenJDK, Perl, PHP, Python, Ruby, Rust, Git, FFmpeg, PyTorch, TensorFlow, Ollama и Codex. В ядре обеспечена полная поддержка архитектуры x86-64, частичная поддержка RISC-V 64 и x86-64 с изоляцией на базе Intel TDX, а также начальная поддержка архитектуры LoongArch 64. Из приоритетных областей применения называются системы, завязанные на Linux ABI, но требующие более высокого уровня защищённости. Например, Asterinas предлагается использовать для формирования системного окружения защищённых виртуальных машин, для изоляции которых используются такие технологии, как ARM CCA, AMD SEV и Intel TDX, а также на стороне хост-системы, обеспечивающей запуск контейнеров. Для снижения вероятности появления ошибок при работе с памятью, являющихся главным источником наиболее опасных уязвимостей, при написании Asterinas задействован язык Rust и тактика ограниченного использования unsafe-блоков. Ядро построено с использованием архитектуры framekernel, в которой попытались совместить возможности изоляции микроядер с эффективностью монолитных ядер. Компоненты ядра в Asterinas размещаются в общем адресном пространстве, а безопасность достигается на уровне логического разделения безопасного кода и кода, в котором не исключено возникновение проблем с безопасностью. Ядро разбито на две части, написанные на Rust: OS Framework и OS Services. В OS Services запрещено применение unsafe-блоков, а все низкоуровневые операции, требующие выполнения кода в блоках unsafe, вынесены в OS Framework и доступны только через высокоуровневый API. Все системные вызовы, файловые системы и драйверы реализуются на уровне OS Services и не могут включать unsafe-блоки. Для разработки системных сервисов и модулей ядра поставляется инструментарий OSDK (Operating System Development Kit), предоставляющий утилиту cargo-osdk для создания, сборки, тестирования и запуска компонентов операционной системы. Для разработчиков подготовлен набор библиотек OSTD (Operating System Standard Library), включающий редакцию стандартных библиотек Rust(crate std), адаптированную для использования в компонентах операционной системы. Среди изменений в версии 0.18:
| ||
|
Обсуждение (138 +30) |
Тип: Программы |
| ||
| · | 09.06.2026 | Опубликован Vortex 3.0, открытый GPGPU на базе архитектуры RISC-V (28 +25) |
|
Доступен выпуск проекта Vortex 3.0, развивающего открытый GPGPU на базе архитектуры набора команд RISC-V, рассчитанный на выполнение параллельных вычислений с использованием API OpenCL и модели выполнения SIMT (Single Instruction, Multiple Threads). Проект также может быть использован при проведении исследований в области 3D-графики и при разработке новых архитектур GPU. Схемы, описания аппаратных блоков на языке Verilog, симулятор, драйверы и сопутствующая проектная документация распространяются под лицензией Apache 2.0.
Основу GPGPU составляет типовой ISA RISC-V, расширенный дополнительными инструкциями для поддержки функций GPU и управления потоками. Изменения в архитектуре набора команд RISC-V сведены к минимуму и по возможности используются уже имеющиеся векторные инструкции. Среди дополнительных инструкций: "tex" для ускорения обработки текстур; vx_rast для управления растеризацией, vx_rop для обработки фрагментов, глубины и прозрачности; vx_imadd для выполнения операции "умножить и сложить"; vx_wspawn, vx_split, vx_join, vx_tmc и vx_bar для активации групп потоков (wavefront), параллельно выполняемых SIMD Engine. ![]() Развиваемый GPGPU поддерживает 32- и 64-разрядные архитектуры набора команд RISC-V RV32IMF и RV64IMAFD, и может включать опциональную разделяемую память, кэши уровней L1, L2 и L3, а также настраиваемое число ядер, блоков задач (warps) и потоков. В свою очередь для каждого ядра предусмотрена возможность включения настраиваемого числа ALU, FPU, LSU и SFU. Для создания прототипов могут использоваться FPGA Xilinx и Altera, а для симуляции работы чипа применяться Verilator (Verilog-симулятор), RTLSIM (симуляция RTL) и SimX (программная симуляция). Для разработки приложений предлагается инструментарий, включающий адаптированные для работы с Vortex варианты PoCL (компилятор и runtime OpenCL), LLVM/Clang, GCC и Binutils. Проектом поддерживается спецификация OpenCL 1.2 и через трансляцию в OpenCL реализована поддержка промежуточного представления шейдеров SPIR-V. Среди изменений в Vortex 3.0:
| ||
|
Обсуждение (28 +25) |
Тип: К сведению |
| ||
| Следующая страница (раньше) >> | ||
|
Закладки на сайте Проследить за страницей |
Created 1996-2026 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |