Bug 46884

Summary: некорректная схема версионирования пакета
Product: Sisyphus Reporter: Danil Shein <dshein>
Component: linux-toolsAssignee: Vitaly Chikunov <vt>
Status: NEW --- QA Contact: qa-sisyphus
Severity: normal    
Priority: P5 CC: rider, vt
Version: unstable   
Hardware: x86_64   
OS: Linux   

Description Danil Shein 2023-07-12 15:45:52 MSK
Пакет в репозитории имеет схему версионирования 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

Изменение схемы версионирования позволит эффективно отслеживать как закрытые так и открытые уязвимость пакетов в репозитории и значительно снизить процент ложных срабатываний.
Comment 1 Vitaly Chikunov 2023-07-12 22:04:47 MSK
У нас корректнее версионирование для пакета linux-tools, в апстриме этого пакета версионирование MAJOR.MINOR.PATCH не применяется.
Comment 2 Anton Farygin 2023-07-13 09:38:14 MSK
Тогда надо исключать трансляцию linux-tools в linux_kernel CPE.
Comment 3 Vitaly Chikunov 2023-07-13 10:00:11 MSK
(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* не собираются.
Comment 4 Anton Farygin 2023-07-13 10:37:20 MSK
Виталий, проблема в том, что на linux-tools вешаются cve ядра, т.к. они матчатся в linux_kernel и имеют версию без PATCH.

Возможно именно поэтому во всех дистрибутивах linux-tools собирают с трёхчисловыми версиями.
Comment 5 Anton Farygin 2023-07-13 10:38:54 MSK
Есть точно такая же ошибка в другом пакете usbip:
#46885
Comment 6 Vitaly Chikunov 2023-07-13 11:07:41 MSK
Я думаю никто не добавляет не существующую цифру к известной апстримной версии ради того, чтоб подстраиваться под ошибочные записи cpe. Но, действительно, у многих есть .0 у этих утилит - почти у всех кроме, например, Арча.
Comment 7 Anton Farygin 2023-07-13 11:17:09 MSK
Да, добавление .0 тоже облегчит задачу, т.к. rpmvercmp считает 5.15.0 старше чем просто 5.15

В fedora, похоже, linux-tools называется kernel-tools и собирается из своего дерева. имеет PATCH в версии:
https://src.fedoraproject.org/rpms/kernel-tools
Comment 8 Anton Farygin 2023-07-13 11:20:57 MSK
В Ubuntu:
https://packages.ubuntu.com/kinetic/linux-tools-common
Comment 9 Vitaly Chikunov 2023-07-14 00:49:37 MSK
Если мы добавим ".0", а в cpe будет правильная запись, например

     "version_start": "",
     "version_end": "5.15",
     "version_start_excluded": false,
     "version_end_excluded": true

То версия 5.15.0 снова не будет исключена из ошибки. Таким образом добавление ".0" это не решение проблемы.

Думаю самый правильный вариант - добавить в скрипт сравнения cpe отсечение хвостовых ".0" типа `sub /(\.0)+$/ -> ''` перед сравнением.
Comment 10 Anton Farygin 2023-07-14 09:25:43 MSK
Сравнение идёт не в скрипте а в librpm.
Ну и тогда сломается остальная логика работы с остальными приложениями.

В libversion https://github.com/repology/libversion  от автора репологии подобные хаки используются, но мы не хотели бы переходить на неё и полностью отдать сравнение версий в librpm
Comment 11 Vitaly Chikunov 2023-07-14 10:00:05 MSK
Я не имел ввиду что надо менять сам алгоритм сравнения.

Я имел ввиду что добавление ".0" к версии пакета не решит проблему сравнения её с ошибочными записями из cpe. Для решения достаточно было бы "нормализовать" версии взятые из cpe и из пакета перед их сравнением -- удалив хвостовые ".0".

>> https://github.com/repology/libversion
> "Unusual separators: 1_2~3 == 1.2.3"

Странное решение в свете распространенности тильды (в Debian, gnulib и rpm).