Summary: | некорректная схема версионирования пакета | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Danil Shein <dshein> |
Component: | linux-tools | Assignee: | 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
У нас корректнее версионирование для пакета 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 Если мы добавим ".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).
|