ALT Linux Bugzilla – #48923

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
Дали нормальный ответ. Теперь вы решайте, надо или нет.

Бомбочка сработала. ;-) https://codereview.qt-project.org/c/qt/qtbase/+/696212