Bug 48923 - Оключение tls в qt6.6
Summary: Оключение tls в qt6.6
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: libqt6-core (show other bugs)
Version: unstable
Hardware: x86_64 Linux
: P5 normal
Assignee: Sergey V Turchin
QA Contact: qa-sisyphus
URL:
Keywords:
: 51318 52068 52115 (view as bug list)
Depends on:
Blocks: 46625 51318
  Show dependency tree
 
Reported: 2023-12-25 16:49 MSK by proskurinov@basealt.ru
Modified: 2025-01-15 15:36 MSK (History)
11 users (show)

See Also:


Attachments
Тест для демонстрации ошибок (1.07 KB, text/x-c++src)
2023-12-25 16:49 MSK, proskurinov@basealt.ru
no flags Details
digikam (75.77 KB, image/png)
2024-11-18 15:29 MSK, Alexander Makeenkov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description proskurinov@basealt.ru 2023-12-25 16:49:09 MSK
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
```
Comment 1 proskurinov@basealt.ru 2023-12-25 17:15:48 MSK
OpenSSL 3.1.4 24 Oct 2023 (Library: OpenSSL 3.1.4 24 Oct 2023)
Comment 2 Gleb F-Malinovskiy 2024-02-16 17:29:26 MSK
(In reply to proskurinov@basealt.ru from comment #0)
> Закомментирован флаг инициализации ( в Fedora включен из коробки,в Debian -
> деволтный конфиг.)
Получается, в Debian это тоже не работает?  В апстримном конфиге activate закомментирован, да и в целом в этом месте наш конфиг ничем не отличается от апстримного.
Comment 3 Gleb F-Malinovskiy 2024-02-16 18:30:38 MSK
Нет, в Debian работает, в том числе с нынешним конфигом из Сизифа.
Я считаю, что это значит, что проблема вовсе не в конфиге потому что разница точно не только в нём.
Comment 4 Sergey V Turchin 2024-11-14 11:37:38 MSK
$ 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.
Если конфиг поправить, то всё ок.
Comment 5 Sergey V Turchin 2024-11-18 10:01:27 MSK
*** Bug 52068 has been marked as a duplicate of this bug. ***
Comment 6 Sergey V Turchin 2024-11-18 10:23:53 MSK
(Ответ для Gleb F-Malinovskiy на комментарий #3)
> проблема вовсе не в конфиге потому что разница точно не только в нём.
По крайней мере, я ни у кого не видел никаких патчей на qtbase про ssl.
Comment 7 Alexander Makeenkov 2024-11-18 15:29:28 MSK
Created attachment 17202 [details]
digikam

При первом запуске digikam предлагается скачать необходимые файлы и возникает ошибка.
Помогает включение параметра `activate = 1` в конфиге openssl.
Comment 8 Sergey V Turchin 2024-11-18 16:03:21 MSK
*** Bug 51318 has been marked as a duplicate of this bug. ***
Comment 9 Sergey V Turchin 2024-11-20 15:27:24 MSK
*** Bug 52115 has been marked as a duplicate of this bug. ***
Comment 10 Sergey V Turchin 2024-12-16 14:37:50 MSK
У меня разобраться не получается. Всё, что смог найти -- отсутствие каких-либо патчей или опций сборки хоть как-то связанных с openssl в debian, fedora и suse.
Comment 11 Anton Farygin 2024-12-16 14:41:13 MSK
$ 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)


Ну вывод об ошибке определённо изменился.
Comment 12 proskurinov@basealt.ru 2024-12-16 14:58:04 MSK
Прикладываю копипасту из задачи 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.
-------------
В федоре флажок включен из коробки, в дебиане эту секцию вообще не включали, т.е. все по дефолту.
Comment 13 Anton Farygin 2024-12-16 15:00:08 MSK
вот тут есть ещё и обсуждение в апстриме этого вопроса:

https://github.com/openssl/openssl/issues/16249
Comment 14 Gleb F-Malinovskiy 2024-12-16 16:10:15 MSK
(In reply to Anton Farygin from comment #13)
> вот тут есть ещё и обсуждение в апстриме этого вопроса:
> 
> https://github.com/openssl/openssl/issues/16249
Тут, если что, речь о том, что можно оставить provider default включённым всегда на тот случай, что кто-то в конфиге включит только legacy, а default при этом явно забудет включить.

В целом, это привело к тому, что ошибку, которая есть и у нас и в fedora заметили только мы.
Comment 16 Gleb F-Malinovskiy 2024-12-16 16:36:42 MSK
Я нашёл где ошибка, писал сообщение, но ошибка опять висит не на том пакете.
Comment 17 Anton Farygin 2024-12-16 17:59:08 MSK
@zerg теперь тебе искать почему в debian эта ошибка не воспроизводится.
Comment 18 Sergey V Turchin 2024-12-16 18:49:25 MSK
(Ответ для Anton Farygin на комментарий #17)
> @zerg теперь тебе искать
Я уже нашёл. Патч выше.
Comment 19 Sergey V Turchin 2024-12-16 18:50:46 MSK
(Ответ для Anton Farygin на комментарий #17)
> почему в debian эта ошибка не воспроизводится.
Есть информация, что ни debian ни пакет libqt6-network тут нипричём.
Comment 21 Sergey V Turchin 2024-12-17 09:40:23 MSK
(Ответ для Dmitry V. Levin на комментарий #20)
> https://git.altlinux.org/gears/q/..git?p=qt6-base.git;a=commitdiff;
> h=39b0adf662cb186ed4db06c5e0d275b9fe1e06c1
Да. Я в курсе.
Comment 22 Sergey V Turchin 2024-12-17 09:42:19 MSK
(Ответ для Anton Farygin на комментарий #17)
> почему в debian эта ошибка не воспроизводится.
Потому, что в Debian более ущербная сборка openssl, чем в RHEL.

P.S.
Надеюсь, там хотя бы сменили мантейнера после той дырищи, которую он учинил.
Comment 23 Gleb F-Malinovskiy 2024-12-17 10:12:03 MSK
(In reply to Sergey V Turchin from comment #22)
> (Ответ для Anton Farygin на комментарий #17)
> > почему в debian эта ошибка не воспроизводится.
> Потому, что в Debian более ущербная сборка openssl, чем в RHEL.
Во всех дистрибутивах, получается?

> P.S.
> Надеюсь, там хотя бы сменили мантейнера после той дырищи, которую он учинил.
О чём речь?
Comment 24 Gleb F-Malinovskiy 2024-12-17 10:12:35 MSK
И не забудьте, пожалуйста, повесить багу в апстрим.
Comment 25 Dmitry V. Levin 2024-12-17 10:17:29 MSK
(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, чтобы апстрим её исправил, и чтобы потом её можно было включить.
Comment 26 Sergey V Turchin 2024-12-17 10:40:43 MSK
(Ответ для Gleb F-Malinovskiy на комментарий #23)
> О чём речь?
https://habr.com/ru/companies/bothub/articles/806377/
Comment 27 Sergey V Turchin 2024-12-17 10:58:22 MSK
(Ответ для 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
Comment 28 Sergey V Turchin 2024-12-17 11:33:57 MSK
(Ответ для Sergey V Turchin на комментарий #27)
> > отрепортить ошибку в QT_FEATURE_openssl_hash, чтобы апстрим её исправил, и чтобы потом её можно было включить.
> Думаю, что после исправления QT_FEATURE_openssl_hash в этом месте openssl
> станет "не нужон".
Ну, или QT_FEATURE_openssl_hash станет включенной по умолчанию. Сейчас по умолчанию выключена.
Comment 29 Repository Robot 2024-12-17 11:54:18 MSK
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)
Comment 30 Sergey V Turchin 2024-12-17 12:00:44 MSK
(Ответ для Dmitry V. Levin на комментарий #25)
> следует отрепортить ошибку в QT_FEATURE_openssl_hash
https://bugreports.qt.io/browse/QTBUG-132271
Comment 31 Gleb F-Malinovskiy 2024-12-17 13:56:47 MSK
(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 сломан, стоит приложить туда тест, который сделал Олег.
Comment 32 Sergey V Turchin 2024-12-17 14:24:52 MSK
(Ответ для Gleb F-Malinovskiy на комментарий #31)
> Я не понимаю, о чём этот баг, но сделай, пожалуйста, багрепорт о том, что qt
> собранный с опцией DQT_FEATURE_openssl_hash сломан
О том, чтоб они сами это сказали.
Comment 33 Gleb F-Malinovskiy 2024-12-18 16:45:18 MSK
(In reply to Sergey V Turchin from comment #32)

Сделай, пожалуйста, багрепорт.
Comment 34 Sergey V Turchin 2024-12-19 13:29:43 MSK
(Ответ для Gleb F-Malinovskiy на комментарий #33)
> Сделай, пожалуйста, багрепорт.
https://bugreports.qt.io/browse/QTBUG-132358
Comment 35 Sergey V Turchin 2025-01-13 15:28:16 MSK
(Ответ для Gleb F-Malinovskiy на комментарий #33)
> Сделай, пожалуйста, багрепорт.
Ну, ответили они...
Comment 36 Sergey V Turchin 2025-01-13 15:46:59 MSK
> https://bugreports.qt.io/browse/QTBUG-132271
И тут тоже про линковку связанная информация.

Получается либо
линковка libqt6-core с libssl и поддержка в openssl
либо
внутренняя реализация соотв. функций, зато libqt6-core свободен от openssl.
Comment 37 Sergey V Turchin 2025-01-15 15:36:13 MSK
(Ответ для Sergey V Turchin на комментарий #34)
> https://bugreports.qt.io/browse/QTBUG-132358
Дали нормальный ответ. Теперь вы решайте, надо или нет.