| · | 21.02.2025 | Выпуск САПР KiCad 9.0 (31 +7) |
|
После года разработки опубликован релиз свободной системы автоматизированного проектирования печатных плат KiCad 9.0.0. Это третий значительный выпуск, сформированный после перехода проекта под крыло организации Linux Foundation. Сборки подготовлены для различных дистрибутивов Linux, Windows и macOS. Код написан на C++ с использованием библиотеки wxWidgets и распространяется под лицензией GPLv3.
KiCad предоставляет средства для редактирования электрических схем и печатных плат, 3D-визуализации платы, работы с библиотекой элементов электрических цепей, манипуляций с шаблонами в формате Gerber, симуляции работы электронных схем, редактирования печатных плат и управления проектами. Проектом также предоставляются библиотеки электронных компонентов, посадочных мест и 3D-моделей. По сведению некоторых производителей печатных плат, около 15% заказов поступает с предоставлением схем, подготовленных в KiCad. Среди изменений в новом выпуске:
| ||
|
Обсуждение (31 +7) |
Тип: Программы |
| ||
| · | 21.02.2025 | Gentoo представил официальные загрузочные образы в формате QCOW2 (20 +6) |
|
Разработчики проекта Gentoo объявили о формировании официальных загрузочных образов в формате QCOW2, позволяющих получить полностью работающее системное окружение, готовое к запуску в виртуальных машинах. Образы обновляются раз в неделю, что позволяет использовать их для оценки текущего состояния дистрибутива. Ранее проектом распространялись только установочные образы и Live-сборка для загрузки с USB-устройств.
Предложено два варианта: образ без сетевых сервисов с пустым паролем root и образ сетевыми сервисами, заблокированными учётными записями и поддержкой настройки через "cloud-init". Первый вариант предназначен для быстрого ознакомления и тестирования дистрибутива на локальной системе, а второй вариант для развёртывания в облачных окружениях. В качестве файловой системы используется XFS. Образы формируются для архитектур amd64 (x86-64) и arm64 (aarch64), и поддерживают загрузку на системах с EFI (BIOS не поддерживается). В планах публикация образов для архитектур riscv64 и loongarch64. На основе доступных образов можно создавать загрузочные носители, используя команду "qemu-img convert" для преобразования формата qcow2 в дисковый образ.
| ||
|
Обсуждение (20 +6) |
Тип: К сведению |
| ||
| · | 21.02.2025 | Линус Торвальдс пояснил свою позицию в отношении приёма изменений на Rust (157 +20) |
|
К обсуждению сопротивления мэйнтейнеров внедрению Rust в ядро подключился Линус Торвальдс, который пояснил, что никто не заставляет мэйнтейнеров изучать язык Rust, использовать код на Rust или принимать во внимание наличие в ядре кода на Rust. Мэйнтейнеры могут спокойно продолжать работать только с кодом на Си и никак не пересекаться с Rust. Но подобные сопровождающие не могут и влиять на то, как развивается Rust в ядре, например, не могут вмешиваться в организацию внешнего взаимодействия Rust-кода с кодом их подсистемы.
Мэйнтейнеры, которые заинтересованы в продвижении Rust, могут быть вовлечены в разработку и тогда они получают возможность влиять на построение обвязок на Rust и могут принимать участие в сопровождении интерфейсов на Rust. Мэйнтейнеры, которые не хотят иметь дела с Rust, могут не беспокоиться о работе обвязок на Rust, но они не смогут и влиять на их разработку. Таким образом, вокруг разработчиков, использующих только язык Си, формируется своеобразная защитная стена, ограждающая их от проблем, связанных с Rust и позволяющая не соприкасаться с Rust. Но эта стена работает в обе стороны, поэтому если разработчик не хочет иметь дело с Rust, он не получает возможность влиять на продвижение Rust. Иными словами: "никто не обязан иметь дело с Rust" не обозначает, что "каждый мэйнтейнер может наложить вето на любой код на Rust". Предполагается, что на деле деление мэйнтейнеров не будет столь радикальным и некоторые сопровождающие станут учитывать обвязки на Rust и сотрудничать с их разработчиками, но не слишком активно погружаясь в этот процесс. Что касается ситуации с подтверждением Rust-обвязок над подсистемой DMA в обход мэйнтейнера, пытающегося заблокировать приём подобных обвязок, Линус раскритиковал действия Кристофа Хелвига. По мнению Линуса, Кристоф превысил свои полномочия и попытался повлиять на код, который не затрагивал код подсистемы DMA, был реализован в отдельном подкаталоге и не влиял на код, за который отвечает Кристоф. Кристоф попытался контролировать то, для чего используется подсистема DMA и его действия можно сравнить с попыткой запрета использования DMA в каком-то драйвере лишь потому, что ему не понравился этот драйвер. Итог: несмотря на то, что сопровождающие отвечают за свой код, они не отвечают за то, как и кем используется результат работы этого кода.
| ||
|
Обсуждение (157 +20) |
Тип: К сведению |
| ||
| · | 20.02.2025 | Выпуск Ubuntu 24.04.2 LTS c обновлением графического стека и ядра Linux (89 +8) |
|
Сформировано обновление дистрибутива Ubuntu 24.04.2 LTS, в которое включены изменения, связанные с улучшением поддержки оборудования, обновлением ядра Linux и графического стека, исправлением ошибок в инсталляторе и загрузчике. В состав также включены актуальные обновления для нескольких сотен пакетов, связанные с устранением уязвимостей и проблем, влияющих на стабильность. Одновременно представлены аналогичные обновления Kubuntu 24.04.2 LTS, Ubuntu Budgie 24.04.2 LTS, Ubuntu MATE 24.04.2 LTS,
Lubuntu 24.04.2 LTS, Ubuntu Kylin 24.04.2 LTS, Ubuntu Studio 24.04.2 LTS, Xubuntu 24.04.2 LTS, Edubuntu 24.04.2 LTS, Ubuntu Cinnamon 24.04.2 LTS
и Ubuntu Unity 24.04.2 LTS.
В состав выпуска включены некоторые улучшения, бэкпортированные из выпуска Ubuntu 24.10:
В сборках для рабочего стола (Ubuntu Desktop) новые ядро и графический стек предложены по умолчанию. Для серверных систем (Ubuntu Server) новое ядро добавлено в качестве опции в инсталляторе. Использовать новые сборки имеет смысл только для новых установок - системы, установленные ранее, могут получить все присутствующие в Ubuntu 24.04.2 изменения через штатную систему установки обновлений. Напомним, что для поставки новых версий ядра и графического стека применяется rolling-модель поддержки обновлений, в соответствии с которой бэкпортированные ядра и драйверы будут поддерживаться только до выхода следующего корректирующего обновления LTS-ветки Ubuntu. Так, предложенное в нынешнем выпуске ядро Linux 6.11 будет поддерживаться до выхода Ubuntu 24.04.3, в котором будет предложено ядро из состава Ubuntu 25.04. Изначально поставляемое базовое ядро 6.8 будет поддерживаться в течение всего пятилетнего цикла сопровождения. Для отката Ubuntu Desktop на базовое ядро 6.8 следует выполнить команду:
sudo apt install --install-recommends linux-generic
Для установки нового ядра в Ubuntu Server следует запустить: sudo apt install --install-recommends linux-generic-hwe-24.04
| ||
|
Обсуждение (89 +8) |
Тип: Программы |
| ||
| · | 20.02.2025 | Выпуск Netflow/IPFIX/sFlow коллектора Xenoeye 25.02 (12 +9) |
|
Опубликован релиз Netflow/IPFIX/sFlow коллектора Xenoeye 25.02. Коллектор позволяет собирать с различных сетевых устройств статистику о потоках трафика, передаваемую с использованием протоколов Netflow v5, v9, IPFIX и sFlow, обрабатывать данные, генерировать отчёты и строить графики. Ядро проекта написано на языке С, код распространяется под лицензией ISC.
Коллектор агрегирует сетевой трафик по выбранным полям и экспортирует данные в PostgreSQL. По этим данным можно строить отчеты, графики (используя gnuplot, скриптами на Python + Matplotlib) или дашборды в Grafana. Кроме этого, коллектор может запускать пользовательские скрипты при превышении порогов или при падении трафика ниже порогов.  Для подсчёта текущей скорости трафика используются скользящие средние. Механизм, отслеживающий превышение порогов, предназначен для оповещения о DoS/DDoS-атаках и запуске подавления с помощью BGP-анонсов (Flowspec или Blackhole). В комплекте с коллектором идет пример скрипта Telegram-робота, который может оповещать в мессенджер об аномалиях. Коллектор не требователен к ресурсам, он может обрабатывать трафик небольших сетей на Raspberry/Orange Pi или в виртуальной машине с 2-4Гб оперативной памяти. Изменения в новой версии:
| ||
| · | 20.02.2025 | Mozilla диверсифицирует бизнес через AI-продукты и платформу online-рекламы (62 –11) |
|
Марк Сурман (Mark Surman), президент организации Mozilla Foundation, объявил о реорганизации управления проектом Mozilla и диверсификации путей получения доходов. Изменения объясняются желанием преодолеть препятствия, связанные с финансовым ростом и продвижением миссии проекта. Отмечается, что дальнейшее выживание Mozilla зависит одновременно от того, как проект укрепит Firefox, привлечёт новые источники дохода и расширит способы продвижения свой миссии.
В дополнение к браузеру Firefox, который останется основным направлением деятельности Mozilla, компания анонсировала три новых направления:
Изменения в управлении сводятся к созданию нового управляющего органа Mozilla Leadership Council, в который войдут руководители всех организаций Mozilla, а также назначению новых председателей советов директоров организаций Mozilla Foundation, Mozilla Corporation и Mozilla.ai. Совет Mozilla Leadership Council создан для координации совместной работы организаций, образующих проект Mozilla. В совет вошли Mark Surman (президент) и Jane Silber (Mozilla.ai), Laura Chambers (Mozilla Corporation), Mohamed Nanabhay (Mozilla Ventures), Nabiha Syed (Mozilla Foundation) и Ryan Sipes (MZLA/Thunderbird). Митчелл Бейкер (Mitchell Baker) покинула совет директоров Mozilla Corporation (Executive Chairwoman) и прекратила занимать пост его председателя. Новым председателем назначена Керри Купер (Kerry Cooper), которая была принята в совет директоров Mozilla Corporation два года назад, а до этого занимала связанные с маркетингом руководящие должности в компаниях Walmart.com, Rothy's и Choose Energy. Председателем совета директоров Mozilla Foundation назначена Николь Вонг (Nicole Wong), юрист по вопросам конфиденциальности и интеллектуальной собственности, занимавшая руководящие должности в Google и Twitter. На пост председателем совета директоров Mozilla.ai утверждён Раффи Крикорян (Raffi Krikorian), возглавлявший лабораторию беспилотных автомобилей в Uber, занимавший пост вице-президента по разработке платформ в Twitter и являвшийся техническим директором организации Emerson Collective.
| ||
|
Обсуждение (62 –11) |
Тип: К сведению |
| ||
| · | 20.02.2025 | Мнение Грега Кроа-Хартмана и Кейса Кука о продвижении Rust в ядро Linux (472 +28) |
|
Грег Кроа-Хартман (Greg Kroah-Hartman), отвечающий за поддержку стабильной ветки ядра Linux, высказался в поддержку разработки новых компонентов ядра на языке Rust. Как человек, через которого последние 15 лет проходит вся информация об ошибках и уязвимостях в ядре Linux, он утверждает, что большинство ошибок в ядре вызваны неучитываемыми особенностями языка Си (corner case), которые полностью исключены в коде на языке Rust.
При использовании Rust можно будет оставить в прошлом такие проблемы, как обращение к памяти после её освобождения, выход на границу буфера (частично), некорректное освобождение ресурсов при обработке ошибок и забытые проверки возвращаемых кодов ошибок, что позволит мэйнтейнерам сосредоточиться на реальных ошибках, таких как состояния гонки и проблемы с логикой, а не рассеивать при рецензировании внимание по мелочам. Уже имеющийся старый код на языке Си никуда не денется, а вот для нового кода и новых драйверов внедрение Rust позволит существенно поднять качество. Внедрение Rust также даст возможность структурировать внутренние программные интерфейсы ядра таким образом, что будут практически исключены ошибки использования внутреннего API - в ядре накопилось слишком много сложных и запутанных API, создающих большую нагрузку на мэйнтейнеров в их работе по проверке, что данные API используются правильно. В процессе развития Rust-обвязок у мэйнтейнеров появляется возможность переосмыслить и привести в порядок API, что принесёт пользу для всех, включая использующих язык Си. Грег не считает Rust "серебряной пулей", которая позволит решить все проблемы в ядре, но данный язык точно поможет в огромном числе ситуаций. Поддержка Rust также удовлетворит потребность разработчиков драйверов, которые надеются получить инструмент, позволяющий писать код для их оборудования, исключая многие типы ошибок. Что касается, смешивания нескольких языков, Грег не видит в этом большой проблемы, по его мнению, в прошлом разработчики ядра справлялись и с более серьёзными задачами, и нет повода отказываться от продвижения в ядро новых хороших идей, которые помогут обеспечить успех проекта на следующие 20+ лет. К обсуждению также присоединился Кейс Кук (Kees Cook), бывший главный системный администратор kernel.org и лидер Ubuntu Security Team. Кейс уточнил, что речь не про переписывание уже имеющегося кода в ядре, а в предоставлении возможности использования Rust для создания новых драйверов и подсистем. Применение Rust для нового кода позволит не только снизить число ошибок при работе с памятью, но и сократить время разработки. Скорость разработки возрастает благодаря снижению трудозатрат на отладку и наличию в языке строгих гарантий, позволяющих выявлять ошибки на ранней стадии написания кода, ещё до начала тестирования продукта. Эффективность тактики использования Rust для повышения качества нового кода уже продемонстрирована Google в платформе Android. Показано, что основным источником проблем с безопасностью является новый код, и повышению его качества следует уделять основное внимание. Для старого кода наблюдается экспоненциальная зависимость безопасности от времени (например, 5-летний код в среднем имеет в 3.4 раза меньшую плотность уязвимостей, чем новый код).
| ||
|
Обсуждение (472 +28) |
Тип: Тема для размышления |
| ||
| · | 19.02.2025 | Релиз Mesa 25.0, свободной реализации OpenGL и Vulkan (100 +24) |
|
После трёх месяцев разработки опубликован релиз свободной реализации API OpenGL и Vulkan - Mesa 25.0.0. Первый выпуск ветки Mesa 25.0.0 имеет экспериментальный статус - после проведения окончательной стабилизации кода будет выпущена стабильная версия 25.0.1.
В Mesa 25.0 доступна поддержка графического API Vulkan 1.4 в драйверах ANV для GPU Intel, RADV для GPU AMD, NVK для GPU NVIDIA, Asahi для GPU Apple, Turnip для GPU Qualcomm и в программном растеризаторе lavapipe (lvp). В режиме эмулятора (vn) поддерживается API Vulkan 1.3, в драйвере PanVK для GPU ARM Mali - Vulkan 1.1, а в драйверах v3dv (GPU Broadcom VideoCore для Raspberry Pi 4+) и dzn (реализация Vulkan поверх Direct3D 12) - Vulkan 1.0. В Mesa также обеспечивается полная поддержка OpenGL 4.6 для драйверов iris (GPU Intel Gen 8+), radeonsi (AMD), Crocus (старые GPU Intel Gen4-Gen7), zink, llvmpipe, virgl (виртуальный GPU Virgil3D для QEMU/KVM), freedreno (Qualcomm Adreno), d3d12 (прослойка для организации работы OpenGL поверх DirectX 12) и asahi (GPU AGX, используемый в чипах Apple M1 и M2). Поддержка OpenGL 4.5 доступна для GPU AMD (r600) и NVIDIA (nvc0). Поддержка OpenGL 3.3 присутствует в драйверах softpipe (программный растеризатор) и nv50 (NVIDIA NV50). Основные новшества:
| ||
|
Обсуждение (100 +24) |
Тип: Программы |
| ||
| · | 19.02.2025 | Линус Торвальдс намерен включать связанные с Rust изменения в обход мэйнтейнеров (490 +25) |
|
Кристоф Хелвиг (Christoph Hellwig), мэйнтейнер подсистем DMA, KVM, Slab Allocator и архитектуры PowerPC в ядре Linux, принципиально отказавшийся принимать в ядро Rust-обвязки для подсистемы DMA, подключился к обсуждению правил сопровождения Rust в составе ядра, опубликованных проектом Rust for Linux. По мнению Кристофа подобные правила бесполезны, пока они не согласованы с сообществом и не включены в документацию к ядру.
Кристоф также обратил внимание на то, что в правилах указана некорректная информация относительно того, что мэйнтейнеры могут самостоятельно принимать решения о включении в их подсистемы кода, связанного с Rust. По словам Кристофа, в личной беседе Линус Торвальдс заявил, что он твёрдо намерен принять в ядро Rust-код, несмотря на возражения мэйнтейнеров. Таким образом разработчикам и мэйнтейнерам ядра теперь придётся иметь дело с Rust, независимо от того, хотят они этого или нет. Кристоф также повторно сравнил распространение Rust-обвязок с раковой опухолью, которая расползётся на все подсистемы ядра и приведёт к фрагментации. Из единого целого ядро превращается в проект, написанный на нескольких языках, без чёткого определения того, когда какой язык должен использоваться. По словам Кристофа, работа с подобной смешанной кодовой база стала для него худшим кошмаром, так как в подобных условиях постоянно происходит переписывание кода с одного языка на другой, а затем обратно. При этом Кристоф просит пояснить ему цель внедрения Rust в ядро. Если цель в решении проблем с безопасностью, возникающих при низкоуровневой работе с памятью, то прежде всего требуется модернизация существующего кода. С учётом того, что сопровождающие болезненно реагируют даже на тривиальные вещи, такие как проверки на целочисленное переполнение, непонятно как можно преодолеть разрыв между одной частью ядра, не принимающей даже простые правила по обеспечению безопасности, и другой частью, придерживающейся соблюдения строгих правил. Если же цель в упрощении разработки драйверов, то введение поддержки ещё одного языка только добавит новой работы и увеличит нагрузку на и без того перегруженных людей, поддерживающих инфраструктуру ядра в рабочем состоянии. Что касается сторонников внедрения Rust в ядро, то ими называются следующие цели:
Дополнение 1: Мнение Грега Кроа-Хартмана и Кейса Кука о целях продвижении Rust в ядро Linux. Дополнение 2: Линус Торвальдс пояснил свою позицию в отношении приёма изменений на языке Rust.
| ||
|
Обсуждение (490 +25) |
Тип: К сведению |
| ||
| · | 19.02.2025 | Компания VK передаёт игровой движок Nau Engine на попечение сообщества (78 +8) |
|
Разработчики открытого игрового движка NauEngine, основанного компанией VK, объявили о передаче проекта сообществу. Техническое сопровождение движка вместо VK теперь будет осуществлять Школа разработки видеоигр ИТМО, а экспертную поддержку обеспечит ассоциация АПРИОРИ. В анонсе передача проекта в руки сообщества преподносится как новый этап развития, связанный с переходом от коммерческой модели разработки к модели на основе привлечения независимого сообщества. Репозиторий проекта не обновлялся с момента публикации бета-версии в ноябре.
Судя по комментариям представителей проекта, данным изданию Коммерсант, дальнейшее развитие продукта будет зависить от сообщества, а интеграция с университетом ИТМО позволит развивать движок и обучать студентов разработке, а также использовать его как основу для научно-исследовательских работ. При этом пресс-служба VK заявила, что компания продолжит поддерживать движок, исходя из потребностей его дальнейшего развития. Директор Школы разработки видеоигр ИТМО считает, что в сообществе движок сможет развиваться более эффективно и разнопланово, чем при стандартной коммерческой разработке. По мнению представителей игровой индустрии движок Nau Engine оказался не востребован и все продолжают работать с Unreal Engine и Unity. В качестве основы движка NauEngine используется система рендеринга, построенная с заимствованием компонентов из движка Dagor Engine, открытого осенью прошлого года компанией Gaijin Entertainment. Код из движка Dagor был доработан, особенно в области управления ассетами. Вместо внутреннего языка шейдеров Dagor (dshl) задействован язык HLSL. Добавлена возможность условной компиляции шейдеров для динамического изменения материала поверхности. Переработана реализация техники физически корректного рендеринга (PBR). Для ассетов задействован формат USD (Universal Scene Description). Для симуляции физических процессов задействована библиотека Jolt. Для построения графического интерфейса в играх применён инструментарий Cocos2dx и библиотека Dear ImGui. Сетевое взаимодействие в движке организовано при помощи UDP-транспорта GameNetworkingSockets и библиотеки ASIO. Для работы со звуком используется библиотека miniaudio. Для управления вводом используется библиотека gainput, а для импорта скелетной анимации проект ozz-animation. Для написания игровой логики предлагается использовать языки C++ и Lua, но дополнительно развивается подсистема агностического скриптинга, которая позволит применять различные языки программирования. Вместе с движком развивается среда разработки игр NauEditor, включающая редактор трехмерной сцены, материалов, анимаций и визуальных эффектов (VFX). Интерфейс построен с использованием библиотеки Qt 6 и включает такие компоненты, как Project Browser (Браузер проекта), Viewport (Окно просмотра), Outliner (Структура сцены), Inspector (Инспектор) и Console (Консоль). Отдельно поставляется редактор интерфейса пользователя в играх (GUI Editor), основанный на библиотеке Cocos2dx.
| ||
|
Обсуждение (78 +8) |
Тип: К сведению |
| ||
| · | 19.02.2025 | Компания Valve опубликовала код игры Team Fortress 2 (110 +66) |
|
Компания Valve опубликовала обновлённый инструментарий "Source SDK 2013", предназначенный для создания модов к играм на базе движка Source. Публикация примечательна тем, что в состав пакета включён исходный код игры Team Fortress 2 (как клиентские, так и серверные части). Отмечается, что доступность кода позволит создателям модов не только вносить незначительные изменения и дополнение в существующую игру, но и создавать полностью переработанные варианты Team Fortress 2.
Поддерживается сборка в Linux и Windows. Созданные на основе предложенного кода модификации разрешено публиковать в Steam в форме новых игр. Код распространяется под лицензией SOURCE 1 SDK, допускающей использование, копирование и модификацию, при условии, что результат распространяется бесплатно и не нарушает условия сервиса Steam.
| ||
|
Обсуждение (110 +66) |
Тип: К сведению |
| ||
| · | 18.02.2025 | Обновление OpenSSH 9.9p2 с устранением возможности совершения MITM-атаки (131 +16) |
|
Доступен корректирующий выпуск OpenSSH 9.9p2, в котором устранены две уязвимости, выявленные компанией Qualys. Продемонстрирован пример использования данных уязвимостей для совершения MITM-атаки, позволяющей при попытке подключения клиента к SSH-серверу, перенаправить трафик на собственный фиктивный сервер, обойти проверку хостовых ключей и создать у клиента видимость подключения к желаемому серверу (ssh-клиент примет хостовый ключ фиктивного сервера вместо ключа легитимного сервера).
Первая уязвимость (CVE-2025-26465) вызвана логической ошибкой в утилите ssh, позволяющей обойти проверку идентификации сервера и совершить MITM-атаку. Проблема проявляется начиная с выпуска OpenSSH 6.8p1 (декабрь 2014 г.) в конфигурациях с включённой настройкой VerifyHostKeyDNS. В базовой поставке OpenSSH данная опция по умолчанию отключена, но до марта 2023 года была включена в настройках ssh во FreeBSD. Суть проблемы в том, что в коде функции verify_host_key_callback() при вызове функции verify_host_key() проверяется только код ошибки "-1", а другие коды, такие как "-2", игнорируются. В итоге функция verify_host_key_callback() может вернуть успешный код "0", несмотря на возврат ошибки "-2" функцией verify_host_key(). Код ошибки "-2" возвращается функцией verify_host_key() при нехватке памяти. Если создать условия, которые приведут к невозможности выделить память в функции verify_host_key(), SSH посчитает, что хостовый ключ был проверен успешно. Для создания таких условий подставной SSH-сервер атакующего, на который перенаправлен клиент, возвращает хостовый ключ максимально возможного размера (256KB), и одновременно эксплуатируется утечка памяти на стороне ssh-клиента. Условия для создания утечки памяти достигаются благодаря второй уязвимости (CVE-2025-26466), затрагивающей как клиент ssh, так и сервер sshd, и эксплуатируемая без аутентификации. Уязвимость позволяет исчерпать доступную процессу память и создать высокую нагрузку на CPU через отправку большого числа пакетов SSH2_MSG_PING. В обработчике пакетов SSH2_MSG_PING имеется утечка памяти, проявляющаяся начиная с выпуска OpenSSH 9.5p1 (август 2023 г.). Утечка возникает из-за того, что на каждый поступающий 16-байтовый PING-пакет выделяется 256-байтовый буфер для формирования ответа, но данный буфер освобождается только после завершения согласования ключей. В качестве обходного пути защиты предлагается настроить ограничения при помощи директив LoginGraceTime, MaxStartups и PerSourcePenalties.
| ||
|
Обсуждение (131 +16) |
Тип: Проблемы безопасности |
| ||
| · | 18.02.2025 | Опубликован почтовый сервер Postfix 3.10.0 (60 +13) |
|
После почти года разработки опубликован релиз новой стабильной ветки почтового сервера Postfix - 3.10.0. В то же время объявлено о прекращении поддержки ветки Postfix 3.6, выпущенной в начале 2021 года. Код проекта написан на языке Си и распространяется под лицензиями EPL 2.0 (Eclipse Public license) и IPL 1.0 (IBM Public License).
Postfix является одним из редких проектов, сочетающих одновременно высокую безопасность, надёжность и производительность, чего удалось добиться благодаря многопроцессой архитектуре, изолирующей отдельные обработчики, а также жёсткой политике оформления кода и аудита патчей. Для защиты от ошибок при работе с памятью в проекте используются защищённые варианты функции для выделения и освобождения памяти, а также набор абстрактных функций-обвязок для работы с буферами (проверяется выход за границы буфера и обращения к освобождённой памяти), файловыми операциями, форматирования вывода, буферизированного ввода/вывода и манипуляций со строками (включая возможности для работы со строками произвольного размера и автоматического изменения размера строк). В соответствии с февральским автоматизированным опросом около 550 тысяч почтовых серверов, Postfix используется на 37.64% (год назад 36.81%) почтовых серверов, доля Exim составляет 56.03% (год назад 56.61%), Sendmail - 3.39% (3.60%), MailEnable - 1.80% (1.82%), MDaemon - 0.39% (0.40%), Microsoft Exchange - 0.19% (0.19%), OpenSMTPD - 0.10% (0.09%).  Основные новшества:
| ||
|
Обсуждение (60 +13) |
Тип: Программы |
| ||
| · | 17.02.2025 | Опубликована AI-модель синтеза речи Zonos, поддерживающая клонирование голоса (89 +18) |
|
Компания Zyphra опубликовала под лицензией Apache 2.0 первый бета-выпуск AI-модели для синтеза речи Zonos. Предлагаемый вместе с моделью инструментарий поддерживает функцию клонирования голоса, позволяющую синтезировать речь желаемым голосом, для воспроизведения которого модели достаточно предоставить эталонную запись речи говорящего, продолжительностью 10-30 секунд. Поддерживается синтез на английском, японском, китайском, французском и немецком языках.
Модель охватывает 1.6 млрд параметров и обучена на 200 тысячах часов аудиозаписей. Поддерживается синтез монотонной (как в аудиокнигах) и эмоциональной речи (как в живом разговоре), а также синтез на основе заданного префикса (приводится аудиозапись с началом речи, на основе которой модель синтезирует продолжение по указанному тексту, воспроизводя исходные характеристики речи, например, продолжая говорить шёпотом). На выходе генерируется звук с частотой дискретизации 44kHz. Поддерживается подстановка синтезируемых вставок для симуляции выступлений с несколькими говорящими или построения интерактивных диалогов, а также добавление меток для управления скоростью речи, тональностью и выражением эмоций, таких как радость, страх, печаль и гнев. По заявлению разработчиков, по качеству генерируемой речи модель не уступает или превосходит все публично доступные открытые и коммерческие системы синтеза (в тестах приводится сравнение с ElevenLabs, Cartesia и FishSpeech). Из недостатков отмечается более высокая концентрация звуковых артефактов, таких как кашель, звук дыхания или скрипы, в начале или в конце формируемого звукового материала.
Для использования модели на своей системе подготовлен готовый к работе образ для системы Docker, в состав которого входит web-интерфейс для управления синтезом, основанный на платформе Gradio. Для начала работы достаточно установить образ командой "git clone https://github.com/Zyphra/Zonos.git; cd Zonos; docker compose up" и открыть в браузере страницу "http://localhost:7860". Для работы рекомендуется наличие GPU NVIDIA как минимум серии 3000 с 6 Гб видеопамяти. Производительность работы на системе с GPU RTX 4090 в два раза превышает возможности, необходимые для синтеза в режиме реального времени. 
| ||
|
Обсуждение (89 +18) |
Тип: К сведению |
| ||
| · | 16.02.2025 | В PostgreSQL устранена уязвимость, использованная при атаке на BeyondTrust (23 +16 ↻) |
|
Сформированы корректирующие обновления для всех поддерживаемых веток PostgreSQL 17.3, 16.7, 15.11, 14.16 и 13.19, в которых исправлено более 70 ошибок и устранена уязвимость (CVE-2025-1094), в конце декабря задействованная в атаке на компанию BeyondTrust и Министерство финансов США. Проблема в PostgreSQL выявлена при анализе удалённой уязвимости (CVE-2024-12356) в сервисах BeyondTrust PRA (Privileged Remote Access) и BeyondTrust RS (Remote Support), при эксплуатации которой дополнительно была задействована ранее неизвестная (0-day) уязвимость в libpq.
В результате атаки злоумышленникам удалось получить ключ для доступа к API, применяемому для удалённого оказания услуг технической поддержки клиентам SaaS-сервисов BeyondTrust. Данный API был использован для сброса пароля и компрометации инфраструктуры Министерства финансов США, пользующегося продуктами BeyondTrust. В ходе атаки злоумышленники смогли загрузить конфиденциальные документы и получили доступ к рабочим станциям сотрудников министерства. Уязвимость проявляется в библиотеке libpq, предоставляющей API для взаимодействия с СУБД из программ на языке Си (поверх библиотеки также реализованы библиотеки-обвязки для C++, Perl, PHP и Python). Проблема затрагивает приложения, использующие для экранирования спецсимволов и нейтрализации кавычек функции PQescapeLiteral(), PQescapeIdentifier(), PQescapeString() или PQescapeStringConn(). Атакующий может добиться подстановки своего SQL-кода, если получаемый извне текст перед использованием внутри SQL-запроса экранируется при помощи вышеотмеченных функций libpq. В приложениях BeyondTrust экранированные подобным образом запросы передавались через утилиту командной строки psql. Уязвимость вызвана отсутствием проверки корректности Unicode-символов в функциях экранирования, что позволяет обойти нормализацию кавычек через указание некорректных многобайтовых последовательностей UTF-8. Для эксплуатации уязвимость можно использовать некорректный UTF-8 символ, состоящий из байт 0xC0 и 0x27 ("└'"). Байт 0x27 в ASCII-кодировке соответствует одинарной кавычке ("'"), подлежащей экранированию. В коде экранирования сочетание байтов 0xC0 и 0x27 обрабатывается как один Unicode-символ. Соответственно, байт 0x27 в такой последовательности остаётся не экранирован, при том, что при обработке SQL-запроса в утилите psql он обрабатывается как кавычка. При запуске SQL-запросов при помощи утилиты psql для организации выполнения произвольного кода можно использовать подстановку в строку команды "\!", предназначенной в psql для запуска произвольных программ. Например, для запуска на сервере утилиты "id" можно передать значение "hax\xC0'; \! id #". В примере ниже для экранирования вызывается PHP-скрипт dbquote, использующий PHP-функцию pg_escape_string, работающую поверх функции PQescapeString из libpq: $ echo -e "hello \xC0'world'" | ./dbquote 'hello └'world''' $ quoted=$(echo -e "hax\xC0'; \! id # " | ./dbquote) $ echo "SELECT COUNT(1) FROM gw_sessions WHERE session_key = $quoted AND session_type = 'sdcust' AND (expiration IS NULL OR expiration>NOW())" | psql -e SELECT COUNT(1) FROM gw_sessions WHERE session_key = 'hax└'; ERROR: invalid byte sequence for encoding "UTF8": 0xc0 0x27 uid=1000(myexamplecompany) gid=1000(myexamplecompany) Дополнение: Внесённое в libpq исправление привело к появлению регрессии (функция PQescapeIdentifier перестала учитывать поле с размером). Для устранения регрессии 20 февраля планируют опубликовать внеплановое обновление.
| ||
|
Обсуждение (23 +16 ↻) |
Тип: Проблемы безопасности |
| ||
| Следующая страница (раньше) >> | ||
