Bug 48923
| Summary: | Оключение tls в qt6.6 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | proskurinov <proskurinov> | ||||||
| Component: | libqt6-core | Assignee: | Sergey V Turchin <zerg> | ||||||
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||||
| Severity: | normal | ||||||||
| Priority: | P5 | CC: | amakeenk, george, glebfm, iv, ldv, lvol, mail, me, nenderus, rider, zerg | ||||||
| Version: | unstable | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| See Also: | https://bugzilla.altlinux.org/show_bug.cgi?id=49598 | ||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 46625, 51318 | ||||||||
| Attachments: |
|
||||||||
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 заметили только мы. Я нашёл где ошибка, писал сообщение, но ошибка опять висит не на том пакете. @zerg теперь тебе искать почему в debian эта ошибка не воспроизводится. (Ответ для Anton Farygin на комментарий #17) > @zerg теперь тебе искать Я уже нашёл. Патч выше. (Ответ для Anton Farygin на комментарий #17) > почему в debian эта ошибка не воспроизводится. Есть информация, что ни debian ни пакет libqt6-network тут нипричём. (Ответ для 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 Дали нормальный ответ. Теперь вы решайте, надо или нет. Бомбочка сработала. ;-) https://codereview.qt-project.org/c/qt/qtbase/+/696212 |
Description
proskurinov@basealt.ru 2023-12-25 16:49:09 MSKCreated 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 ```