46884 2023-07-12 15:45:52 +0300 некорректная схема версионирования пакета 2025-04-21 14:06:06 +0300 1 1 4 Development Sisyphus linux-tools unstable x86_64 Linux NEW P5 normal --- 1 dshein vt rider vt qa-sisyphus oldest_to_newest 229559 0 dshein 2023-07-12 15:45:52 +0300 Пакет в репозитории имеет схему версионирования 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 Изменение схемы версионирования позволит эффективно отслеживать как закрытые так и открытые уязвимость пакетов в репозитории и значительно снизить процент ложных срабатываний. 229585 1 vt 2023-07-12 22:04:47 +0300 У нас корректнее версионирование для пакета linux-tools, в апстриме этого пакета версионирование MAJOR.MINOR.PATCH не применяется. 229592 2 rider 2023-07-13 09:38:14 +0300 Тогда надо исключать трансляцию linux-tools в linux_kernel CPE. 229594 3 vt 2023-07-13 10:00:11 +0300 (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* не собираются. 229596 4 rider 2023-07-13 10:37:20 +0300 Виталий, проблема в том, что на linux-tools вешаются cve ядра, т.к. они матчатся в linux_kernel и имеют версию без PATCH. Возможно именно поэтому во всех дистрибутивах linux-tools собирают с трёхчисловыми версиями. 229598 5 rider 2023-07-13 10:38:54 +0300 Есть точно такая же ошибка в другом пакете usbip: #46885 229602 6 vt 2023-07-13 11:07:41 +0300 Я думаю никто не добавляет не существующую цифру к известной апстримной версии ради того, чтоб подстраиваться под ошибочные записи cpe. Но, действительно, у многих есть .0 у этих утилит - почти у всех кроме, например, Арча. 229610 7 rider 2023-07-13 11:17:09 +0300 Да, добавление .0 тоже облегчит задачу, т.к. rpmvercmp считает 5.15.0 старше чем просто 5.15 В fedora, похоже, linux-tools называется kernel-tools и собирается из своего дерева. имеет PATCH в версии: https://src.fedoraproject.org/rpms/kernel-tools 229613 8 rider 2023-07-13 11:20:57 +0300 В Ubuntu: https://packages.ubuntu.com/kinetic/linux-tools-common 229715 9 vt 2023-07-14 00:49:37 +0300 Если мы добавим ".0", а в cpe будет правильная запись, например "version_start": "", "version_end": "5.15", "version_start_excluded": false, "version_end_excluded": true То версия 5.15.0 снова не будет исключена из ошибки. Таким образом добавление ".0" это не решение проблемы. Думаю самый правильный вариант - добавить в скрипт сравнения cpe отсечение хвостовых ".0" типа `sub /(\.0)+$/ -> ''` перед сравнением. 229719 10 rider 2023-07-14 09:25:43 +0300 Сравнение идёт не в скрипте а в librpm. Ну и тогда сломается остальная логика работы с остальными приложениями. В libversion https://github.com/repology/libversion от автора репологии подобные хаки используются, но мы не хотели бы переходить на неё и полностью отдать сравнение версий в librpm 229729 11 vt 2023-07-14 10:00:05 +0300 Я не имел ввиду что надо менять сам алгоритм сравнения. Я имел ввиду что добавление ".0" к версии пакета не решит проблему сравнения её с ошибочными записями из cpe. Для решения достаточно было бы "нормализовать" версии взятые из cpe и из пакета перед их сравнением -- удалив хвостовые ".0". >> https://github.com/repology/libversion > "Unusual separators: 1_2~3 == 1.2.3" Странное решение в свете распространенности тильды (в Debian, gnulib и rpm). 263288 12 rider 2025-04-21 14:06:06 +0300 https://packages.altlinux.org/ru/tasks/381828/fixes/ может быть нам вообще отвязать пакет linux-tools от CPE ядра ?