QNetworkAccessManager, HTTPS и OpenSSL в 2018 году - давайте таки разберемся

По поводу зависимостей:

// файл project.pro
// добавляем к QMAKE_RPATHDIR значение lib
QMAKE_RPATHDIR += lib

Как заставить работать QNetworkAccessManager на Linux?

А он разве не работает? То что ты процитировал - предупреждения, не ошибки. Нужны конкретные ошибки от QNetworkAccessManager. Ты обрабатываешь сигнал sslErrors()?

Вот тестовый пример от EXL.

https://github.com/EXLMOTODEV/NetworkManagerDemo

Он говорит что у него работает. А на моем линухе при нажатии Go в консоль выдаются предупреждения, и скачивания не происходит:

Запускается /build-NetworkManagerDemo-Desktop_Qt_5_10_1_GCC_64bit-Debug/NetworkManagerDemo...
qt.network.ssl: QSslSocket: cannot resolve CRYPTO_num_locks
qt.network.ssl: QSslSocket: cannot resolve CRYPTO_set_id_callback
qt.network.ssl: QSslSocket: cannot resolve CRYPTO_set_locking_callback
qt.network.ssl: QSslSocket: cannot resolve ERR_free_strings
qt.network.ssl: QSslSocket: cannot resolve EVP_CIPHER_CTX_cleanup
qt.network.ssl: QSslSocket: cannot resolve EVP_CIPHER_CTX_init
qt.network.ssl: QSslSocket: cannot resolve sk_new_null
qt.network.ssl: QSslSocket: cannot resolve sk_push
qt.network.ssl: QSslSocket: cannot resolve sk_free
qt.network.ssl: QSslSocket: cannot resolve sk_num
qt.network.ssl: QSslSocket: cannot resolve sk_pop_free
qt.network.ssl: QSslSocket: cannot resolve sk_value
qt.network.ssl: QSslSocket: cannot resolve SSL_library_init
qt.network.ssl: QSslSocket: cannot resolve SSL_load_error_strings
qt.network.ssl: QSslSocket: cannot resolve SSL_get_ex_new_index
qt.network.ssl: QSslSocket: cannot resolve SSLv3_client_method
qt.network.ssl: QSslSocket: cannot resolve SSLv23_client_method
qt.network.ssl: QSslSocket: cannot resolve SSLv3_server_method
qt.network.ssl: QSslSocket: cannot resolve SSLv23_server_method
qt.network.ssl: QSslSocket: cannot resolve X509_STORE_CTX_get_chain
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_add_all_algorithms_noconf
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_add_all_algorithms_conf
qt.network.ssl: QSslSocket: cannot resolve SSLeay
qt.network.ssl: Incompatible version of OpenSSL
qt.network.ssl: QSslSocket: cannot call unresolved function SSLv23_client_method
qt.network.ssl: QSslSocket: cannot call unresolved function SSL_CTX_new
qt.network.ssl: QSslSocket: cannot call unresolved function SSL_library_init
qt.network.ssl: QSslSocket: cannot call unresolved function ERR_get_error
qt.network.ssl: QSslSocket: cannot call unresolved function ERR_get_error

Incompatible version of OpenSSL

Попробуй поставить дефолтный Qt в своём Debian. Он почти наверняка работает нормально.

Qt и OpenSSL из системы или самосборные?

Qt 5.10.1 с официального сайта, поставлен вручную.

OpenSSL из системы, версия 1.1.0f-3+deb9u2.

Впрочем, та же проблема и на Qt 5.9.x.

запускать очевидно надо с той же версией OpenSSL, с которой конпелялся Qt, что в данном случае скорей всего не так

Как же пользоваться Qt, который установлен с официального сайта и HTTPS? Вообще никак?

В дистрах Linux часто есть несколько версий SSL библиотек. Если ты поставил openssl 1.1.0, то думаю автоматом установился libssl1.1. Попробуй поставь libssl1.0.2.

QMAKE_RPATHDIR += lib

Это круто. А давно такая опция есть? Правильно понимаю, что это runtime каталог для либ?

Если ты поставил openssl 1.1.0, то думаю автоматом установился libssl1.1. Попробуй поставь libssl1.0.2.

У меня и то и то установлено:

> aptitude -F "%c%a%M%S %p %Z %v %V" search ssl | grep "^i"
i    libssl1.0.2  1.0.2l-2+deb9u3 1.0.2l-2+deb9u3
i    libssl1.1    1.1.0f-3+deb9u2 1.1.0f-3+deb9u2
i A  openssl      1.1.0f-3+deb9u2 1.1.0f-3+deb9u2

Мои предположения закончились. Предлагаю стандартно - запилить баг-репорт :) Так с дефолтным Qt https работает или нет?

dpkg -l | grep openssl
ii    openssl    1.1.0f-3+deb9u2    amd64    Secure Sockets Layer toolkit - cryptographic utility

Qt-проекты, использующие SSL собираются и даже работают, защищенное соединение устанавливается. Как с Qt 5.9.0 (скачано с офсайта), так и с Qt 5.7.1 (из репозиториев).

Ну я щас раздумываю, поставить дефолтный Qt или нет. Как то я ставил несколько Qt, аккуратно, в разные каталоги, но в Qt есть автопоиск, и помню в какой-то момент один Qt подцепил куски и документацию от другого Qt, получился бардак.

Qt-проекты, использующие SSL собираются и даже работают, защищенное соединение устанавливается. Как с Qt 5.9.0 (скачано с офсайта), так и с Qt 5.7.1 (из репозиториев).

Проверь в Qt 5.9.0 на проекте:

https://github.com/EXLMOTODEV/NetworkManagerDemo

Правда, видимо, он может подхватить системный кусок SSL, установленный вместе с Qt 5.7.1, если у тебя все работает.

У меня на Debian 9 Stable 64 bit ни Qt 5.9.0, ни Qt 5.10.1 с HTTPS не работают (Qt из репозитария еще не ставил).

Немного обновил проект по ссылке.

Официальный Qt (не из реп) собран с OpenSSL 1.0.x, так что вам нужно прокинуть путь именно до этой версии библиотеки, у вас она видимо уже установлена и имеет версию 1.0.2l. Это можно сделать, например, с помощью переменной окружения LD_LIBRARY_PATH.

В Arch Linux, работает так:

$ git clone https://github.com/EXLMOTODEV/NetworkManagerDemo
$ cd NetworkManagerDemo/
$ /opt/Qt5.10.1/5.10.1/gcc_64/bin/qmake NetworkManagerDemo.pro
$ make
$ ls /usr/lib/openssl-1.0/ -al
total 256
drwxr-xr-x   4 root root   4096 Apr  9 16:17 .
drwxr-xr-x 203 root root 245760 May 19 22:59 ..
drwxr-xr-x   2 root root   4096 Apr  9 16:17 engines
lrwxrwxrwx   1 root root     21 Mar 31 23:45 libcrypto.so -> ../libcrypto.so.1.0.0
lrwxrwxrwx   1 root root     18 Mar 31 23:45 libssl.so -> ../libssl.so.1.0.0
drwxr-xr-x   2 root root   4096 Apr  9 16:17 pkgconfig
LD_LIBRARY_PATH=/usr/lib/openssl-1.0/:$LD_LIBRARY_PATH ./NetworkManagerDemo
<всё работает>

Заметьте, что библиотеки, которые расположены по указанному пути, должны называться именно как libcrypto.so и libssl.so, а не libcrypto.so.1.0.0 и libssl.so.1.0.0, кстати, проблем с опакеченым мейнтейнерами Qt'ом быть не должно.

Хм, в моем случае из пакета libssl1.0.2 устанавливаются файлы:

/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.2

/usr/lib/x86_64-linux-gnu/openssl-1.0.2

ln -s ../libcrypto.so.1.0.2 libcrypto.so
ln -s ../libssl.so.1.0.2 libssl.so

LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/openssl-1.0.2/:$LD_LIBRARY_PATH ./NetworkManagerDemo

qt.network.ssl: QSslSocket: cannot resolve SSLv3_client_method
qt.network.ssl: QSslSocket: cannot resolve SSLv3_server_method

В таком виде заработало, только в выхлопе появляются предупреждения:

Это нормально.

Не знаю точно. Скорее всего не очень давно, т.к. в первых версиях Qt5 это не работало и нужно было устанавливать RPATH по другому.

Правильно понимаю, что это runtime каталог для либ?

Правильно, но я бы выразился так: этот параметр для qmake, который устанавливает в исполняемом файле значение RPATH. RPATH - специальный параметр в исполняемом файле, который определяет список каталогов, в которых ищутся динамические библиотеки при выполнении.

Вот же здорово, а я парился... И основной каталог либами засирал.

Да. Пожалуйста, распространяй приложение со своими либами. И никакого ада зависимостей, вообще с точки зрения того, что любую программу можно поставлять вместе с требуемыми библиотеками, используя параметр rpath в исполняемом файле, не понимаю всю эту шумиху про проблемы зависимостей, необходимость всяких AppImage и прочее...

Проблема только в том, что когда выйдет очередной heartbleed, все поставляльщики приложений со своими либами должны будут срочно обновить себе либу и приложение клиентам.

Запускается.

SSL version use for build: OpenSSL 1.0.1e-fips 11 Feb 2013
SSL version use for run-time: OpenSSL 1.0.2l  25 May 2017
SSL support: 1

Пожалуйста, распространяй приложение со своими либами. И никакого ада зависимостей

Если ядро вообще сможет этот бинарник и либу запустить, и libc будет нужной версии, а это никто гарантировать не может.

Если ядро вообще сможет этот бинарник и либу запустить

а что, может не смочь?

и libc будет нужной версии, а это никто гарантировать не может.

У glibc полная обратная совместимость, код собранный со старой версией всегда заработает с более новой

Да гарантий нет. И то, что бинарник некоторые будут в винде запускать пробовать...

В Ubuntu достаточно написать:

sudo apt install libssl1.0-dev

Не то, чтобы я некропостер, просто проблема до сих пор актуальна.

И что, из dev-пакета будут *.so-файлы библитотек устанавливаться?

И что, из dev-пакета будут *.so-файлы библитотек устанавливаться?

А как иначе? К чему линковаться или что открывать через dlopen?

Практически у всех dev-пакетов в зависимостях бинарные пакеты без префикса dev.

И этот не исключение: https://packages.ubuntu.com/bionic/libssl1.0-dev

depends:

libssl1.0.0

А, ну если по зависимостям...

dev-пакеты для того и предназначены, что устанавливают всё нужное для разработки: как *.so или *.a файлы, так и *.h

Я почему-то помнил что только .a и .h файлы, если речь про c/cpp либы. Ну да ладно.

ну, одним словом — дебиан. это надо иметь определённый склад ума, чтобы им пользоваться, да ещё и при разработке. придумали какую-то мифическую стабильность, а на деле — куча багов, сплошные несовместимости и утаревший софт, которым невозможно нормально пользоваться. и вместо того, чтобы делать что-то полезное, разработчики дебиана делают дебиан, борясь с ветряными мельницами.

sudo apt install libssl1.0-dev

Уточнение. В Debian 9, оказывается, есть два взаимоисключающих пакета: libssl.dev и libssl1.0-dev. Одновременно они не могут быть установлены, а так же каждый стирает линки на файлы у другого.

В нашем случае нужно, чтобы стоял пакет libssl1.0-dev.