Пакет в репозитории имеет схему версионирования MAJOR.MINOR в то время как в апстриме применяется схема MAJOR.MINOR.PATCH В настоящий момент в рамках проекта ALTRepo DB (packages.altlinux.org, rdb.altlinux.org) ведётся активная разработка иструментария поиска открытых и закрытых уязвимостей пакетов репозитория ALT Linux. Существующая схема версионирования приводит к тому, что при анализе уязвимости пакетов с использованием данных CVE возникают ошибки при сравнении версий. Например для версии пакета 5.15 уязвимость содержащая следующую конфигурацию `CPE matching`: { "cpe": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versions": { "version_start": "", "version_end": "5.15.0", "version_start_excluded": false, "version_end_excluded": true } } считается открытой потому что версия 5.15 при сравнении считается меньше чем 5.15.0, которая исключена из диапазона версий. В других дистрибутивах пакет linux-tools версионируется по схеме как у ядра (MAJOR.MINOR.PATCH) https://repology.org/project/linux/versions Изменение схемы версионирования позволит эффективно отслеживать как закрытые так и открытые уязвимость пакетов в репозитории и значительно снизить процент ложных срабатываний.
У нас корректнее версионирование для пакета linux-tools, в апстриме этого пакета версионирование MAJOR.MINOR.PATCH не применяется.
Тогда надо исключать трансляцию linux-tools в linux_kernel CPE.
(In reply to Anton Farygin from comment #2) > Тогда надо исключать трансляцию linux-tools в linux_kernel CPE. На всякий случай поясню. Этот пакет собирается из (диры tools) mainline дерева Linux, где версии всегда 2х числовые (VERSION.PATCHLEVEL[-EXTRAVERSION]). 3х числовые версии это стабильные ядра (другой репозиторий, много других бранчей). Кроме того тегов vX.Y.0 не бывает. Я поискал, в perf тоже бывают CVE https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=perf например: CVE-2023-23003 In the Linux kernel before 5.16, tools/perf/util/expr.c lacks a check for the hashmap__new return value. Про этот CVE есть такие записи: cpe:2.3:o:linux:linux_kernel:5.14:-:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.14:rc1:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.14:rc2:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.14:rc3:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.14:rc4:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.14:rc5:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.14:rc6:*:*:*:*:*:* Вот эти версии из mainline. У нас rc* не собираются.
Виталий, проблема в том, что на linux-tools вешаются cve ядра, т.к. они матчатся в linux_kernel и имеют версию без PATCH. Возможно именно поэтому во всех дистрибутивах linux-tools собирают с трёхчисловыми версиями.
Есть точно такая же ошибка в другом пакете usbip: #46885
Я думаю никто не добавляет не существующую цифру к известной апстримной версии ради того, чтоб подстраиваться под ошибочные записи cpe. Но, действительно, у многих есть .0 у этих утилит - почти у всех кроме, например, Арча.
Да, добавление .0 тоже облегчит задачу, т.к. rpmvercmp считает 5.15.0 старше чем просто 5.15 В fedora, похоже, linux-tools называется kernel-tools и собирается из своего дерева. имеет PATCH в версии: https://src.fedoraproject.org/rpms/kernel-tools
В Ubuntu: https://packages.ubuntu.com/kinetic/linux-tools-common
Если мы добавим ".0", а в cpe будет правильная запись, например "version_start": "", "version_end": "5.15", "version_start_excluded": false, "version_end_excluded": true То версия 5.15.0 снова не будет исключена из ошибки. Таким образом добавление ".0" это не решение проблемы. Думаю самый правильный вариант - добавить в скрипт сравнения cpe отсечение хвостовых ".0" типа `sub /(\.0)+$/ -> ''` перед сравнением.
Сравнение идёт не в скрипте а в librpm. Ну и тогда сломается остальная логика работы с остальными приложениями. В libversion https://github.com/repology/libversion от автора репологии подобные хаки используются, но мы не хотели бы переходить на неё и полностью отдать сравнение версий в librpm
Я не имел ввиду что надо менять сам алгоритм сравнения. Я имел ввиду что добавление ".0" к версии пакета не решит проблему сравнения её с ошибочными записями из cpe. Для решения достаточно было бы "нормализовать" версии взятые из cpe и из пакета перед их сравнением -- удалив хвостовые ".0". >> https://github.com/repology/libversion > "Unusual separators: 1_2~3 == 1.2.3" Странное решение в свете распространенности тильды (в Debian, gnulib и rpm).
https://packages.altlinux.org/ru/tasks/381828/fixes/ может быть нам вообще отвязать пакет linux-tools от CPE ядра ?
