38287 2020-03-27 15:45:41 +0300 Задать жёсткую зависимость на версию openssl у бинарного пакета ntp 2020-04-04 16:16:35 +0300 1 1 4 Development Sisyphus ntp unstable x86_64 Linux CLOSED FIXED P5 enhancement --- 1 vercha asy asy glebfm ldv mcpain mike rider sotor qa-sisyphus oldest_to_newest 188882 0 vercha 2020-03-27 15:45:41 +0300 # rpm -qa | grep ntp ntp-4.2.8p13-alt1.x86_64 ntpdate-4.2.8p13-alt1.x86_64 ntpq-4.2.8p13-alt1.x86_64 ntp-doc-4.2.8p13-alt1.noarch ntpd-4.2.8p13-alt1.x86_64 ntp-aux-4.2.8p13-alt1.noarch ntp-utils-4.2.8p13-alt1.x86_64 Тестовые стенды: server-9-x86-64 workstation-9-x86-64 При выполнении команды ntp-keygen ошибка: OpenSSL version mismatch. Built against 101000af, you have 1010104f Built against OpenSSL OpenSSL 1.1.0j 20 Nov 2018, using version OpenSSL 1.1.1d 10 Sep 2019 Using host server-9-x86-64-office group server-9-x86-64-office Generating RSA keys (512 bits)... RSA 0 36 38 1 26 54 3 1 2 Generating new host file and link ntpkey_host_server-9-x86-64-office->ntpkey_RSAhost_server-9-x86-64-office.3794299580 Using host key as sign key Generating new certificate server-9-x86-64-office RSA-MD5 X509v3 Basic Constraints: critical,CA:TRUE X509v3 Key Usage: digitalSignature,keyCertSign Verify RSA-MD5 certificate fails error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm 188900 1 asy 2020-03-27 20:34:03 +0300 Что-то тут не так. Вот это OpenSSL version mismatch. Built against 101000af, you have 1010104f Built against OpenSSL OpenSSL 1.1.0j 20 Nov 2018, using version OpenSSL 1.1.1d 10 Sep 2019 у меня воспроизводится. Причина понятна: после обновления OpenSSL не пересобрали ntp. Вопрос сразу к ldv@: а такие неочевидные штуки сборочница как-то может ловить? А вот с ntp из задания 248359 это не воспроизводится у меня. В итоге простой запуск ntp-keygen всё равно даёт ошибку (error:0909006C:PEM routines:get_name:no start line), но на несоответствие версий OpenSSL не ругается уже. 188902 2 asy 2020-03-27 21:11:00 +0300 (In reply to Vera Blagoveschenskaya from comment #0) > При выполнении команды ntp-keygen ошибка: > OpenSSL version mismatch. Built against 101000af, you have 1010104f Это, всё же, только предупреждение. Но почему и с p14 на стенде вылезло я по прежнему не понимаю. > Verify RSA-MD5 certificate fails > error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message > digest algorithm А это последствие того, что в новом OpenSSL отключили MD5. Надо пока использовать "-c RSA-SHA1" например. 188904 3 asy 2020-03-27 21:41:55 +0300 Оказывается у них есть баг про MD5: https://bugs.ntp.org/show_bug.cgi?id=2518 Я немного дописал. 188936 4 asy 2020-03-30 10:31:56 +0300 (In reply to Vera Blagoveschenskaya from comment #0) > При выполнении команды ntp-keygen ошибка: > OpenSSL version mismatch. Built against 101000af, you have 1010104f > Built against OpenSSL OpenSSL 1.1.0j 20 Nov 2018, using version OpenSSL > 1.1.1d 10 Sep 2019 Это проблема сборочницы. Вероятно enhancement, если это вообще исправимо. > Verify RSA-MD5 certificate fails > error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message > digest algorithm По этому поводу завёл Bug 38300 188947 5 glebfm 2020-03-30 11:46:18 +0300 (Ответ для Sergey Y. Afonin на комментарий #4) > (In reply to Vera Blagoveschenskaya from comment #0) > > > При выполнении команды ntp-keygen ошибка: > > OpenSSL version mismatch. Built against 101000af, you have 1010104f > > Built against OpenSSL OpenSSL 1.1.0j 20 Nov 2018, using version OpenSSL > > 1.1.1d 10 Sep 2019 > > Это проблема сборочницы. Вероятно enhancement, если это вообще исправимо. А при чём тут сборочница? Это ntp сам по себе решил, что версия не совпала, set:versions так не посчитали -- кто-то из них неправ. 188956 6 asy 2020-03-30 13:37:11 +0300 (In reply to Gleb F-Malinovskiy from comment #5) > > Это проблема сборочницы. Вероятно enhancement, если это вообще исправимо. > > А при чём тут сборочница? Это ntp сам по себе решил, что версия не совпала, > set:versions так не посчитали -- кто-то из них неправ. Я пока не знаю, зачем ntp это проверяет и выдаёт предупреждение. Но может в сборочнице можно сделать какой-то список явных зависимостей на тему, что требуется пересобирать? На самом деле есть минимум ещё один кандидат, который просто так не ловится. Оказалось, что при обновлении gpsd до 3.19 надо было явно пересобрать gqrx. Но это отдел тестирования на пересборке репозитория отловил правда. Не знаю пока, это что-то разовое было, или всегда так будет. 188958 7 ldv 2020-03-30 13:44:22 +0300 (In reply to Vera Blagoveschenskaya from comment #0) > При выполнении команды ntp-keygen ошибка: > OpenSSL version mismatch. Built against 101000af, you have 1010104f > Built against OpenSSL OpenSSL 1.1.0j 20 Nov 2018, using version OpenSSL > 1.1.1d 10 Sep 2019 Ну это просто древний баг в пакете ntp. (In reply to Sergey Y. Afonin from comment #6) > Я пока не знаю, зачем ntp это проверяет и выдаёт предупреждение. Но может в > сборочнице можно сделать какой-то список явных зависимостей на тему, что > требуется пересобирать? Если вы знаете, чтобы между пакетами были противоестественные зависимости, просто запишите их в спек-файле. А мы потом покритикуем. 188959 8 ldv 2020-03-30 13:45:13 +0300 (In reply to Dmitry V. Levin from comment #7) > Если вы знаете, Если вы хотите, конечно. 188965 9 asy 2020-03-30 14:27:36 +0300 (In reply to Dmitry V. Levin from comment #7) > > Я пока не знаю, зачем ntp это проверяет и выдаёт предупреждение. Но может в > > сборочнице можно сделать какой-то список явных зависимостей на тему, что > > требуется пересобирать? > > Если вы знаете, чтобы между пакетами были противоестественные зависимости, > просто запишите их в спек-файле. А мы потом покритикуем. А что, в спек-файле есть такие зависимости, которые говорят, что "вон тот пакет надо непременно всегда пересобрать если я пересобрался"? :-) 188966 10 ldv 2020-03-30 14:29:10 +0300 (In reply to Sergey Y. Afonin from comment #9) > (In reply to Dmitry V. Levin from comment #7) > > > > Я пока не знаю, зачем ntp это проверяет и выдаёт предупреждение. Но может в > > > сборочнице можно сделать какой-то список явных зависимостей на тему, что > > > требуется пересобирать? > > > > Если вы знаете, чтобы между пакетами были противоестественные зависимости, > > просто запишите их в спек-файле. А мы потом покритикуем. > > А что, в спек-файле есть такие зависимости, которые говорят, что "вон тот > пакет надо непременно всегда пересобрать если я пересобрался"? :-) В точности наоборот: в "том пакете" можно указать жёсткую зависимость. 188967 11 asy 2020-03-30 14:46:27 +0300 (In reply to Dmitry V. Levin from comment #10) > > А что, в спек-файле есть такие зависимости, которые говорят, что "вон тот > > пакет надо непременно всегда пересобрать если я пересобрался"? :-) > > В точности наоборот: в "том пакете" можно указать жёсткую зависимость. А как? Requires: name = %EVR очевидно же, что не годится. Нужна логика вида Requires: name (and rebuild if %EVR changed). 188968 12 ldv 2020-03-30 14:59:43 +0300 (In reply to Sergey Y. Afonin from comment #11) > (In reply to Dmitry V. Levin from comment #10) > > > > А что, в спек-файле есть такие зависимости, которые говорят, что "вон тот > > > пакет надо непременно всегда пересобрать если я пересобрался"? :-) > > > > В точности наоборот: в "том пакете" можно указать жёсткую зависимость. > > А как? Requires: name = %EVR очевидно же, что не годится. Почему не годится? > Нужна логика вида Requires: name (and rebuild if %EVR changed). Что значит rebuild в Requires? 188970 13 asy 2020-03-30 15:15:42 +0300 (In reply to Dmitry V. Levin from comment #12) > > А как? Requires: name = %EVR очевидно же, что не годится. > > Почему не годится? Я может не очень понятно написал в 6-ом комментарии. Речь не про привязку к конкретной версии, а про пересборку с любой новой версией. Практически то же самое, что делает set version (не даёт пропустить задание без, как минимум, пересборки зависимого пакета), но в ситуации, котогда set version не срабатывает ввиду других причин необходимости, отличных от проверяемых set version. 188973 14 ldv 2020-03-30 16:54:24 +0300 (In reply to Sergey Y. Afonin from comment #13) > (In reply to Dmitry V. Levin from comment #12) > > > > А как? Requires: name = %EVR очевидно же, что не годится. > > > > Почему не годится? > > Я может не очень понятно написал в 6-ом комментарии. Речь не про привязку к > конкретной версии, а про пересборку с любой новой версией. Практически то же > самое, что делает set version (не даёт пропустить задание без, как минимум, > пересборки зависимого пакета), но в ситуации, котогда set version не > срабатывает ввиду других причин необходимости, отличных от проверяемых set > version. Повторю ещё раз: - эта проверка в ntp очевидно неправильная; - в пакетах бывают (возможно, зря, но бывают) жёсткие привязки к версиям других пакетов. Посмотрите, например, gvfs.spec 188974 15 asy 2020-03-30 17:07:25 +0300 (In reply to Dmitry V. Levin from comment #14) > Повторю ещё раз: > - эта проверка в ntp очевидно неправильная; При чём тут конкретно ntp? Во-первых я уже привёл один пример другого пакета. Во-вторых зачем-то же сделали копирование пересборкой, а не оставили просто копирование. > - в пакетах бывают (возможно, зря, но бывают) жёсткие привязки к версиям > других пакетов. Посмотрите, например, gvfs.spec Привязка к версии в данном случае не рассматривается. 188992 16 asy 2020-03-31 09:17:54 +0300 И всё же это фичереквест для сборочничы, а не для какого-то конкретного пакета. Если он не может быть реализован, либо нужность его переоценена, надо закрыть, как WONTFIX. 188995 17 ldv 2020-03-31 12:29:17 +0300 Пожалуйста, не надо перевешивать ошибки, найденные в конкретном пакете, на инфраструктуру. 188996 18 asy 2020-03-31 12:57:26 +0300 Пожалуйста не надо перевешивать на пакет заявку на фичу на инфраструктуру, которая иллюстрируется НЕ ошибкой на пакете. Данное сообщение на пакете ntp НЕ ЯВЛЯЕТСЯ ОШИБКОЙ и НЕ ВЛИЯЕТ НА РАБОТОСПОСОБНОСТЬ! 188997 19 asy 2020-03-31 13:01:38 +0300 Если кто-то ещё не понял, настоящей ошибкой на ntp тут было Verify RSA-MD5 certificate fails error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest Оно не имеет абсолютно никакого отношения к ПРЕДУПРЕЖДЕНИЮ про версию SSL и это Bug 38300. 188999 20 ldv 2020-03-31 13:27:59 +0300 Если вы не хотите понимать, что я вам написал, то я не буду больше тратить на это время. Внепакетных зависимостей не бывает. 189000 21 asy 2020-03-31 13:38:24 +0300 (In reply to Dmitry V. Levin from comment #20) > Если вы не хотите понимать, что я вам написал, Я хорошо понимаю, что хотите сказать Вы, а вот Вы, очевидно, не понимаете, что хочу сказать я. Понятно только, что мы совершенно про разное. > то я не буду больше тратить на это время. Внепакетных зависимостей не бывает. Хорошо. 189001 22 rider 2020-03-31 13:44:03 +0300 на girar уже есть данные о том, какие пакеты что используют в runtime и при сборке. В принципе технически отправить на пересборку не должно быть сложным. Но - если у содержимого пакета есть runtime зависимость на версию другого пакета, а в rpm пакете такая зависимость не зафиксирована, то это ошибка. Нужно просто прописать у ntp более жёстку зависимость на версию openssl, с которой он собрался. В этом случае при сборке следующей версии openssl его сразу пересоберут. 189002 23 asy 2020-03-31 14:20:21 +0300 (In reply to Anton Farygin from comment #22) > В принципе технически отправить на пересборку не должно быть сложным. Но - > если у содержимого пакета есть runtime зависимость на версию другого пакета, > а в rpm пакете такая зависимость не зафиксирована, то это ошибка. > > Нужно просто прописать у ntp более жёстку зависимость на версию openssl, с > которой он собрался. > > В этом случае при сборке следующей версии openssl его сразу пересоберут. Как это сделать, не залезая в спек? 189003 24 asy 2020-03-31 14:32:00 +0300 (In reply to Sergey Y. Afonin from comment #23) > > В этом случае при сборке следующей версии openssl его сразу пересоберут. > > Как это сделать, не залезая в спек? Другими словами, есть ли в rpm макрос, который определяет что-то аналогичное %EVR, но для пакета из BuildRequires? Если есть, то я тогда не прав. А если нет, то тогда это фичереквест для сборочницы. Или rpm. 189005 25 ldv 2020-03-31 15:08:58 +0300 (In reply to Dmitry V. Levin from comment #14) > Повторю ещё раз: > - эта проверка в ntp очевидно неправильная; > - в пакетах бывают (возможно, зря, но бывают) жёсткие привязки к версиям > других пакетов. Посмотрите, например, gvfs.spec Есть и другие примеры, помимо gvfs.spec: $ git grep '^Requires: [^=]* = %{get_SVR' j/javazi/javazi.spec:Requires: tzdata = %{get_SVR tzdata} $ git grep -Fw '%{get_dep' f/fuse-7z/fuse-7z.spec:Requires: %{get_dep fuse} g/gvfs/gvfs.spec:Requires: %{get_dep fuse3} i/itest/itest.spec:Requires: %{get_dep libqt4-core} k/kde4-basket/basket.spec:Requires: %{get_dep kde4libs} p/polkit-qt-1/policykit-qt.spec:Requires: %{get_dep libqt4-core} s/sawfish/sawfish.spec:Requires: %{get_dep rep-gtk} Зависит от требуемой степени жёсткости. 189006 26 asy 2020-03-31 15:23:17 +0300 (In reply to Dmitry V. Levin from comment #25) > > других пакетов. Посмотрите, например, gvfs.spec Тут почти всё задано жёстко. Есть get_dep(), но на общем объёме не заметно. > Есть и другие примеры, помимо gvfs.spec: > > $ git grep '^Requires: [^=]* = %{get_SVR' > j/javazi/javazi.spec:Requires: tzdata = %{get_SVR tzdata} А вот это то самое, да. 189007 27 ldv 2020-03-31 15:29:23 +0300 $ git grep '^Requires: [^%]*%{get_version' a/attica/attica.spec:Requires: libqt4-core >= %{get_version libqt4-core} k/kde4-kmldonkey/kmldonkey.spec:Requires: kde4libs >= %{get_version kde4libs} k/kde4-smb4k/smb4k.spec:Requires: kde4libs >= %{get_version kde4libs} k/kdevplatform/kdevplatform.spec:Requires: kde4libs >= %{get_version kde4libs} k/kdevplatform/kdevplatform.spec:Requires: kde4libs >= %{get_version kde4libs} k/kdevplatform/kdevplatform.spec:Requires: kde4libs >= %{get_version kde4libs} k/kdevplatform/kdevplatform.spec:Requires: kde4libs >= %{get_version kde4libs} k/kdevplatform/kdevplatform.spec:Requires: kde4libs >= %{get_version kde4libs} l/libtag-extras/libtag-extras.spec:Requires: libtag >= %{get_version libtag} l/licq/licq.spec:Requires: kde4libs >= %{get_version kde4libs} l/licq/licq.spec:Requires: libqt4-core >= %{get_version libqt4-core} p/phonon/phonon.spec:Requires: libqt4-core >= %{get_version libqt4-core} p/polkit-qt-1/policykit-qt.spec:Requires: libqt4-core >= %{get_version libqt4-core} q/qimageblitz/qimageblitz.spec:Requires: libqt4-core >= %{get_version libqt4-core} В общем, много есть разных примеров. 189008 28 asy 2020-03-31 15:44:07 +0300 Достаточно было grep "^%get_" /usr/lib/rpm/x86_64-linux/macros но спасибо. :-) 189058 29 asy 2020-04-03 22:29:51 +0300 (In reply to Sergey Y. Afonin from comment #28) > Достаточно было grep "^%get_" /usr/lib/rpm/x86_64-linux/macros Но что-то не получается... Requires: libcrypto = %{get_version libssl-devel} Локально это работает, но вот в сборочнице не очень: error: line 51: Version required: Requires: libcrypto = Я правильно понимаю, что не работать это может только по причине отсутствия libssl-devel на момент исполнения? Но зависимость на libssl-devel уже и через BuildPreReq описал. Сейчас в последней итерации попробовал в get_version написать libcrypto1.1, то же самое. 189059 30 ldv 2020-04-03 22:40:22 +0300 (In reply to Sergey Y. Afonin from comment #29) > (In reply to Sergey Y. Afonin from comment #28) > > > Достаточно было grep "^%get_" /usr/lib/rpm/x86_64-linux/macros > > Но что-то не получается... > > Requires: libcrypto = %{get_version libssl-devel} > > Локально это работает, но вот в сборочнице не очень: > error: line 51: Version required: Requires: libcrypto = В дополнение ко всему, пакета libcrypto ещё и нет. Попробуйте %(rpmquery --qf 'Requires: %%{NAME} = %%{VERSION}' libcrypto1.1) 189060 31 asy 2020-04-03 23:33:25 +0300 (In reply to Dmitry V. Levin from comment #30) > > Requires: libcrypto = %{get_version libssl-devel} > > > > Локально это работает, но вот в сборочнице не очень: > > error: line 51: Version required: Requires: libcrypto = > > В дополнение ко всему, пакета libcrypto ещё и нет. Попробуйте Так ругается же на отсутствие версии, а не пакета. По поводу пакета: в openssl есть "Provides: libcrypto = %version-%release". > %(rpmquery --qf 'Requires: %%{NAME} = %%{VERSION}' libcrypto1.1) Так работает. А Requires: libcrypto1.1 = %{get_version libcrypto1.1} не работает тоже, хотя я не очень понимаю разницу в этом случае. Вообще привязка к версии в имени - это то что хочется избежать как раз. В принципе вот это тоже сработало, и вроде бы как пока задумано: %(rpmquery --qf 'Requires: libcrypto = %%{VERSION}' libssl-devel) 189061 32 ldv 2020-04-04 00:37:03 +0300 (In reply to Sergey Y. Afonin from comment #31) > Вообще привязка к версии в имени - это то что хочется избежать как раз. В > принципе вот это тоже сработало, и вроде бы как пока задумано: > > %(rpmquery --qf 'Requires: libcrypto = %%{VERSION}' libssl-devel) libcrypto - это версионированный provides, так что по идее тоже должно работать. 189068 33 repository-robot 2020-04-04 16:16:35 +0300 ntp-4.2.8p14-alt2 -> sisyphus: Sat Apr 04 2020 Sergey Y. Afonin <asy@altlinux> 4.2.8p14-alt2 - updated License tag to SPDX syntax, changed to GPL-3.0-or-later - added ntp-4.2.8p14-MD5-to-SHA1-default.patch (ALT #38300) - added libcrypto with build version to Requires (ALT #38287)