| · | 25.10 | Компания Valve опубликовала дистрибутив для игровых консолей SteamOS 3.9 (11 +1) |
|
Компания Valve представила выпуск операционной системы SteamOS 3.9.5, который отмечен как первый стабильный выпуск в ветке 3.9. Операционная система SteamOS поставляется в устройствах Steam Deck и с недавних пор используется в игровых консолях некоторых других производителей, таких как Lenovo Legion Go S и ASUS ROG Ally. Для установки следует выставить канал "Steam Deck Preview" в настройках обновления "Settings > System > System Update Channel". В прошлом энтузиастами развивались неофициальные сборки HoloISO и SteamFork, но они находятся в заброшенном состоянии.
Платформа основана на Arch Linux, использует для ускорения запуска игр композитный сервер Gamescope на базе протокола Wayland, поставляется с доступной только на чтение корневой ФС, применяет атомарный механизм установки обновлений, поддерживает пакеты Flatpak, использует мультимедийный сервер PipeWire и предоставляет два режима работы интерфейса (оболочка Steam и рабочий стол KDE Plasma). Среди изменений:
| ||
|
Обсуждение (11 +1) |
Тип: Программы |
| ||
| · | 25.10 | YouTube добавит поддержку AV2 в начале 2027 года, Intel готовит SVT-AV2 (9 +1) |
|
Альянс Open Media (AOMedia) объявил об успехах продвижения видеокодека AV2, не требующего патентных и лицензионных отчислений, обеспечивающего примерно на 30% большую эффективность сжатия по сравнению с AV1 и поддерживающего расширенные возможности для потокового вещания, отдачи видео по запросу (VOD), применения в видеоконференциях и интерактивных системах. YouTube планирует начать вещание в AV2 в начале 2027 года, первое время только при просмотре через Web. Также отмечается, что по состоянию на март этого года 90% контента в YouTube доступно в формате AV1. Google проводит внутреннее тестирование экспериментальных сборок Chrome с поддержкой AV2, но пока не перенёс изменения в официальные нестабильные сборки. Появление поддержки AV2 в Chrome ожидается до начала вещания в данном формате в YouTube.
Компания Intel ведёт разработку библиотеки SVT-AV2 (Scalable Video Technology AV2) c реализациями кодировщика и декодировщика AV2, ускоренными при помощи процессорных расширений для аппаратного распараллеливания вычислений. Компания Meta намерена задействовать AV2 для распространения видео на Facebook и Instagram, как когда-то было сделано с кодеком AV1, а также проявляет интерес к открытым звуковым кодекам OAC (Open Audio Codec) и OAR (Open Audio Renderer).
| ||
|
Обсуждение (9 +1) |
Тип: К сведению |
| ||
| · | 24.10 | Выпуск системы шифрования дисковых разделов VeraCrypt 1.26.30 (28 +5) |
|
Опубликован выпуск проекта VeraCrypt 1.26.30, развивающего форк системы шифрования дисковых разделов TrueCrypt, прекратившей своё существование. VeraCrypt примечателен заменой используемого в TrueCrypt алгоритма RIPEMD-160 на SHA-512 и SHA-256, увеличением числа итераций хэширования, упрощением процесса сборки для Linux и macOS, устранением проблем, выявленных в процессе аудита исходных текстов TrueCrypt. Разработанный проектом VeraCrypt код распространяется под лицензией Apache 2.0, а заимствования из TrueCrypt продолжают поставляться под лицензией TrueCrypt License 3.0. Готовые сборки формируются для Linux, FreeBSD, Windows и macOS.
Среди изменений в новой версии:
| ||
|
Обсуждение (28 +5) |
Тип: Программы |
| ||
| · | 24.10 | В systemd добавлена возможность разработки компонентов на языке Rust (40 +7) |
|
В кодовую базу системного менеджера systemd принято изменение, добавляющее возможность создания компонентов на языке Rust. Rust намерены использовать только для разработки новых компонентов, а существующий код на языке Си переписывать на Rust не планируют. Пакетный менеджер cargo в процессе сборки не применяется, остаётся задействована только сборочная система Meson. Rust-код используется в режиме "no_std" (без стандартной библиотеки), разрешено использовать только библиотеки core, alloc и libc.
Компоненты systemd на Rust динамически связываются с Си-библиотекой libsystemd-shared. Rust-обвязки над libsystemd-shared генерируются автоматически на этапе сборки из заголовочных файлов при помощи утилиты bindgen, и становятся доступны для rust-программ в форме пакета systemd_shared. Для работы требуется как минимум версии rustc 1.85 и bindgen 0.71.1, соответствующие версиям из Debian 13. Тестовый исполняемый файл на Rust при сборке с LTO-оптимизациями занимает 32 КБ, при том что аналог на Си занимает 20 КБ. По умолчанию поддержка Rust включается только при наличии в системе соответствующего Rust-инструментария (-Drust=auto). В качестве первого компонента, написанного на Rust, развивается systemd-keyring-setup, который пока не принят в основную кодовую базу systemd. Systemd-keyring-setup предназначен для настройки и управления X.509-сертификатами для механизмов ядра Linux dm-verity, fs-verity и bpf.
| ||
|
Обсуждение (40 +7) |
Тип: К сведению |
| ||
| · | 24.10 | Критическая уязвимость в декодировщике Brotli, затрагивающая Node.JS, Bun, браузеры, HTTP-клиенты и другие проекты (136 +11) |
|
В библиотеке с эталонной реализацией декодировщика формата сжатия данных Brotli выявлена уязвимость (CVE-2026-111497, кодовые имена Broccoli2Shell и HTTP2Shell), приводящая к переполнению буфера при обработке специально оформленных сжатых данных. По данным Google уязвимость может использоваться для удалённого выполнения кода при атаке на проекты, использующие официальную реализацию декодировщика Brotli. Среди затрагиваемых уязвимостью проектов: Node.js, Bun, Envoy, Istio, web-браузеры, прокси-серверы, HTTP-клиенты, HTTP-серверы, архиваторы, прокси-серверы, UEFI-прошивки, просмотрщики JPEG XL, декодирующие контент библиотеки для Python, Ruby, Java, PHP и .NET и связанные с ними зависимости.
Проблема была выявлена компанией OpenAI в феврале этого года и блокирована в кодовой базе Brotli через отбрасывание некорректных потоков при декодировании. 22 октября были опубликованы корректирующие выпуски Brotli 1.0.10, 1.1.1 и 1.2.1 в которых явно было заявлено об устранении уязвимости и исправлена суть проблемы. В этот же день был создан прототип эксплоита, позволивший удалённо выполнить код в лабораторных условиях, при использовании нестандартных сборок (в стандартных сборках происходило аварийное завершение). Позднее компания Imperva зафиксировала атаку на штатные сборки Node.js 24.22.0 в Linux-окружении на системе ARM64. Уязвимость приводит к записи за пределы буфера из-за некорректной обработки ошибок в процессе разбора блоков в сжатом потоке. Функция DecodeBlockTypeAndLength() вместо кода ошибки возвращала только значения true и false, что не позволяло вызывающему коду отличить повреждение потока от состояния, требующего передачи в функцию дополнительных данных. В случае указания в потоке некорректного типа блока сжатых данных, декодировщик воспринимал его не как ошибку, а как состояние нехватки данных, требующее дополнительного чтения из потока. Но так как выделенный буфер не был рассчитан на дополнительно прочитанные данные, они записывались в область за его пределами, в которой хранилось внутреннее состояние декодировщика. Подверженные уязвимости проекты:
| ||
|
Обсуждение (136 +11) |
Тип: Проблемы безопасности |
Интересно
| ||
| · | 24.10 | Выпуск системы потокового видеовещания OBS Studio 33.0 (44 +16) |
|
Опубликован выпуск OBS Studio 33.0, пакета для потокового вещания, композитинга и записи видео. Код написан на языках C/C++ и распространяется под лицензией GPLv2. Сборки сформированы для Linux (flatpak), Windows и macOS.
Целью разработки OBS Studio было создание переносимого варианта приложения Open Broadcaster Software (OBS Classic), не привязанного к платформе Windows, поддерживающего OpenGL и расширяемого через плагины. Отличием также является использование модульной архитектуры, подразумевающей разделение интерфейса и ядра программы. Поддерживается перекодирование исходных потоков, захват видео во время игр и стриминг в PeerTube, Twitch, Facebook Gaming, YouTube, DailyMotion и другие сервисы. Для обеспечения высокой производительности возможно использование механизмов аппаратного ускорения (например, NVENC, Intel QSV, Apple Video Toolbox и VAAPI). Предоставляется поддержка композитинга с построением сцены на основе произвольных видеопотоков, данных с web-камер, карт захвата видео, изображений, текста, содержимого окон приложений или всего экрана. В процессе вещания допускается переключение между несколькими предопределёнными вариантами сцен (например, для переключения представлений с акцентом на содержимое экрана и изображение с web-камеры). Программа также предоставляет инструменты для микширования звука, фильтрации при помощи VST-плагинов, выравнивая громкости и подавления шумов. Ключевые изменения:
| ||
|
Обсуждение (44 +16) |
Тип: Программы |
| ||
| · | 23.10 | Ещё одна уязвимость в PHP, в редких конфигурациях позволяющая удалённо выполнить код (149 +25) |
|
Разработчики проекта PHP предупредили о выявлении ещё одной уязвимости (CVE-2026-115560), которая потенциально может использоваться для удалённого выполнения кода на сервере при определённом редком сочетании нестандартных настроек (не в конфигурации по умолчанию) и выполняемого PHP-кода. Подробности о уязвимости намерены опубликовать после готовности очередных корректирующих выпусков PHP.
В качестве обходного пути защиты рекомендуется выставить в php.ini параметр "session.upload_progress.enabled=0", который также был рекомендован в качестве одной из мер блокирования прошлой критической уязвимости. Проблема проявляется при наличии в настройках параметра "session.serialize_handler", выставленного в значение "php_binary" или "php_serialize", и изменения этого парамтера в PHP-коде на значение "php" через функцию "ini_set()" на стадии до вызова функции session_start().
| ||
|
Обсуждение (149 +25) |
Тип: Проблемы безопасности |
| ||
| · | 23.10 | Выпуск криптографических библиотек OpenSSL 4.1.0 и LibreSSL 4.4.0 (26 +10) |
Опубликован релиз библиотеки OpenSSL 4.1.0, предлагающей с реализацию протоколов TLS и различных алгоритмов шифрования. OpenSSL 4.1 отнесён к выпускам с обычным сроком поддержки, обновления для которых выпускаются в течение 13 месяцев. Поддержка LTS-ветки OpenSSL 3.5 продлится до апреля 2030 года. Код проекта распространяется под лицензией Apache 2.0.
Дополнительно можно отметить выпуск переносимой редакции пакета LibreSSL 4.4.0, развивающего форк OpenSSL. Выпуск LibreSSL 4.4.0 рассматривается как экспериментальный, в котором развиваются возможности, которые войдут в состав OpenBSD 8.1. Изменения в новой версии LibreSSL в основном связаны с исправлением ошибок, оптимизациями и решением проблем совместимости с OpenSSL. Значительно улучшена поддержка платформы Windows и добавлена поддержка сборки для macOS 27.0. Включены ассемблерные оптимизации для MIPS32 и MIPS64. Повышена производительность SHA-3.
| ||
|
Обсуждение (26 +10) |
Тип: Программы |
| ||
| · | 23.10 | Около 10% выходных узлов Tor были вовлечены в атаку по перехвату SSH-подключений (70 +22) |
|
Опубликованы детали инцидента, в ходе которого злоумышленникам удалось получить контроль над 333 выходными узлами сети Tor (всего в Tor около 3000 выходных узлов) и организовать на них перехват нешифрованного трафика и перенаправление SSH-соединений. Атака началась 2 октября (в пятницу вечером), но была выявлена и начала блокироваться 4 октября. 5 октября все скомпрометированные серверы были отключены операторами или самими атакующими. Разбирательство показало, что атакующие получили доступ к серверам за два месяца до начала атаки на пользователей Tor и установили в скомпрометированных системах вредоносное ПО Ebury 1.8.3.
Целью атаки был перехват паролей, ключей и конфиденциальной информации в транзитном незашифрованном трафике, а также захват паролей к SSH. При анализе незашифрованного трафика атакующие сосредоточились на обращениях без шифрования к почтовым серверам. Для стимулирования отката на работу без шифрования на выходных узлах было произведено блокирование сетевых портов, применяемых для организации шифрованного канала связи с почтовыми серверами. Нешифрованный трафик анализировался на лету. Для сбора паролей к SSH было организовано перенаправление SSH-запросов на один из 12 серверов злоумышленников. Данные серверы принимали соединение по SSH и выводили запрос пароля от имени сервера, к которому осуществлялось подключение. Так как хостовые ключи не совпадали, ssh на стороне клиента выдавал предупреждение о подключении к неизвестному серверу. Если пользователь игнорировал данное предупреждение и вводил пароль для подключения, то вредоносный сервер транслировал через себя подключение к легитимному целевому SSH-серверу, сохранял введённый жертвой пароль и перехватывал информацию о действиях в SSH-сеансе. Параллельно осуществлялось подключение к целевому серверу с захваченным паролем и установка на него вредоносного ПО Ebury. Получая контроль над Linux-серверами, не являющимися выходными узлами Tor, атакующие меняли настройки в файле torrc и превращали их новые вредоносные выходные узлы Tor.  Для определения всех вредоносных выходных узлов выявивший проблему исследователь использовал утилиту exitmap для перебора всех выходных узлов, установки SSH-соединения через каждый из них и проверки факта перенаправления запроса. Как именно атакующие получили доступ к захваченным Tor-узлам пока не ясно, среди прочего высказываются предположения о компрометации операторов хостинга.
| ||
|
Обсуждение (70 +22) |
Тип: Проблемы безопасности |
| ||
| · | 23.10 | Аnthropic развивает технику для формальной верификации существующего ПО при помощи AI (213 +7) |
|
Компания Аnthropic представила результаты экспериментов по использованию AI-моделей для формальной верификации надёжности и безопасности уже существующих проектов. В ходе эксперимента при помощи AI-моделей для 123 открытых библиотек, протестированных в инфраструктуре OSS Fuzz, были сгенерированы математические доказательства отсутствия ошибок при работе с памятью.
Проверка проводилась на уровне скомпилированного ассемблерного кода для архитектуры RISC-V. Общий объём сгенерированных доказательств составил около 180 миллионов строк кода для системы верификации Rocq Prover (около 600 тысяч строк на бинарный файл с 18 тысячами RISC-V инструкций). Доказательства формировались путём автоматического преобразования существующих fuzzing-тестов в формальные спецификации, после чего AI-модель Claude доказывала, что при любых входных данных объёмом до 64 МБ в программе не возникает сбоев. В процессе построения доказательств AI-модель смогла выявить и подготовить исправления для сотен ошибок, ранее не замеченных при fuzzing-тестировании. Среди прочего, были выявлены уязвимости, приводящие к переполнению буфера при обработке определённых входных данных (например, CVE-2026-56132 в libexpat), а также логические ошибки. Помимо этого, AI-модель была использована для доказательства соответствия реализации алгоритма zlib в ядре Linux спецификации RFC 1950. Также на языке Rust был сгенерирован интерпретатор для подмножества языка Python, для которого при помощи инструментария Verus подготовлено формальное доказательство соответствия семантике CPython. Для сравнения поведения с CPython было выполнено более 1.7 миллионов случайно сгенерированных Python-программ. В 99.95% случаев результаты выполнения этих программ в новой реализации и в CPython совпали, а выявленные расхождения оказались известными граничными случаями. Проведённая формальная верификация гарантирует соответствие спецификации, но полностью не исключает возникновение проблем с безопасностью, так как остаются неформализованными риски, вызванные проблемами с многопоточностью, динамическим связыванием и аномальным поведением реального оборудования. Ключевым преимуществом предложенного подхода является работа непосредственно с бинарными файлами, что позволяет обойтись без необходимости переписывания существующего кода на формально верифицируемых языках.
| ||
|
Обсуждение (213 +7) |
Тип: К сведению |
| ||
| · | 23.10 | Для уязвимостей PHP2Shell анонсирован первый эксплоит, обходящий рандомизацию адресов (66 +15) |
|
Исследователи из компании VulnCheck заявили о получении первого эксплоита для уязвимости PHP2Shell (CVE-2026-109618б), обходящего механизм рандомизации адресов (ASLR) на системах x86-64 с типовой конфигурацией PHP. Эксплоит позволяет атаковать системы с PHP 8.4.10-8.4.26 в конфигурации по умолчанию. Ранее трудность определения раскладки памяти в модуле mod_php мешала реализации эксплоита, позволяющего добиться выполнения кода на реальных системах. Для обхода ASLR в эксплоите задействована утечка информации об адресах в коде отображения информации об ошибках.
Заявлено, что доступ к рабочему эксплоиту предоставлен только клиентам, занимающимся защитой информации, но злоумышленники могут воссоздать используемую технику при помощи AI. Для обходного пути блокирования утечки информации о раскладке адресов следует выставить в php.ini параметр "display_errors=off", помимо ранее опубликованных рекомендаций. VulnCheck также упоминает о том, что на GitHub появились сотни прототипов эксплоитов, но только единицы оценены как рабочие и лишь один прототип был способен обойти ASLR. Помимо этого, директор Cloudflare сообщил, что компания фиксирует миллионы попыток эксплуатации уязвимостией PHP2Shell, при том, что за 10 часов до анонса наличия уязвимостей таких попыток уже были тысячи, а через 2 часа после официального раскрытия информации достигли сотен тысяч. Судя по всему, в атаках используются прототипы эксплоитов, лишь фиксирующие наличие уязвимых версий PHP, так как пока нет информации о подтверждённых фактах взлома через уязвимости PHP2Shell. По данным компании Amazon первые попытки эксплуатации зафиксированы развёрнутыми honeypot-системами ещё 17 октября, т.е. за 3 дня до утечки первых сведений об CVE-идентификаторах. Активность усилилась 21 октября, за 12 часов до публикации корректирующих обновлений PHP, в это время зафиксированы попытки атак с использованием нескольких вариантов прототипов эксплоитов. Попытки атак до официального раскрытия информации также зафиксировала компания Hadrian.
| ||
|
Обсуждение (66 +15) |
Тип: Проблемы безопасности |
| ||
| · | 22.10 | Релиз менеджера паролей KeePassXC 2.8 (235 +36) |
|
Опубликован выпуск открытого кроссплатформенного менеджера паролей KeePassXC 2.8.0, предоставляющего средства для безопасного хранения обычных паролей, одноразовых паролей (TOTP), SSH-ключей и прочей информации, которую пользователь считает конфиденциальной. Данные могут храниться как в локальном зашифрованном хранилище, так и во внешних облачных хранилищах. Код проекта написан на языке C++ с использованием библиотеки Qt и распространяется под лицензиями GPLv2 и GPLv3. Готовые сборки подготовлены для Linux (AppImage, Flatpak, Ubuntu PPA, Snap), Windows и macOS.
Основные возможности:
 Ключевые изменения в новом выпуске:
| ||
|
Обсуждение (235 +36) |
Тип: Программы |
| ||
| · | 22.10 | Опубликован сетевой стек F-Stack 2.0, работающий в пользовательском пространстве (68 +16) |
|
Состоялся релиз проекта F-Stack 2.0, развивающего редакцию сетевого стека FreeBSD, адаптированную для обособленной работы в пользовательском пространстве в форме библиотеки. Проект создан крупнейшей в Китае телекоммуникационной компанией Tencent и используется в её продуктах и сервисах. Код написан на языке Си и распространяется под лицензией BSD. Поддерживается работа в Linux и FreeBSD. Проектом также поддерживаются переведённые на использование F-Stack редакции Nginx 1.28 и СУБД Redis 6.2.6, демонстрирующие производительность выше обычных сборок, работающих поверх системного сетевого стека.
F-Stack позволяет задействовать в приложениях собственный локальный сетевой стек, не зависящий от сетевого стека операционной системы, функционирующий в пользовательском пространстве и напрямую работающий с сетевым оборудованием. F-Stack позиционируется как решение, позволяющее повысить производительность обработчиков сетевых запросов в условиях, когда штатный TCP/IP стек ядра Linux становится узким местом и ограничивает масштабирование. Теоретически F-Stack позволяет достигнуть потолка сетевой производительности, возможного для используемой сетевой карты, и в некоторых ситуациях даёт возможность в разы увеличить число обрабатываемых мелких сетевых запросов. Повышение производительности достигается за счёт исключения таких операций, как копирования сетевых пакетов, планирование потоков, обработка прерываний и обращение к системным вызовам. Для взаимодействия с сетевой картой, минуя интерфейсы ядра операционной системы, применяется фреймворк DPDK (Data Plane Development Kit), развивающий набор библиотек для низкоуровневой работы с сетевыми адаптерами. DPDK даёт возможность снизить накладные расходы и уложиться в минимальное число циклов CPU при приёме или отправке сетевых пакетов. Функциональность стека TCP/IP соответствует сетевому стеку FreeBSD 15 и выделена из данной операционной системы в независимую библиотеку. Для разработки приложений можно использовать стандартный API POSIX (socket, epoll, kqueue) или собственный программный интерфейс на основе микропотоков, упрощающий создание сетевых приложений и позволяющий обойтись без сложной логики асинхронной обработки запросов. Возможно использование с немодифицированными приложениями с загрузкой через LD_PRELOAD. Наиболее заметные изменения в новом выпуске:
| ||
|
Обсуждение (68 +16) |
Тип: Программы |
| ||
| · | 22.10 | В PyPI-пакет и Docker-образ с LiteLLM подставлено вредоносное ПО (30 +14) |
|
Зафиксирована публикация в репозитории PyPI вредоносного выпуска библиотеки LiteLLM, насчитывающей 23 млн загрузок в неделю, а также подстановка вредоносного кода в официальный Docker-образ проекта. Это не первый подобный инцидент с LiteLLM - в марте этого года атакующие уже публиковали вредоносные выпуски после перехвата учётных данных сопровождающего. На этот раз атакующие разместили версию LiteLLM 1.107.0, в которую был встроен вредоносный код для организации удалённого выполнения команд, а также поиска и отправки учётных данных, ключей и токенов доступа.
Вредоносный код был подставлен на этапе сборочного процесса без компрометации git-репозитория. После установки вредоносный код активируется до импорта LiteLLM через установку файлов cook.pth, cook.py и sitecustomize.py в директорию с библиотеками Python. Данные файлы запускаются при каждом выполнении Python в системе без необходимости совершения пользователем каких-либо действий. Вначале Python запускает файл cook.pth, в котором имеется только одна строка "import cook" для импорта скрипта cook.py, собирающего учётные данные. Далее импортируется скрипт sitecustomize.py, применяемый для фоновой загрузки внешнего кода (параметры загрузки определяются по ссылке "raw.githubusercontent.com/letters9813/pythonclient-test/main/domain.txt"). Вредоносный код в обоих скриптах сжат через zlib и закодирован методом Base64. Индикатором компрометации может служить появление в системе файлов "/tmp/.pc_once_*" и "/tmp/remote_code_loader.lock". После активации файл cook.py выполняет сканирование параметров подключения к облачным сервисам, репозиториям и системам непрерывной интеграции (AWS, Azure, Google Cloud, Kubernetes, Docker, GitHub CLI, Vault, Terraform, Packer), учётных записей разработчиков, параметров подключения к Git, настроек npm и PyPI, файлов с переменными окружения, закрытых ключей для SSH, PGP и TLS, настроек AI-инструментов, браузерных БД c Cookie, хранимыми данными и историей, информации о процессах и переменных окружения. Обнаруженные данные шифруются с использованием алгоритмов AES-256-CBC + RSA-4096 и отправляются в форме проверочного запроса на сайт litellm.dev, созданный злоумышленниками.
| ||
|
Обсуждение (30 +14) |
Тип: Проблемы безопасности |
| ||
| · | 22.10 | Проблемные корневые сертификаты eMudhra были сгенерированы в HSM и прошли независимый аудит (166 +41) |
|
Компания eMudhra опубликовала заявление, связанное с инцидентом, в результате которого у восьми корневых сертификатов удостоверяющего центра оказались легко подбираемые закрытые ключи, имеющие всего 1 байт энтропии вместо 48. eMudhra утверждает, что сертификаты были сгенерированы в апреле 2025 года на публичной церемонии с использованием аппаратных модулей HSM (Hardware Security Module), имеющих сертификат соответствия требованиям FIPS 140-2 Level 3.
В процессе генерации ключей произошёл сбой, из-за которого на этапе упаковки/распаковки в HSM (wrap/unwrap, шифрование и расшифровка ключом-обёрткой) в дополнение к основному набору криптостойких ключей был создан второй набор слабых ключей с обнулёнными старшими байтами, который и был задействован в сертификатах. Сбой не был распознан, так как закрытые ключи создаются и хранятся только в HSM и не попадают в открытом виде за его пределы. Причина произошедшего сбоя пока не ясна и компания проводит связанное с этим расследование. Утверждается, что проблемные корневые сертификаты, созданные с использованием слабых ключей, прошли независимый аудит и два года оставались в списке доверенных во всех хранилищах корневых сертификатов. Дополнение: Компания eMudhra объявила о прекращении деятельности удостоверяющего центра и сосредоточении бизнеса на разработке корпоративных решений и сервисах, связанных с обеспечением безопасности. Отмечается, что связанная с TLS-сертификатами деятельность приносила около 1% от общей выручки компании.
| ||
|
Обсуждение (166 +41) |
Тип: Проблемы безопасности |
| ||
| Следующая страница (раньше) >> | ||
