Created attachment 15277 [details] Тест для демонстрации ошибок приложения на Qt 6.6 отключают поддержку tls, соответсвенно пропадает сеть. -------------------------- Причина: ``` /etc/openssl/openssl.cnf [provider_sect] default = default_sect [default_sect] #activate = 1 ``` Закомментирован флаг инициализации ( в Fedora включен из коробки,в Debian - деволтный конфиг.) -------------------------- Последствия: Если приложение на qt6.6 обратится к crypto - например QCryptographicHash или выполнит plain - http запрос ДО инициализации SSL, инициализация ssl завершится неудачно, что приведет к: ``` Random number generator not seeded, disabling SSL support ``` Приложение остается без интернета. -------------------------- Подробности: 1. В случае обращения к Crypto hash - cначала вызывается OSSL_PROVIDER_load с цепочкой вызовов до OPENSSL_init_crypto 2. Для tls сначала вызывается OPENSSL_init_ssl + сопутсвующие соответственно, если вызовы пройдут в порядке 1->2 то tls работать не будет, в обратном порядке будет работать. Приводит к ошибкам в различных приложениях. -------------------------- Тесты: Простой тест - во вложении. Команда для компиляции: ``` /usr/lib64/qt6/libexec/moc qt_test.cpp > qt_test.moc && g++-13 -I /usr/include/qt6/QtCore/ -I /usr/include/qt6 -I /usr/include/qt6/QtNetwork/ qt_test.cpp -l Qt6Core -l Qt6Network ```
OpenSSL 3.1.4 24 Oct 2023 (Library: OpenSSL 3.1.4 24 Oct 2023)
(In reply to proskurinov@basealt.ru from comment #0) > Закомментирован флаг инициализации ( в Fedora включен из коробки,в Debian - > деволтный конфиг.) Получается, в Debian это тоже не работает? В апстримном конфиге activate закомментирован, да и в целом в этом месте наш конфиг ничем не отличается от апстримного.
Нет, в Debian работает, в том числе с нынешним конфигом из Сизифа. Я считаю, что это значит, что проблема вовсе не в конфиге потому что разница точно не только в нём.
$ audiotube ssl.SSLError: [SSL] malloc failure (_ssl.c:3026) At: /usr/lib64/python3.12/ssl.py(438): __new__ /usr/lib/python3/site-packages/urllib3/util/ssl_.py(292): create_urllib3_context /usr/lib/python3/site-packages/requests/adapters.py(84): <module> <frozen importlib._bootstrap>(488): _call_with_frames_removed P.S. Если конфиг поправить, то всё ок.
*** Bug 52068 has been marked as a duplicate of this bug. ***
(Ответ для Gleb F-Malinovskiy на комментарий #3) > проблема вовсе не в конфиге потому что разница точно не только в нём. По крайней мере, я ни у кого не видел никаких патчей на qtbase про ssl.
Created attachment 17202 [details] digikam При первом запуске digikam предлагается скачать необходимые файлы и возникает ошибка. Помогает включение параметра `activate = 1` в конфиге openssl.
*** Bug 51318 has been marked as a duplicate of this bug. ***
*** Bug 52115 has been marked as a duplicate of this bug. ***
У меня разобраться не получается. Всё, что смог найти -- отсутствие каких-либо патчей или опций сборки хоть как-то связанных с openssl в debian, fedora и suse.
$ audiotube qrc:/AlbumCoverItem.qml:19:12: Duplicate signal name: invalid override of property change signal or superclass signal ssl.SSLError: [SSL: LIBRARY_HAS_NO_CIPHERS] library has no ciphers (_ssl.c:3026) Ну вывод об ошибке определённо изменился.
Прикладываю копипасту из задачи 113600 (сообщения 93 - 101). Дело было около года назад (тогда же я завел и этот баг), с тех пор по этому поводу мои мысли не особо поменились, единственное что появилась масса подтверждений что изменение конфига убирает проблему. ================================================= В Qt6.6 отвалилась вся сеть по TLS, сразу в нескольких приложениях, qt ругается на какой-то random seed и отключает tls. Соответсвенно новые пакеты пока не получается проверить. Разбираюсь с qt. ================================================= По поводу QT. В qt-base (qtbase/src/plugins/tls/openssl/qtlsbackend_openssl.cpp) есть вызов q_RAND_status(). Функция обернута в макросы,но по сути это обращение к libssl3. Проблема следующая - функция вызывается через механизм resolve, то есть ее адрес вычисляется в runtime. Если resolve не сработает, макросы вернут -1 в качестве результата выполнения q_RAND_status, что приводит к "Random number generator not seeded, disabling SSL support" и отключению сети полностью. Обойти проблему можно если обратиться к QSslConfiguration до запуска qt application engine(причем независимо Console GUI или QML), тогда дальнейшие обращения будут проходить без проблем, думаю адреса где-то кэшируются после resolve. В общем делаю пока вывод что это проблема динамической линковки, других идей пока нет, в librum-reader добавлю костыль, дополнительное обращение к ssl3 не должно как то повлиять на работу программы. ================================================= Дополнительные эксперименты с qt и openssl показали что rand_status действительно возвращает 0 иногда. Тогда появляются вопросы к c сборке openssl. Доки по openssl говорят следующее: ``` seeding of the default OpenSSL random generator (RAND_OpenSSL(3)) is not necessary (but allowed), since it does (re-)seed itself automatically using trusted system entropy sources. This holds unless the default RAND_METHOD has been replaced or OpenSSL was built with automatic reseeding disabled, see RAND for more details. ``` ================================================= Собрал себе QT core без оптимизаций, прошелся gdb по всему вызову http запроса. Ломает работу сети не сам http запрос, а вызов QCryptographicHash - вычисление крипто хэша вызывает libcrypto. Прошелся по алгоритму вычисления крипто хэша в qt, реализовал его без qt, работает - хэши совпадают статус нормальный. Если вызвать QCryptographicHash из qt до обращения к libssl, libssl работать откажется. В debian не воспроизводится. Качаю fedor-у. ================================================== 1. в случае обращения к Crypto hash - cначала вызывается OSSL_PROVIDER_load с цепочкой вызовов до OPENSSL_init_crypto 2. для tls сначала вызывается OPENSSL_init_ssl + сопутсвующие В целом пока понятно что в QT какая-то проблема с инициализацией openssl, непонятно почему не удается воспроизвести без qt. ================================================== Похоже что проблема действительно в инициализации, у нас отключена дефолтная инициализация provider (vim /etc/openssl/openssl.cnf) В федоре включена, в дебиан тоже. QT не сомсем верно справляется с данной ситуацией, поэтому tls отваливается если обратиться к крипто-хэшу до инициализации ssl. --------------------------- [provider_sect] default = default_sect [default_sect] activate = 1 --------------------------- Это фрагмент openssl.cnf, если activate =1 раскомментировать ошибка уйдет -------------------------- Соответсвенно вопрос уже за рамками моей компетенции, либо включить данный флажок, либо вбивать костыль в qt. Доки в конфиге говорят следующее: If you add a section explicitly activating any other provider(s), you most probably need to explicitly activate the default provider, otherwise it becomes unavailable in openssl. As a consequence applications depending on OpenSSL may not work correctly which could lead to significant system problems including inability to remotely access the system. ------------- В федоре флажок включен из коробки, в дебиане эту секцию вообще не включали, т.е. все по дефолту.
вот тут есть ещё и обсуждение в апстриме этого вопроса: https://github.com/openssl/openssl/issues/16249
(In reply to Anton Farygin from comment #13) > вот тут есть ещё и обсуждение в апстриме этого вопроса: > > https://github.com/openssl/openssl/issues/16249 Тут, если что, речь о том, что можно оставить provider default включённым всегда на тот случай, что кто-то в конфиге включит только legacy, а default при этом явно забудет включить. В целом, это привело к тому, что ошибку, которая есть и у нас и в fedora заметили только мы.
https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/0024-load-legacy-prov.patch
Я нашёл где ошибка, писал сообщение, но ошибка опять висит не на том пакете.
@zerg теперь тебе искать почему в debian эта ошибка не воспроизводится.
(Ответ для Anton Farygin на комментарий #17) > @zerg теперь тебе искать Я уже нашёл. Патч выше.
(Ответ для Anton Farygin на комментарий #17) > почему в debian эта ошибка не воспроизводится. Есть информация, что ни debian ни пакет libqt6-network тут нипричём.
https://git.altlinux.org/gears/q/..git?p=qt6-base.git;a=commitdiff;h=39b0adf662cb186ed4db06c5e0d275b9fe1e06c1
(Ответ для Dmitry V. Levin на комментарий #20) > https://git.altlinux.org/gears/q/..git?p=qt6-base.git;a=commitdiff; > h=39b0adf662cb186ed4db06c5e0d275b9fe1e06c1 Да. Я в курсе.
(Ответ для Anton Farygin на комментарий #17) > почему в debian эта ошибка не воспроизводится. Потому, что в Debian более ущербная сборка openssl, чем в RHEL. P.S. Надеюсь, там хотя бы сменили мантейнера после той дырищи, которую он учинил.
(In reply to Sergey V Turchin from comment #22) > (Ответ для Anton Farygin на комментарий #17) > > почему в debian эта ошибка не воспроизводится. > Потому, что в Debian более ущербная сборка openssl, чем в RHEL. Во всех дистрибутивах, получается? > P.S. > Надеюсь, там хотя бы сменили мантейнера после той дырищи, которую он учинил. О чём речь?
И не забудьте, пожалуйста, повесить багу в апстрим.
(In reply to Sergey V Turchin from comment #21) > (Ответ для Dmitry V. Levin на комментарий #20) > > https://git.altlinux.org/gears/q/..git?p=qt6-base.git;a=commitdiff; > > h=39b0adf662cb186ed4db06c5e0d275b9fe1e06c1 > Да. Я в курсе. На мой взгляд, если новая фича QT_FEATURE_openssl_hash не поддерживает валидный openssl.cnf, то не стоит такую QT_FEATURE включать. Вместо этого следует отрепортить ошибку в QT_FEATURE_openssl_hash, чтобы апстрим её исправил, и чтобы потом её можно было включить.
(Ответ для Gleb F-Malinovskiy на комментарий #23) > О чём речь? https://habr.com/ru/companies/bothub/articles/806377/
(Ответ для Dmitry V. Levin на комментарий #25) > отрепортить ошибку в QT_FEATURE_openssl_hash, чтобы апстрим её исправил, и чтобы потом её можно было включить. Думаю, что после исправления QT_FEATURE_openssl_hash в этом месте openssl станет "не нужон". P.S. Ну и к RHEL у меня доверия больше. Например, в Debian openssl всё подряд пообрублено при сборке. Вот их опции: no-idea no-mdc2 no-rc5 no-ssl3 enable-unit-test no-ssl3-method enable-rfc3779 enable-cms no-capieng no-rdrand enable-tfo enable-zstd enable-zlib enable-fips Кажется, коррелирует с этим https://github.com/openssl/openssl/issues/16996
(Ответ для Sergey V Turchin на комментарий #27) > > отрепортить ошибку в QT_FEATURE_openssl_hash, чтобы апстрим её исправил, и чтобы потом её можно было включить. > Думаю, что после исправления QT_FEATURE_openssl_hash в этом месте openssl > станет "не нужон". Ну, или QT_FEATURE_openssl_hash станет включенной по умолчанию. Сейчас по умолчанию выключена.
qt6-base-6.7.2-alt6 -> sisyphus: Tue Dec 17 2024 Sergey V Turchin <zerg@altlinux> 6.7.2-alt6 - switch to legacy implementation of QCryptographicHash while openssl3 not ready (closes: 48923)
(Ответ для Dmitry V. Levin на комментарий #25) > следует отрепортить ошибку в QT_FEATURE_openssl_hash https://bugreports.qt.io/browse/QTBUG-132271
(In reply to Sergey V Turchin from comment #30) > (Ответ для Dmitry V. Levin на комментарий #25) > > следует отрепортить ошибку в QT_FEATURE_openssl_hash > https://bugreports.qt.io/browse/QTBUG-132271 Я не понимаю, о чём этот баг, но сделай, пожалуйста, багрепорт о том, что qt собранный с опцией DQT_FEATURE_openssl_hash сломан, стоит приложить туда тест, который сделал Олег.
(Ответ для Gleb F-Malinovskiy на комментарий #31) > Я не понимаю, о чём этот баг, но сделай, пожалуйста, багрепорт о том, что qt > собранный с опцией DQT_FEATURE_openssl_hash сломан О том, чтоб они сами это сказали.
(In reply to Sergey V Turchin from comment #32) Сделай, пожалуйста, багрепорт.
(Ответ для Gleb F-Malinovskiy на комментарий #33) > Сделай, пожалуйста, багрепорт. https://bugreports.qt.io/browse/QTBUG-132358
(Ответ для Gleb F-Malinovskiy на комментарий #33) > Сделай, пожалуйста, багрепорт. Ну, ответили они...
> https://bugreports.qt.io/browse/QTBUG-132271 И тут тоже про линковку связанная информация. Получается либо линковка libqt6-core с libssl и поддержка в openssl либо внутренняя реализация соотв. функций, зато libqt6-core свободен от openssl.
(Ответ для Sergey V Turchin на комментарий #34) > https://bugreports.qt.io/browse/QTBUG-132358 Дали нормальный ответ. Теперь вы решайте, надо или нет.
