It's possible that Qt is built with OpenSSL and some other backend.
The ifdefs generated are not mutually exclusive anymore, as it was
in the past. So tests should rely on the actual backend they have
working at runtime.
In the process of fixing the auto-tests, modernized feature #if-ery and
some associated compilation issues.
Fixes: QTBUG-92875
Change-Id: I2be1b924d506fd36dc4e2c6c9158b5023ff87f32
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
QNetworkInterface reports as up and running an interface,
seemingly having a valid IP address which actually has
not IPv4/IPv6 configured at all (this is what getifaddrs
gives us).
Change-Id: I5808d5dfdbc54004a1e02b791917e9b2ba62905f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
For some reason the test case was (no longer?) detected by moc
Change-Id: I20f20de76479f7d9db43fae985cefe0869a7e203
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
To see if a certain method is supported. To be used in an upcoming patch.
Change-Id: I1a5c2f655585331820701bb54f6991b4aba38273
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The BASE argument of qt_add_resources now denotes the root point of the
alias of the file. Before, BASE was merely prepended to every file that
got passed to qt_add_resources.
Old behavior:
qt_add_resources(app "images"
PREFIX "/"
BASE "../shared"
FILES "images/button.png")
Alias is "../shared/images/button.png", and pro2cmake generated
QT_RESOURCE_ALIAS assignments to fix this.
New behavior:
qt_add_resources(app "images"
PREFIX "/"
BASE "../shared"
FILES "../shared/images/button.png")
The alias is "images/button.png". No extra QT_RESOURCE_ALIAS assignment
is needed.
The new behavior is in effect for user projects and for Qt repositories
that define QT_USE_FIXED_QT_ADD_RESOURCE_BASE. Qt repositories will be
ported one by one to this new behavior. Then the old code path can be
removed.
Pick-to: 6.1
Task-number: QTBUG-86726
Change-Id: Ib895edd4df8e97b54badadd9a1c34408beff131f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Already blacklisted on the other linux versions, but is failing on
SLES now in 5.15
Pick-to: 6.1 5.15
Change-Id: I267908adf94ede51e5520aa2cb806b394fb0438e
Reviewed-by: Tarja Sundqvist <tarja.sundqvist@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
And use this in the authenticationRequired test.
Pick-to: 6.1 6.0 5.15
Change-Id: I18e991eb67168214c2c4f829afaca5018568e989
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
With Qt 6 we made HTTP/2 default, which exposed missing handling of
401 Unauthorized (and 407 Proxy Authentication Required).
In HTTP/1.* we would handle this after the response had finished, while
handling the status code. For h2 this path isn't used since it is
heavily reliant on the structure we have for HTTP/1.* (one request per
channel). So we must handle the status code and header directly.
Having that part fixed exposed another issue - when resetting/rewinding
uploaded data we were not resetting the 'totallyUploadedData' counter in
the reply (this, in turn, exposed another small issue). Because of that
we did not actually send any data on the retry, only sending the
content-length followed by no data.
Finally, the small issue mentioned in the previous paragraph was how we
check if we have uploaded all our data. It was only checking if the
byte-device was atEnd(), which it was. But only because it had not yet
prepared any data for us.
Fixes: QTBUG-91284
Pick-to: 6.1 6.0 5.15
Change-Id: I798d105b02688b18a02897cc476f19f57a47f98f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The qt_ForceTlsSecurityLevel symbol is not defined if SSL is not configured,
so don't use it in the QNetworkReply test if it's not.
Change-Id: Id3110a1997fea1648b48bfc411e90e7efe306678
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
All TLS (and non-TLS) backends that QSsl classes rely
on are now in plugins/tls (as openssl, securetransport,
schannel and certonly plugins).
For now, I have to disable some tests that were using OpenSSL
calls - this to be refactored/re-thought. These include:
qsslsocket auto-test (test-case where we work with private keys),
qsslkey auto-test (similar to qsslsocket - test-case working with
keys using OpenSSL calls).
qasn1element moved to plugins too, so its auto-test have to
be re-thought.
Since now we can have more than one working TLS-backend on a given
platform, the presence of OpenSSL also means I force this backend
as active before running tests, to make sure features implemented
only in OpenSSL-backend are tested.
OCSP auto test is disabled for now, since it heavily relies on
OpenSSL symbols (to be refactored).
[ChangeLog][QtNetwork][QSslSocket] QSslSocket by default prefers 'openssl' backend
if it is available.
[ChangeLog][QtNetwork][QSslSocket] TLS-backends are not mutually exclusive anymore,
depending on a platform, more than one TLS backend can be built. E.g., configuring
Qt with -openssl does not prevent SecureTransport or Schannel plugin from being
built.
Fixes: QTBUG-91928
Change-Id: I4c05e32f10179066bee3a518bdfdd6c4b15320c3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
As suggested in the API review.
Amends 37bd7b5733
Pick-to: 6.1 6.1.0
Change-Id: Ic3e8567f349568dc3b4dbf79be27c304b39480cf
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
On Windows, on exit, the backend will deref (and then implicitly start
deletion of) a COM object. This object tries to communicate with an
object in another thread, though it seems this other thread quits before
the main thread in _most_ cases.
To get around this we move the deletion to earlier in the program. While
this is only reported as a Windows issue it makes for more consistent
behavior if all platforms behave the same.
Document and test that recreation of QNI works as expected after the
destruction (and recreation) of QCoreApplication.
Amends: 0875626e22
Fixes: QTBUG-92568
Pick-to: 6.1 6.1.0
Change-Id: Iffc07f38673019aa059efd4d64d2ad706a03f6fe
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
It was more complex than needed in a few places.
Change-Id: I0609423f82420f72c65637cf398ccd7694ee85e5
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The 'pipeBroken' flag must be updated before emitting the readyRead()
signal to avoid deadlock of waitForReadyRead() inside slot connected
to readyRead().
Change-Id: Ie393fdd594c6691da6609ea18307589b7157c624
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Takes advantage of Linux's and Android's support for abstract namespace
when binding sockets, which is independent of the filesystem (see man
entry for unix domain sockets).
To make QLocalServer and QLocalSocket use an abstract socket address,
one needs to set the socket options to QLocalServer::AbstractNamespaceOption.
Fixes: QTBUG-16090
Change-Id: Ia9f9c9cc1ac5c28f9d44b0a48d854a7cfbd39b11
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This can only be completed in Qt 7, due to BC guarantees. I've only
updated the source code for QHostAddress and its unit test and even then
I did not touch the documentation. This needs to be completed in Qt 7.0
Change-Id: I26b8286f61534f88b649fffd166b695882f8f3b5
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
All backend-specific code is now separated and removed
from QSslSocket(Private) code. The original code is mostly
preserved to avoid (as much as possible) regressions (and
to simplify code-review).
Fixes: QTBUG-91173
Task-number: QTBUG-65922
Change-Id: I3ac4ba35d952162c8d6dc62d747cbd62dca0ef78
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit 9391ba55149336c395b866b24dc9b844334d50da)
Renamed the private part of the namespace to QTlsPrivate.
Fixes: QTBUG-91531
Change-Id: Id2d9c458d8d958b35e437eee42889177dad0a7a7
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit e4efa00c72c7011f4e5c27722c2a522b30274610)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This is to avoid false positives.
By default files are large if uncompressed size > 10 MB. Only configurable internally.
Also add auto tests.
Task-number: QTBUG-91392
Pick-to: 6.0 6.1
Change-Id: I32258cb7c957f2a23a05157ba4ed5c0af2ba585e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It's a bit weird to calculate timeout in milliseconds and then pass
it as number of seconds ...
Pick-to: 6.1 5.15
Change-Id: I1127163ea06e49ac1b53eea6f60ee8590319bfa1
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
When a foreign event loop that does not enter an alertable wait state
is running (which is also the case when a native dialog window is
modal), pipe handlers would freeze temporarily due to their APC
callbacks not being invoked.
We address this problem by moving the I/O callbacks to the Windows
thread pool, and only posting completion events to the main loop
from there. That makes the actual I/O completely independent from
any main loop, while the signal delivery works also with foreign
loops (because Qt event delivery uses Windows messages, which foreign
loops typically handle correctly).
As a nice side effect, performance (and in particular scalability)
is improved.
Several other approaches have been tried:
1) Using QWinEventNotifier was about a quarter slower and scaled much
worse. Additionally, it also required a rather egregious hack to
handle the (pathological) case of a single thread talking to both
ends of a QLocalSocket synchronously.
2) Queuing APCs from the thread pool to the main thread and also
posting wake-up events to its event loop, and handling I/O on the
main thread; this performed roughly like this solution, but scaled
half as well, and the separate wake-up path was still deemed hacky.
3) Only posting wake-up events to the main thread from the thread pool,
and still handling I/O on the main thread; this still performed
comparably to 2), and the pathological case was not handled at all.
4) Using this approach for reads and that of 3) for writes was slightly
faster with big amounts of data, but scaled slightly worse, and the
diverging implementations were deemed not desirable.
Fixes: QTBUG-64443
Change-Id: I66443c3021d6ba98639a214c3e768be97d2cf14b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
This patch marks some functions "override" to silence the corresponding
warning.
Change-Id: I88ccc5fa7521ecccc84a6cba9f06ea185cc5679e
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The idea is to have QSslKey(Private) backend-neutral and hide
all library-specific code inside plugins.
Fixes: QTBUG-90953
Task-number: QTBUG-65922
Change-Id: I2eeee3b2b72c78c2e24f2fb914abce3caa913be8
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit 0352cf8e1bf57615b9faf3f6f383896444e762ac)
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The emulation detection has been usable only on qtbase tests, move it to
QTest so that it can be used in other modules as well.
Pick-to: 6.1
Change-Id: I4b2321b7856414d7b1cfd5e6b1405a633c6bb878
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
QTlsBackend is a factory itself - it creates TLS/X509 objects. Having
an intermediary between Factory->Backend->TLS primitive does not look
very natural thus let's squash the first two parts. Backend is a factory
creating TLS primitives, but its static functions also provide information
about backends availablei and give access to those backends.
Fixes: QTBUG-90606
Task-number: QTBUG-65922
Change-Id: I8409d81fd11fb46e6ab4465b4937a7680a8c2447
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Read/write/notify properties, 3 out of 5 defined in this class.
Task-number: QTBUG-85520
Change-Id: Ic6c74f90a2fa3c71d71cf9a5d557f1b6fc489d35
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Fetched from the authoritative source, verified the content matches
that of the current master revision in the github repository.
Amend one cookie jar test to find the last group in the last chunk
correctly - each group arises from a non-empty hsah-table entry, but
the last few hash-table entries may be empty, in which case the last
group isn't just before the last index, it's earlier by the number of
empty hash table entries. In the process, amend this test and the
related test of the end of the first chunk to iterate all the entries
in the group (in the present version, as it happens, each end-group
has just one entry, but that may vary).
Task-number: QTBUG-90214
Pick-to: 6.0 5.15
Change-Id: I6da365a6ca558124f8275e392735071dc77e04bb
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This is an abstraction for TLS backend and its factory, preparing to transition
to plugin-based design.
Task-number: QTBUG-65922
Change-Id: Ibe810e77fd1b715a6bea66cd3f44312b015ac274
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This API gives the names of available backends and provides a basic
information about features/protocols supported by those backends.
Also, it has the 'loadBackend' functions which allow to select
a particular backend (which are becoming plugins).
At the moment, the implementation is still 'hardcoded', the
follow-up patch will allow to select different backends in runtime.
Task-number: QTBUG-65922
Change-Id: I05877de9c02857594e76b24d52e7578bdb01df69
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The plugins are meant to indicate what they do support, meaning users of
QNetworkInformation can choose to not care about which plugin is used
and rather just request what they want.
Task-number: QTBUG-86966
Change-Id: Ie130e1791250ec2a4470e3ba7081d982654af06c
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Those serve no purpose anymore, now that the .pro files are gone.
Task-number: QTBUG-88742
Change-Id: I39943327b8c9871785b58e9973e4e7602371793e
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
SecureTransport does not allow deprecated digest algorithms, and
(depending on ST version) it may or may not accept our server's
certificate.
Funnily enough, they 'fluctuate' between versions again and again.
Fixes: QTBUG-89922
Change-Id: Ie5fbfca316806bd5000ce2d128b81b718bb36624
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Remove the qmake project files for most of Qt.
Leave the qmake project files for examples, because we still test those
in the CI to ensure qmake does not regress.
Also leave the qmake project files for utils and other minor parts that
lack CMake project files.
Task-number: QTBUG-88742
Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Complete search and replace of QtTest and QtTest/QtTest with QTest, as
QtTest includes the whole module. Replace all such instances with
correct header includes. See Jira task for more discussion.
Fixes: QTBUG-88831
Change-Id: I981cfae18a1cabcabcabee376016b086d9d01f44
Pick-to: 6.0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
SIOCGIFNAME is now supported on QEMU.
This reverts commit 42b3ed763f.
Change-Id: I79caa371dc798464ab76851d2ea3189ec9eb0c57
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Apparently some library definitions went overboard, link them directly.
Pick-to: 6.0
Change-Id: I009737f7e3edff5619241b700a627dc4e25e6018
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Looking at grafana it rarely fails in dev so unblacklisting it.
Though it is a little more flaky after switching to http 2 by default
because then we only have one channel and more requests end up queued in
the same channel, which will get errored out when the server
disconnects.
Task-number: QTBUG-88943
Change-Id: If5d6335864ce6bbc35f519b2c6d7068e4181afd2
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
headFromHttp hasn't been flaky since 5.14 times according to grafana,
does not fail locally.
Same situation with ioHttpRedirect as above.
ioHttpRedirectMultipartPost has not failed on Windows since october
2019, assumed stable now.
backgroundRequestInterruption no longer exists.
ioPostToHttpFromSocket would fail in debug MSVC builds but was
fixed in 710886fbdd.
Task-number: QTBUG-88943
Change-Id: Ida640179ef15a3452291745e4e94a71a385f57ae
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The test in general is fine, but it was making an assumption that the
first 5 readyRead emissions would never result in the whole message
being received. In certain scenarios with slowdown however it was still
possible that we would receive the whole message after just a few
readyReady emissions. While I didn't check it's most likely due to a
mechanic in the QNetworkReply machinery where we suppress some
emissions if we know there's more data just about to be available.
Task-number: QTBUG-88943
Change-Id: I0cf06edb34d4e86cc8a42c0f1cd7e8c35765f6ee
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
It's not _wrong_ to time out when connecting to something unreachable
(it's just a different way of handling it) so we shouldn't fail when
this happens either.
In local testing (windows) it times out after 8 seconds, so bump
the timer to 10 seconds. On systems where it's faster there'll be
no difference as long as things don't go wrong.
Pick-to: 6.0
Fixes: QTBUG-89089
Change-Id: I8437cf8e4fbecedea2391ed87fdce1213085b964
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Which contains a lot of 'macos'/'osx' black-listed auto-tests. They
mostly fail with SecureTransport (on BigSur) because SecTrustEvaluate()
does not like our old certificate. Instead, since SecureTransport
is deprecated anyway and we are not planning to develop it in future,
skip the related auto-test depending on QT_CONFIG(securetransport).
Task-number: QTBUG-88943
Change-Id: I5f6cb7b2d0ea15c445603c1ff3e1700f123c28d1
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
