Объявлено о готовности системы криптографической верификации кода Sigstore

Компания Google сообщила о формировании первых стабильных выпусков компонентов, образующих проект Sigstore, который объявлен пригодным для создания рабочих внедрений. Sigstore развивает инструменты и сервисы для верификации программного обеспечения при помощи цифровых подписей и ведения публичного лога, подтверждающего подлинность изменений (transparency log). Проект развивается под эгидой некоммерческой организации Linux Foundation компаниями Google, Red Hat, Cisco, vmWare, GitHub и HP Enterprise при участии организации OpenSSF (Open Source Security Foundation) и университета Пердью.

Sigstore можно рассматривать как аналог Let’s Encrypt для кода, предоставляющий сертификаты для заверения кода цифровыми подписями и инструментарий для автоматизации проверки. При помощи Sigstore разработчики смогут формировать цифровые подписи для связанных с приложением артефактов, таких как файлы с релизами, образы контейнеров, манифесты и исполняемые файлы. Используемый для подписи материал отражается в защищённом от внесения изменений публичном логе, который можно использовать для проверки и аудита.

Вместо постоянных ключей в Sigstore применяются короткоживущие эфемерные ключи, которые генерируются на основе полномочий, подтверждённых провайдерами OpenID Connect (в момент генерации ключей, необходимых для создания цифровой подписи, разработчик идентифицирует себя через провайдера OpenID с привязкой к email). Подлинность ключей проверяется по публичному централизованному логу, который позволяет убедиться, что автор подписи именно тот, за кого себя выдаёт, и подпись сформирована тем же участником, что отвечал за прошлые релизы.

Готовность Sigstore к внедрению обусловлена формированием релизов двух ключевых компонентов - Rekor 1.0 и Fulcio 1.0, программные интерфейсы которых объявлены стабильными и впредь сохраняющими обратную совместимость. Компоненты сервиса написаны на языке Go и распространяются под лицензией Apache 2.0.

Компонент Rekor содержит реализацию лога для хранения заверенных цифровыми подписями метаданных, отражающих информацию о проектах. Для обеспечения целостности и защиты от искажения данных задним числом применяется древовидная структура "дерево Меркла" (Merkle Tree), в которой каждая ветка верифицирует все нижележащие ветки и узлы благодаря совместному (древовидному) хешированию. Имея конечный хеш, пользователь может удостовериться в корректности всей истории операций, а также в корректности прошлых состояний БД (корневой проверочный хеш нового состояния базы вычисляется с учётом прошлого состояния). Для верификации и добавления новых записей предоставляется RESTful API, а также интерфейс командной строки.

Компонент Fulcio (SigStore WebPKI) включает систему для создания удостоверяющих центров (root CA), выдающих короткоживущие сертификаты на основе email, аутентифицированного через OpenID Connect. Время жизни сертификата составляет 20 минут, за которые разработчик должен успеть сформировать цифровую подпись (если в дальнейшем сертификат попадёт к руки злоумышленника, то он уже будет просрочен). Дополнительно проектом развивается инструментарий Сosign (Container Signing), предназначенный для формирования подписей к контейнерам, проверки подписей и размещения подписанных контейнеров в репозиториях, совместимых с OCI (Open Container Initiative).

Внедрение Sigstore даёт возможность повысить безопасность каналов распространения программ и защититься от атак, нацеленных на подмену библиотек и зависимостей (supply chain). Одной из ключевых проблем с безопасностью в открытом ПО является сложность проверки источника получения программы и верификации процесса сборки. Например, для проверки целостности релиза большинство проектов используют хеши, но часто необходимая для проверки подлинности информация хранится на незащищенных системах и в общих репозиториях с кодом, в результате компрометации которых атакующие могут подменить необходимые для верификации файлы и, не вызывая подозрений, внедрить вредоносные изменения.

Применение цифровых подписей для верификации релизов пока не получило повсеместного распространения из-за сложностей в управлении ключами, распространении открытых ключей и отзыве скомпрометированных ключей. Для того, чтобы верификация имела смысл дополнительно требуется организовать надёжный и безопасный процесс распространения открытых ключей и контрольных сумм. Даже при наличии цифровой подписи многие пользователи игнорируют проверку, так как необходимо потратить время на изучение процесса верификации и понять, какой ключ заслуживает доверия. Проект Sigstore пытается упросить и автоматизировать эти процессы, предоставив готовое и проверенное решение.

Источник: https://www.opennet.ru/opennews/art.shtml?num=57979

Уязвимости в Samba, приводящие к переполнению буфера и выходу за границу базового каталога

Опубликованы корректирующие выпуски пакета Samba 4.17.2, 4.16.6 и 4.15.11 с устранением двух уязвимостей. Выпуск обновлений пакетов в дистрибутивах можно проследить на страницах: Debian, Ubuntu, Gentoo, RHEL, SUSE, Arch, FreeBSD.

• CVE-2022-3437 - переполнение буфера в функциях unwrap_des() и unwrap_des3(), предоставляемых в библиотеке GSSAPI из пакета Heimdal (поставляется в составе Samba, начиная с версии 4.0). Эксплуатация уязвимости возможна через отправку специально оформленного пакета на системы, в которых используется GSSAPI. Например проблема проявляется в реализации клиента и файлового сервера на базе протокола SMB1, при применении DCE/RPC и в контроллере домена Active Directory. Системы собранные с MIT Kerberos (--with-system-mitkrb5) вместо Heimdal проблеме не подвержены.
• CVE-2022-3592 - возможность выхода за границы экспортируемого каталога и доступа к любому файлу на сервере через манипуляции с символическими ссылками. Проблема проявляется только в ветке Samba 4.17 и вызвана ошибкой в новом коде для обработки символических ссылок в пространстве пользователя (в коде отсутствовала проверка нахождения целевого каталога ссылки за границей экспортируемого каталога). Уязвимость может быть эксплуатирована клиентом, имеющим доступ на запись в экспортируемый раздел, предоставляемый через протоколы SMB1 или NFS, допускающие создание символических ссылок.

Источник: https://www.opennet.ru/opennews/art.shtml?num=57978

Опубликован черновик третьей редакции формата PNG

Консорциум W3C опубликовал черновой вариант третьей редакции спецификации, стандартизирующей формат упаковки изображений PNG. Новый вариант полностью обратно совместим со второй редакцией спецификации PNG, выпущенной в 2003 году, и отличается включением таких дополнительных возможностей, как поддержка анимированных изображений, возможность интеграции метаданных EXIF и поставка свойств CICP (Coding-Independent Code Points) для определения цветовых пространств (в том числе цветовых пространств для HDR).

Источник: https://www.opennet.ru/opennews/art.shtml?num=57977

Выпуск Brython 3.11, реализации языка Python для web-браузеров

Представлен релиз проекта Brython 3.11 (Browser Python) с реализацией языка программирования Python 3 для выполнения на стороне web-браузера, позволяющей использовать Python вместо JavaScript для разработки скриптов для Web. Код проекта написан на языке Python и распространяется под лицензией BSD.

Подключив библиотеки brython.js и brython_stdlib.js, web-разработчик может использовать язык Python для определения логики работы сайта на стороне клиента, применяя Python вместо JavaScript. Для включения Python-кода на страницы используется тег ‹script› с mime-типом "text/python". Допускается как встраивание кода на страницу, так и загрузка внешних скриптов (‹script type="text/python" src="test.py"›). Из скрипта предоставляется полный доступ к элементам и событиям DOM. Помимо доступа к стандартной библиотеке Python предлагаются специализированные библиотеки для взаимодействия с DOM и JavaScript-библиотеками, такими как jQuery, D3, Highcharts и Raphael. Поддерживается использование CSS-фреймворков Bootstrap3, LESS и SASS.

Выполнение Python-кода из блоков ‹script› производится через предварительную компиляцию этого кода, выполняемую обработчиком Brython после загрузки страницы. Компиляция инициируется при помощи вызова функции brython(), например через добавление "‹body onload="brython()"›". На основе Python-кода формируется представление на языке JavaScript, которое затем выполняется штатным JavaScript-движком браузера (для сравнения, проект PyPy.js предлагает для выполнения Python-кода в браузере скомпилированный в asm.js интерпретатор CPython, а Skulpt реализует интерпретатор на JavaScript).

Итоговая производительность большинства операций во встраиваемых в web-страницы Python-сценариях близка к производительности CPython. Задержка возникает только на этапе компиляции, но для её устранения предоставляется возможность загрузки предварительно скомпилированного в JavaScript кода, которая применяется для ускорения загрузки стандартной библиотеки (Brython предоставляет инструментарий для создания JavaScript-библиотек на основе модулей Python).

Новый выпуск примечателен обеспечением совместимости с CPython 3.11 и реализацией большей части новых возможностей данной ветки, включая поддержку групп исключений и выражения "except*", детализации проблемных выражений в диагностических сообщениях и прикрепления примечаний к исключениям.

Источник: https://www.opennet.ru/opennews/art.shtml?num=57976

Bumble открыл систему машинного обучения для выявления непристойных изображений

Компания Bumble, развивающая один из крупнейших online-сервисов знакомств, открыла исходные тексты системы машинного обучения Private Detector, применяемой для определения непристойных изображений на загружаемых в сервис фотографиях. Система написана на языке Python, использует фреймворк Tensorflow и распространяется под лицензией Apache-2.0. Для классификации используется свёрточная нейронная сеть EfficientNet v2. Для загрузки доступна готовая модель для выявления изображений обнажённых людей. Точность определения составляет более 98%.

В состав также входит скрипт для создания собственных моделей, которые можно обучить на своей коллекции и использовать для классификации произвольного содержимого. Для обучения достаточно запустить скрипт с текстовыми файлами, содержащими списки изображений с положительным и отрицательным свойствами. После завершения обучения, можно передать в Private Detector произвольное изображение и на его основе будет вычислен коэффициент попадания.

Источник: https://www.opennet.ru/opennews/art.shtml?num=57975

В кодовую базу Android добавлена начальная поддержка архитектуры RISC-V

В репозиторий AOSP (Android Open Source Project), в котором развиваются исходные тексты платформы Android, началось включение изменений, обеспечивающих поддержку устройств с процессорами на основе архитектуры RISC-V.

Набор изменений для поддержки RISC-V подготовлен компанией Alibaba Cloud и включает 76 патчей, охватывающих различные подсистемы, включая графический стек, звуковую систему, компоненты воспроизведения видео, библиотеку bionic, виртуальную машину dalvik, фреймворки, стеки Wi-Fi и Bluetooth, инструментарий для разработчиков и различные сторонние модули, включая модели для TensorFlow Lite и модули машинного обучения для распознавания текста, классификации звука и изображений.

Из общего набора патчей в состав AOSP уже интегрировано 30 патчей, связанных с системным окружением и библиотеками. В течение следующих нескольких месяцев компания Alibaba Cloud намерена передать в состав AOSP дополнительные патчи, обеспечивающие поддержку RISC-V в ядре, Android Runtime (ART) и эмуляторе.

Для сопровождения поддержки RISC-V в Android в организации RISC-V International создана специальная рабочая группа Android SIG, к которой могут присоединиться и другие компании, заинтересованные в работе программного стека Android на процессорах RISC-V. Продвижение поддержки RISC-V в основной состав Android осуществляется в сотрудничестве с Google и представителями сообщества.

Предложенные для Android изменения подготовлены в рамках инициативы по расширению областей применения устройств на основе архитектуры RISC-V. В прошлом году компания Alibaba открыла наработки, связанные с RISC-V процессорами XuanTie, и начала активное продвижение RISC-V не только для IoT-устройтсв и серверных систем, но и для потребительских устройств и различных специализированных чипов, охватывающих различные области применения, от мультимедийных систем до обработки сигналов и ускорителей для машинного обучения.

RISC-V предоставляет открытую и гибкую систему машинных инструкций, позволяющую создавать микропроцессоры для произвольных областей применения, не требуя при этом отчислений и не налагая условий на использование. RISC-V позволяет создавать полностью открытые SoC и процессоры. В настоящее время на базе спецификации RISC-V разными компаниями и сообществами под различными свободными лицензиями (BSD, MIT, Apache 2.0) развивается несколько десятков вариантов ядер микропроцессоров, около сотни SoC и уже производимых чипов. Поддержка RISC-V присутствует начиная с выпусков Glibc 2.27, binutils 2.30, gcc 7 и ядра Linux 4.15.

Источник: https://www.opennet.ru/opennews/art.shtml?num=57972

Выпуск языка программирования Python 3.11

После года разработки опубликован значительный выпуск языка программирования Python 3.11. Новая ветка будет поддерживаться в течение полутора лет, после чего ещё три с половиной года для неё будут формироваться исправления с устранением уязвимостей.

Одновременно началось альфа-тестирование ветки Python 3.12 (в соответствии с новым графиком разработки работа над новой веткой начинается за пять месяцев до релиза предыдущей ветки и к моменту очередного релиза достигает стадии альфа-тестирования). Ветка Python 3.12 будет находиться на стадии альфа-выпусков в течение семи месяцев, во время которых будут добавляться новые возможности и производиться исправление ошибок. После этого в течение трёх месяцев будет проводиться тестирование бета-версий, во время которого добавление новых возможностей будет запрещено и всё внимание будет уделяться исправлению ошибок. Последние два месяца перед релизом ветка будет находиться на стадии кандидата в релизы, на которой будет выполнена финальная стабилизация.

Среди добавленных в Python 3.11 новшеств:

• Проведена значительная работа по оптимизации производительности. В новую ветку включены изменения, связанные с ускорением и inline-развёртыванием вызова функций, применением быстрых интерпретаторов типовых операций (x+x, x*x, x-x, a[i], a[i] = z, f(arg) C(arg), o.method(), o.attr = z, *seq), а также оптимизациями, подготовленными проектами Cinder и HotPy. В зависимости от вида нагрузки отмечается прирост скорости выполнения кода на 10-60%. В среднем производительность при прохождении тестового набора pyperformance увеличилась на 25%.

  Переработан механизм кэширования байткода, что позволило сократить время запуска интерпретатора на 10-15%. Объекты с кодом и байткод теперь статически разамещаются интерпретатором, что дало возможность исключить стадии демаршалинга извлечённого из кэша байткода и преобразования объектов с кодом для размещения в динамической памяти.

• При отображении трассировки вызовов в диагностических сообщениях обеспечен вывод информации о выражении, из-за которого возникла ошибка (ранее подсвечивалась лишь строка без детализации, какая именно часть строки стала причиной ошибки). Расширенную информацию о трассировке также можно получить через API и использовать для сопоставления отдельных инструкций байткода с конкретной позицией в исходном коде, используя метод codeobject.co_positions() или функцию C API PyCode_Addr2Location(). Изменение существенно упрощает отладку проблем, связанных с вложенными объектами словарей, множественными вызовами функций и сложными арифметическими выражениями. Traceback (most recent call last): File "calculation.py", line 54, in result = (x / y / z) * (a / b / c) ~~~~~~^~~ ZeroDivisionError: division by zero
• Добавлена поддержка групп исключений, дающих программе возможность генерировать и обрабатывать сразу несколько разных исключений одновременно. Для группировки нескольких исключений и их совместного вызова предложены новые типы исключений ExceptionGroup и BaseExceptionGroup, а для выделения отдельных исключений из группы добавлено выражение "except*".
• В класс BaseException добавлен метод add_note(), позволяющий прикрепить текстовое примечание к исключению, например, добавить контекстную информацию, недоступную во время генерации исключения.
• Добавлен специальный тип Self, представляющий текущий закрытый класс. Self может применяться для аннотирования методов, возвращающих экземпляр своего класса, более простым путём, чем при использовании TypeVar. class MyLock: def __enter__(self) -> Self: self.lock() return self
• Добавлен специальный тип LiteralString, который может включать только строковые литералы, совместимые с типом LiteralString (т.е. голые строки и строки с типом LiteralString, но не произвольные и не комбинированные строки с типом str). Тип LiteralString можно использовать для ограничения передачи функциям строковых аргументов, произвольная подстановка частей строк в которых может привести к уязвимостям, например, при формировании строк для SQL-запросов или shell-команд. def run_query(sql: LiteralString) -> ... ... def caller( arbitrary_string: str, query_string: LiteralString, table_name: LiteralString, ) -> None: run_query("SELECT * FROM students") # ok run_query(literal_string) # ok run_query("SELECT * FROM " + literal_string) # ok run_query(arbitrary_string) # Ошибка run_query( # Ошибка f"SELECT * FROM students WHERE name = {arbitrary_string}" )
• Добавлен тип TypeVarTuple, позволяющий использовать вариативные дженерики, в отличие от TypeVar охватывающие не один тип, а произвольное число типов.
• В стандартную библиотеку включён модуль tomllib с функциями для разбора формата TOML.
• Предоставлена возможность пометки отдельных элементов типизованных словарей (TypedDict) метками Required и NotRequired для определения обязательных и не обязательных полей (по умолчанию все объявленные поля обязательны для заполнения, если параметр total не выставлен в значение False). class Movie(TypedDict): title: str year: NotRequired[int] m1: Movie = {"title": "Black Panther", "year": 2018} # OK m2: Movie = {"title": "Star Wars"} # OK (поле year необязательное) m3: Movie = {"year": 2022} # Ошибка, не заполнено обязательное поле title)
• В модуль asyncio добавлен класс TaskGroup с реализацией асинхронного контекстного менеджера, ожидающего завершения группы задач. Добавление задач в группу осуществляется при помощи метода create_task(). async def main(): async with asyncio.TaskGroup() as tg: task1 = tg.create_task(some_coro(...)) task2 = tg.create_task(another_coro(...)) print("Both tasks have completed now.")
• Добавлен декоратор классов, методов и функций @dataclass_transform, при указании которого система проверки статических типов трактует объект, как при использовании декоратора @dataclasses.dataclass. В примере ниже класс CustomerModel при проверке типов будет обработан по аналогии с классом с декоратором @dataclasses.dataclass, т.е. как имеющий метод __init__, допускающий переменные id и name. @dataclass_transform() class ModelBase: ... class CustomerModel(ModelBase): id: int name: str
• В регулярных выражениях добавлена возможность использования атомарной группировки ((?›…)) и ревнивых (possessive) квантификаторов (*+, ++, ?+, {m,n}+).
• Добавлена опция командной строки "-P" и переменная окружения PYTHONSAFEPATH для отключения автоматического прикрепления к sys.path потенциально небезопасных файловых путей.
• Значительно улучшена утилита py.exe для платформы Windows, в которой реализована поддержка синтаксиса "-V:‹company›/‹tag›" в дополнение к "-‹major›.‹minor›".
• Многие макросы в C API преобразованы в обычные или статические inline-функции.
• Объявлены устаревшими и будут удалены в выпуске Python 3.13 модули uu, cgi, pipes, crypt, aifc, chunk, msilib, telnetlib, audioop, nis, sndhdr, imghdr, nntplib, spwd, xdrlib, cgitb, mailcap, ossaudiodev и sunau. Удалены функции PyUnicode_Encode*.

Источник: https://www.opennet.ru/opennews/art.shtml?num=57971

Релиз оконного менеджера IceWM 3.1.0, продолжающий развитие концепции вкладок

Доступен выпуск легковесного оконного менеджера IceWM 3.1.0. IceWM предоставляет полноценное управление через клавиатурные комбинации, возможность использования виртуальных рабочих столов, панели задач и меню-приложений. Оконный менеджер настраивается через достаточно простой файл конфигурации, возможно использование тем оформления. Доступны встроенные апплеты для мониторинга CPU, памяти, трафика. Отдельно развивается несколько сторонних GUI для настройки, реализаций рабочего стола и редакторов меню. Код написан на языке С++ и распространяется под лицензией GPLv2.

В новой версии продолжено развитие механизма управления окнами на основе вкладок. В заголовок окна добавлен специальный индикатор, позволяющий судить о наличии вкладок и переключаться между ними (ранее переключение осуществлялось при помощи клавиатурной комбинации или меню, а сами вкладки никак не выделялись). Разрешено использование во вкладке своего набора параметров (winoption). Добавлен новый параметр окна "frame" для автоматической группировки во вкладки окон приложений с одним значением "frame". Обеспечено сохранение привязки вкладок после перезапуска. В списке окон реализовано отображение вкладок. Улучшено поведение Alt+Tab для окон со вкладками.

Источник: https://www.opennet.ru/opennews/art.shtml?num=57968

Релиз Memtest86+ 6.00 с подержкой UEFI

Спустя 9 лет с момента формирования прошлой значительной ветки опубликован выпуск программы для тестирования оперативной памяти MemTest86+ 6.00. Программа может запускаться на начальной стадии загрузки для проведения полной проверки оперативной памяти. Код проекта распространяется под лицензией GPLv2.

Основные новшества:

• Полностью переписан код для загрузки и запуска при помощи прошивок UEFI.
• Добавлена поддержка SDRAM.
• Реализовано определение памяти DDR4 и DDR5.
• Реализовано определение процессоров AMD Zen 1/2/3/4.
• Реализовано определение процессоров Intel вплоть до 13-поколения.
• Улучшена поддержка поколений CPU AMD, предшествующих Zen.
• Добавлена поддержка режима Long Mode Paging.
• Добавлена поддержка до 256 ядер CPU.
• Добавлена поддержка профилей XMP 3.0 (Extreme Memory Profile).
• Добавлена поддержка старых чипсетов NVIDIA и AMD.

Источник: https://www.opennet.ru/opennews/art.shtml?num=57967

Линус Торвальдс предложил прекратить поддержку CPU i486 в ядре Linux

В ходе обсуждения обходных путей работы на процессорах x86, не поддерживающих инструкцию "cmpxchg8b", Линус Торвальдс заявил, что возможно настало время объявить наличие данной инструкции обязательным для работы ядра и отказаться от поддержки процессоров i486, не поддерживающих "cmpxchg8b", вместо того чтобы пытаться эмулировать работу данной инструкции на процессорах, которые уже никто не использует. В настоящее время почти все дистрибутивы Linux, продолжающие поддержку 32-разрядных систем x86, перешли на сборку ядра с опцией X86_PAE, требующей наличия поддержки "cmpxchg8b".

По мнению Линуса с точки зрения поддержки в ядре процессоры i486 потеряли актуальность, несмотря на то, что они всё ещё встречаются в обиходе. В определённый момент процессоры становятся музейными экспонатами и для них вполне можно обойтись "музейными" ядрами. Пользователи, у которых остаются системы с процессорами i486, смогут использовать LTS-выпуски ядра, которые будут сопровождаться ещё много лет.

Прекращение поддержки классических i486 не затронет выпускавшиеся компанией Intel встроенные процессоры Quark, которые хоть и относятся к классу i486, но включают свойственные поколению Pentium дополнительные инструкции, в том числе "cmpxchg8b". То же самое относится и к процессорам Vortex86DX. Поддержка процессоров i386 была прекращена в ядре 10 лет назад.

Источник: https://www.opennet.ru/opennews/art.shtml?num=57964