This change makes the PREFIX parameter a required parameter if the
target does not specify a default. This way the behavior is clear when
reading the code: add_qt_resource() without PREFIX means it must come
frmo the target.
Change-Id: I79024e70e7b4d32a5164b93aa08ec9ff409b2d39
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
The direct use of pthread_yield() requires pthread linkage, which --
according to the cmake docs -- is best done by using CMake's
Threads::Threads target and the -pthread compiler flag preference.
Change-Id: Iacbd7dfce3ee2f792cea7f58d52b6b8ba8a84b18
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
some assumptions were incorrect: our test server immediately sends
its SETTINGS frame, as a result we have to reply with client preface +
SETTINGS(ACK). So QVERIFY(!prefaceOK) was wrong from the beginning and
was only passing by pure luck.
Change-Id: Ie43f0d4ac41deb0e5339badaae6149a9b2f9d9b3
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This show cases the new cleaner subdirs handling code in
pro2cmake.
Change-Id: I25001942ef020e4c4191b355f55309c4fb033ecc
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
One of the tests above was unsetting a variable that enforces
the use of a temporary keychain. We have to set it back, otherwise
the test is failing. What surprises me though - why I had this
problem only locally and not on CI? Apparently, SecureTransport
is not covered by our configurations ...
Change-Id: I0ff1e3e304632869391ed61213c245b949d8c778
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This change removes the leftovers form other cleanup commits.
Task-number: QTBUG-76491
Change-Id: I61440f87c5a280f9666b78e19aac4d8ac603767e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
QT_SOURCE_TREE is a variable that is set in qtbase/.qmake.conf.
In qtbase, it's used throughout various
projects to find cpp sources when building standalone tests (among
other things).
Everything works fine with qmake, because even if qmake is invoked
on the tests subfolder, qmake searches up the source directory tree
until it finds a .qmake.conf file, and uses that.
When building qttools with qmake, the qdoc project expects
to have a QT_SOURCE_TREE value, but it's not actually set in the
qttools/.qmake.conf file, so the generated include paths that use
that value are incorrect. Curiously the build still succeeds.
Now in CMake land we replaced QT_SOURCE_TREE with
CMAKE_SOURCE_DIR, but that does not work properly when doing a
standalone tests build, because the project in that case is the
tests one, and not the qtbase one, so configuration fails in a
developer build when trying to configure some private tests.
So far I've found that only qtbase actively uses this value.
A temporary fix is to save the qtbase source directory into a
QT_SOURCE_TREE variable inside the generated
BuildInternalsExtra.cmake file.
The pro2cmake script is changed to handle presence of QT_SOURCE_TREE
in a qrc file path. This is handled by finding the location of a
.qmake.conf file starting from the project file absolute path.
This is needed to stop the script from crashing when handling
the mimedatabase test projects for example.
The change also regenerates the relevant failing test projects, and
thus standalone tests (when doing developer builds aka private_tests
enabled) now configure and build successfully.
Change-Id: I15adc6f4ab6e3056c43ed850196204e2229c4d98
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Passes locally, and there is no reason why it shoulnd't. Use IPv6
addresses for Google and Cloudflare DNS servers, and as with the IPv4
tests, rely on Python and (as a fallback) nslookup to produce the
reference.
Change-Id: I584f8ae9bc89c66a1f59d7b1e7493d0ed8033e8a
Fixes: QTBUG-22287
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Lookups performed via QHostInfoRunnable must not synchronously call
the user-code's receiver objects, as that would execute user-code in
the wrong thread. Instead, post a metacall event through the event
loop of the receiver object, or the thread that initiated the lookup.
This was done correctly for the trivial cases of empty host name or
cached results, so the code generally existed. By moving it from a
global function into a member function of QHostInfoResult, we can
simply access the required data to construct and post the event.
As we process that posted event, we need to check that the context
object (which is already guarded via QPointer) is still alive, if
we had one in the first place. If we had one, and it's deleted, then
abort.
[ChangeLog][QtNetwork][QHostInfo] Functors used in the lookupHost
overloads are now called correctly in the thread of the context object.
When used without context object, the thread that initiates the lookup
will run the functor, and is required to run an event loop.
Change-Id: I9b38d4f9a23cfc4d9e07bc72de2d2cefe5d0d033
Fixes: QTBUG-76276
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QNetworkAccessManager::connectToHostEncrypted()/connectToHost()
creates 'fake' requests with pseudo-schemes 'preconnect-https'/
'preconnect-http'. QHttp2ProtocolHandler should handle this
requests in a special way - reporting them immediately as
finished (so that QNAM emits finished as it does in case of
HTTP/1.1) and not trying to send anything.
We also have to properly cache the connection - 'https' or
'http' scheme is too generic - it allows (unfortunately)
mixing H2/HTTP/1.1 in a single connection in case an attribute
was missing on a request, which is wrong.
h2c is more complicated, since it needs a real request
to negotiate the protocol switch to H2, with the current
QNetworkHttpConnection(Channel)'s design it's not possible
without large changes (aka regressions and new bugs introduced).
Auto-test extended.
Fixes: QTBUG-77082
Change-Id: I03467673a620c89784c2d36521020dc9d08aced7
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Deprecated APIs of network lib are used only in tests. This change
makes sure, that the tests build and pass with those deprecated APIs
removed or disabled, by:
- Making the parts of the tests testing the deprecated APIs to be
compiled conditionally, only when the corresponding methods are
enabled.
- If the test-case tests only the deprecated API, but not the
corresponding replacement, added tests for the replacement.
Task-number: QTBUG-76541
Change-Id: I78c4913155007fd1d0df2c38e1b9a8b80066adeb
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
warning C4573: the usage of 'tst_QNetworkReply::connect' requires the
compiler to capture 'this' but the current default capture mode does not
allow it
Change-Id: Ic9fd526fedf7c52e53e2b1136834c10bf4cd0ea9
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
It's not implemented
Change-Id: I56abb0a5fe0e6d5c2f5f678adadafed395456902
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
1. Use per-case QNAM objects
2. In a slots (connected to QNetworkReplies) - if an error detected - stop
the event loop (no reason to continue waiting) and then do normal
QVERIFY/QCOMPARE things.
3. In tests, check QTest::currentTestFailed after the event loop returned -
if an error was detected by a slot, no need to continue with QCOMPARE/QVERIFY
in the test itself.
Task-number: QTBUG-77053
Change-Id: I3827a629a2749becd3dc6eee7fd6994d96441e65
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
fix the bloody test for good - the idea to have a shared QNAM (shared
by test cases in this test) was somewhat wrong to start with.
Fixes: QTBUG-77053
Change-Id: I5755e96ec988e2dd546f527f3f902fc43914b0b7
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
As in QVarLengthArray (c34242c679), this will
probably bite someone someday, so fix it before there's a bug report.
Use ctor delegation to keep code size increase small.
There's also the benefit that default-constructing a QNetworkRequest now
no longer creates an expensive QUrl object just to destroy it unused again.
Add an auto-test.
Change-Id: I5ceb5402ca3946048d695244d1b1c36564a1e80a
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Conflicts:
configure.pri
Also required s/solid\.color/solidColor/ in a couple of places in:
src/gui/painting/qpaintengine_raster.cpp
Change-Id: I29937f63e9779deb6dac7ae77e2948d06ebc0319
The previous code handled only some error codes, in a very inefficient
way, for some code paths. This change standardizes error handling using
a helper function that maps winsock WSAE* codes to Qt error codes.
The test for connecting to unreachable hosts or ports is now more
generic, and enabled on Windows, where it passes in local tests,
but dependency on network configuration still makes it fragile,
so ignoring some failures without completely skipping the test.
[ChangeLog][Network][Windows] Correctly emit errors when trying to
reach unreachable hosts or services
Change-Id: Icaca3e6fef88621d683f6d6fa3016212847de4ea
Fixes: QTBUG-42567
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
These tests have not failed on the removed platforms for at least 60 days
Task-number: QTBUG-76608
Change-Id: If7a9f4db907124e3cd54e3f4b0ad3e20717d1912
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QNetworkSession has a concept of UsagePolicy which can disable
background* transfers to conserve battery or bandwidth. However, it is
only possible to change the policy through
QNetworkSessionPrivate::setUsagePolicy which currently doesn't have any
callers outside of our auto tests.
*background = transfers not initiated directly by the user, but needs
to be marked as such by the application developer.
Change-Id: I92c4abccaca040612b4795abe7c52d68a2d21749
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
When I added the QEXPECT_FAIL the http proxy was the only one.
That's no longer true after fixing the SOCKS proxy, so let's make the
condition more specific.
Change-Id: I1eaa5117d5d0219e04cbd091ec54e522fe7b5509
Reviewed-by: Dimitrios Apostolou <dimitrios.apostolou@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
- Replaced QOperatingSystemVersion::WindowsVersion,
QSysInfo::windowsVersion(), QSysInfo::macVersion(),
QSysInfo::MacintoshVersion with QOperatingSystemVersion::current().
- Added QOperatingSystemVersion::WindowsVista for convenience, as it
is used in lots of places.
Change-Id: If9c4ac496005b2e70b5c70be160747afa74b98c1
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This reverts commit 9a25d27b9d58316dee5d2305135d2d74ad5d51e7.
The QSKIP is no longer needed as the imap server's certificate
was updated
Task-number: QTBUG-76610
Change-Id: I1007ce50d6f7f6258fdeb8894c66678a660b03ca
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
When calling waitFor{ReadyRead,Disconnected} it will wait for data but
if the data is already received and the read notification has been
queued (and there's no more data coming in) it will return false.
By checking if a read notification has been queued and then handling
this we can easily take care of this scenario.
Fixes some flaky tests which missed the read data in waitForDisconnect
and similar.
Fixes: QTBUG-38385
Change-Id: Ic05d59883c1175783e56ff1822b6636c35aec874
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QSslSocket (OpenSSL backend) does not use mutex/locks during
a handshake, so we re-enable previously skipped tests.
This reverts commit 8c87a1402c.
Change-Id: I994b085f016f0eb18b3ba439a7041ea08cd3577b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This is part of the migration of qtbase from QRexExp to
QRegularExpression.
Task-number: QTBUG-72587
Change-Id: Ibdd3f63d9069c3f01dfe8431bcc64bde4f2aa569
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
In this threaded setup the server can sometimes have the data before it
calls "waitForReadyRead", what happens then is that we fail the wait and
as a result the test fails overall.
Let's check if we actually got some data after all and then continue if
we did. Since both the client and the server currently wait the same
amount of time (2s) the max timeout for the client was increased by
0.5s so it has some time to notice that the server got the message.
Change-Id: Ib5915958853413047aa5a7574712585bcae28f79
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit e79b1dcdf5)
Reviewed-by: Simo Fält <simo.falt@qt.io>
(cherry picked from commit d53b8b77bc)
Change-Id: I2f6ffb8e0a9b4d591edb6925e48baffcefc14511
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
If this callback is not set then OpenSSL will call the callback
used for <= TLS 1.2 unconditionally when connecting. If using PSK it
will call it again later once the preshared key is needed.
We don't currently handle the TLSv1.3 PSK, but we definitely should.
But for now we can work around it - when psk_use_session_callback is
called we simply change the PSK callback to a dummy function whose only
purpose is to restore the old callback.
This is mostly done to keep behavior the same as it is now for users
(and to keep our tests running).
Later we can add a new signal and handle this new feature properly.
Reviewed-by: Simo Fält <simo.falt@qt.io>
(cherry picked from commit d8efc8d718)
Task-number: QTBUG-67463
Change-Id: I4aca4ae73ec4be7c4f82a85e8864de103f35a834
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
We use global object to store errors found by q_X509Callback.
Thus, we also use a lock/mutex. It would appear all tests
involving in-process server and QNAM are prone to intermittent
failures on our Windows VMs - it's always about timeouts due
to the client socket (QNAM) locking and the server socket blocking
main thread while trying to acquire the same lock.
The real fix is to re-write our verification callback so that
it does not need locking/does not block the main and 'http'
threads as a result. But such change is too dangerous for
5.13.0 so we instead have a somewhat handicapped/reduced
test on Windows.
The fixed QSSlSocket will go into 5.13.
Task-number: QTBUG-76157
Change-Id: Ia54701bcb3f6f079a69e52c8904ac3efcee4a787
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
to test different h2 modes: "h2c" (clear text with protocol upgrade),
"h2" (encrypted, negotiating via ALPN extension), "h2-direct" (encrypted,
no ALPN), "h2c-direct" (plain text, no protocol upgrade). This patch-set
is an amendment to the recent fix in the protocol handler where we were
crashing in "h2c-direct" mode.
Change-Id: I3ff5ed1396a59b72b59a95f927d404ccd202d0b8
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Hardcoding IP addresses and their respective DNS records is fragile.
We care about Qt producing the same result as other DNS querying tools,
so testing that instead.
Running a python script for this is easiest, and assumed to be quite
reliable.
In case where python fails/is not present, fall back to nslookup.
That tool is available on Linux, macOS, and Windows, although the
output it produces varies. This change implements very basic
line-parsing that can interpret the various results encountered
during testing on those platforms.
This also reverts commit bbaceff253fae13d8e56691bc9de7e1981db5118,
which blacklisted the tests that failed due to changes in DNS
records.
Use the opportunity to replace usage of gitorious.org.
Change-Id: I967de226bd603c805df7fe3ed4e871d92d2d0750
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The DNS entry for the host has changed, dig answers with dns.google,
not with google-public-dns-a.google.com. While developing a proper
fix to the test, blacklisting this particular lookup allows
integrations to pass in the meantime.
Change-Id: Id37da6b24554803bf4e2c84be5b949ded40566e8
Reviewed-by: Kari Oikarinen <kari.oikarinen@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
It is constantly passing according to grafana.
Change-Id: I4953cd54e27adde8dad79e9a0f025960802e6c7a
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
In the QNetworkAccessManager machinery we would treat "no-cache" as if
it meant "don't cache" while in reality it means "don't return these
cached elements without making sure they're up-to-date"
At the same time as this change is made let's add test data for
"no-store", which replaces the "no-cache" test data.
Fixes: QTBUG-71896
Change-Id: Ieda98f3982884ccc839cac2420c777968c786f6e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
If this callback is not set then OpenSSL will call the callback
used for <= TLS 1.2 unconditionally when connecting. If using PSK it
will call it again later once the preshared key is needed.
We don't currently handle the TLSv1.3 PSK, but we definitely should.
But for now we can work around it - when psk_use_session_callback is
called we simply change the PSK callback to a dummy function whose only
purpose is to restore the old callback.
This is mostly done to keep behavior the same as it is now for users
(and to keep our tests running).
Later we can add a new signal and handle this new feature properly.
Task-number: QTBUG-67463
Change-Id: I4aca4ae73ec4be7c4f82a85e8864de103f35a834
Reviewed-by: Simo Fält <simo.falt@qt.io>
In this threaded setup the server can sometimes have the data before it
calls "waitForReadyRead", what happens then is that we fail the wait and
as a result the test fails overall.
Let's check if we actually got some data after all and then continue if
we did. Since both the client and the server currently wait the same
amount of time (2s) the max timeout for the client was increased by
0.5s so it has some time to notice that the server got the message.
Change-Id: Ib5915958853413047aa5a7574712585bcae28f79
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit e79b1dcdf5)
Reviewed-by: Simo Fält <simo.falt@qt.io>
We use global object to store errors found by q_X509Callback.
Thus, we also use a lock/mutex. It would appear all tests
involving in-process server and QNAM are prone to intermittent
failures on our Windows VMs - it's always about timeouts due
to the client socket (QNAM) locking and the server socket blocking
main thread while trying to acquire the same lock.
The real fix is to get rid of global variable/locking, we'll
have it later (quite a change and requires a lot of accuracy).
Task-number: QTBUG-76247
Change-Id: Iffc90d9e16783f17f62e836e01c35f22681bdd39
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit 91ab70d17f)
Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io>
Fix test for systems that do not resolve their hostname to localhost.
Not using name resolution also makes the test more robust.
Change-Id: I558b9a975b9021536709db87fbf6a3b314f7ca79
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... except where they are actually the component under test.
Java-style iterators are scheduled for deprecation.
Change-Id: If4399f7f74c5ffc0f7e65205e422edfa1d908ee8
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We use global object to store errors found by q_X509Callback.
Thus, we also use a lock/mutex. It would appear all tests
involving in-process server and QNAM are prone to intermittent
failures on our Windows VMs - it's always about timeouts due
to the client socket (QNAM) locking and the server socket blocking
main thread while trying to acquire the same lock.
The real fix is to get rid of global variable/locking, we'll
have it later (quite a change and requires a lot of accuracy).
Task-number: QTBUG-76247
Change-Id: Iffc90d9e16783f17f62e836e01c35f22681bdd39
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Previous blacklisting 5c4e5032b5 only
covered RHEL 6.6 and RHEL 7.4. The problem however exists in all
6.x and 7.x distros as they have the same openssl.
This however leaves us the problem with future RHEL 8. This will
keep blacklisting these tests there as well. We need a way to blacklist
versions with a wildcard so that we could say RHEL-7.*
Task-number: QTBUG-46203
Change-Id: I2cc52ba2eac949214ecaa02e19d9e623d5befc49
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
'accept' breaks the order, making the static table unsorted and thus
std::lower_bound cannot find it and we always index it in a dynamic
table. Also, make this static table accessible to auto-test.
Plus fix some warnings quite annoyingly visible in qt-creator.
Fixes: QTBUG-74161
Change-Id: I47410f2ef974ac92797c9804aa55cb5c36a436c4
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It fails on CI (Windows 10). Given our qabstractsocket disables
read notifications/stops emitting readyRead if it already has pending data
(unbuffered, aka UDP socket type) - make sure we do not suffer from this.
The change does not affect the test's logic (unless the logic was to fail),
it just makes it more fail-proof.
Change-Id: I6c9b7ded20478f675260872a2a7032b4f356f197
Fixes: QTBUG-73884
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
1. Fix erroneous logic, which was triggered in 'h2' mode (non-TLS connection)
- after the initial protocol upgrade/POST request was handled, the server
(on Windows specifically) was erroneously handling upcoming DATA frames by replying
with another redirect response.
2. Make the test less heavy by sending 1 MB of Qt::Uninitialize instead of 10 MB
- theoretically this could cause a timeout before the redirected request finished
successfully.
Task-number: QTBUG-73873
Change-Id: I961e0a5f50252988edd46d0e73baf96ee22eef3f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
[ChangeLog][qmake] A new feature "cmdline" was added that implies
"CONFIG += console" and "CONFIG -= app_bundle".
Task-number: QTBUG-27079
Change-Id: I6e52b07c9341c904bb1424fc717057432f9360e1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
[ChangeLog][QtNetwork][SSL] The Schannel backend now supports ALPN and
thus HTTP/2.
Change-Id: I1819a936ec3c9e0118b9dad12681f791262d4db2
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
On Windows and macOS, the containers are deployed into a virtual
machine using the host network. All the containers share the same
hostname (qt-test-server), and they are connected to the same network
domain (local).
When running test in such platforms, use the single-name SSL certificate
(qt-test-server.local) for SSL related tests.
Change-Id: Idf33e01e8dd8814510d848b87b59b5fc0edc903e
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
For some reason behavior of SecureTransport has changed from 10.12 to 10.13
and then to 10.14. On 10.13 SecureTransport fails upon receiving the server's
certificate with 'Unrecoverable error', before we can do a manual verification
and accept the certificate as trusted. Analysis of available source code
shows that they, apparently, do not like MD5 hash which our server is using.
Until certificate is updated on the server or we switch completely to
the Docker-based solution we have to BLACKLIST tests that connect to our
current network test-server. Oddly enough, on 10.14 SecureTransport is
less mean.
Task-number: QTBUG-69873
Change-Id: I7da1883e0970a2f6ddd8385f193b76116d6983e0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Currently only available for the OpenSSL backend to use but doesn't
actually rely on anything OpenSSL specific.
Move it so it can be used by the Schannel backend in an upcoming patch
Change-Id: Ia29b153bf3f29cff0d62a41ec5dd7d4671a18095
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
While it's not common it still occurs, perhaps especially with 127.0.0.1
Can be tested by attempting to connect to https://1.1.1.1/ using Qt.
Change-Id: Idad56476597ab570b8347236ff700fa66ab5b1f4
Fixes: QTBUG-71828
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Adds support for Schannel, an SSL backend for Windows, as an
alternative to OpenSSL.
[ChangeLog][QtNetwork][Ssl] Added support for Schannel on Desktop
Windows. To build Qt with Schannel support use '-schannel' during
configure.
Task-number: QTBUG-62637
Change-Id: Ic4fb8ed3657dab994f9f4a4ac5cbddc7001a0a46
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
... as we normally do in other tests, using localhost.
Change-Id: I7969d7bfd50b545adae7e23476d17b6224e9a8fc
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The tests of smb protocol only work in the CI network. Therefore,
the docker-based test server for Windows can't pass all the tests of
QNetworkReply.
These two tests should be reworked when adding Samba server to the
docker-based test servers later on.
Task-number: QTBUG-72861
Change-Id: I54e639b5414760ee929d0d28fe10f9e021aff7dc
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
since we'll refuse to continue with a handshake, failing in initSslContext()
on a disabled protocol versions. Then, functions like waitForEncrypted,
connectToHostEncrypted, startServerEncryption and startClientEncryption
should either bail out early (who needs a TCP connection which we'll
abort anyway?) or bail out whenever we can, as soon as a disabled protocol
was found in a configuration. This change also makes the behavior
of different back-ends consistent, since it's a general code-path
that reports the same SslInvalidUserData error. Update auto-test to
... actually test what it claims it tests.
Task-number: QTBUG-72196
Task-number: QTBUG-72179
Change-Id: I548468993410f10c07ce5773b78f38132be8e3e0
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
As per RFC 6176 (2011) and RFC 7568 (2015).
Code-wise, we're left with the decision of what to do with a few
enumerators in QSsl::Protocol; I've made TlsV1SslV3 act as TlsV1,
and adjusted the description of AnyProtocol.
A new test was introduced - deprecatedProtocol() - to test that
we, indeed, do not allow use of SSL v2 and v3. protocol() and
protocolServerSide() were reduced to exclude the (now) no-op
and meaningless tests - neither client nor server side can
start a handshake now, since we bail out early in initSslContext().
[ChangeLog][QtNetwork][SSL] Support for SSLv2 and SSLv3
sockets has been dropped, as per RFC 6176 (2011)
and RFC 7568 (2015).
Change-Id: I2fe4e8c3e82adf7aa10d4bdc9e3f7b8c299f77b6
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This patch introduces a private 'API' to enable server-side OCSP responses
and implements a simple OCSP responder, tests OCSP status on a client
side (the test is pretty basic, but for now should suffice).
Change-Id: I4c6cacd4a1b949dd0ef5e6b59322fb0967d02120
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Some tests were fixed and others were skipped/blacklisted.
Task-number: QTBUG-63152
Change-Id: Ica7df555f8d152ee589865911130525101d4b941
Reviewed-by: Liang Qi <liang.qi@qt.io>
This is necessary to provide details for the key too,
when the server is using DHE-RSA-AESxxx-SHAxxx.
Amends 7f77dc84fb.
Change-Id: I8ab15b6987c17c857f54bc368df3c6c1818f428c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
By accident, when we erroneously tried testing TlsV1_3 on macOS with
SecureTransport (which does not support TLS 1.3) we hit this quite
subtle problem: it can happen that a server-side socket is never
created but a client (after TCP connection was established) fails
in TLS initialization and ... stops the loop preventing
SslServer::incomingConnection() from creating its socket. Then we
dereference nullptr.
Task-number: QTBUG-71638
Change-Id: I8dc5a4c53022a25aafe2c80a6931087517a48441
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
1. Remove the conditional inclusion of DTLS versions, they made difficult
and unnecessary ugly adding new protocols (something like TlsV1_2OrLater + 4).
2. OpenSSL 1.1.1 first introduced TLS 1.3 support. OpenSSL 1.1 back-end is
compatible with OpenSSL 1.1.1, but would fail to extract/report protocol
versions and set versions like 'TLS 1.3 only' or 'TLS 1.3 or better' on a
new context. Given 1.1.1 is deployed/adapted fast by different distros,
and 5.12 is LTS, we fix this issue by introducing QSsl::Tls1_3 and
QSsl::Tls1_3OrLater.
SecureTransport, WinRT and OpenSSL below 1.1.1 will report an error in case
the application requests this protocol (SecureTransport in future will
probably enable TLS 1.3).
Saying all that, TLS 1.3 support is experimental in QSslSocket.
Done-by: Albert Astals Cid <albert.astals.cid@kdab.com>
Done-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Change-Id: I4a97cc789b62763763cf41c44157ef0a9fd6cbec
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
on macOS, the test seems to be stable nowadays.
Task-number: QTBUG-39986
Change-Id: I18430c3feb27a5bee5474e1eb95f7d89b25f00a9
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Some of the enums were cast to int on comparison. That just makes it
harder to know what the values were.
And verifyClientCertificate had 4 cases which were named the same as 4
others.
Change-Id: I09e8e346a6f416236a92073cf9a8f349938d37ef
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The test fails in a few cases due to the simplistic internal
implementation of TLD-checking, but it's still useful to run the tests.
Change-Id: Idafaed13506fbac2e67b1d2ba72da2f0c4e2904c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Test that we don't silently replace an invalid TLS configuration with
the default one (for now, the only thing that is considered to be
non-valid - is having non-DTLS protocol set).
Change-Id: I6f714b009cf1345a085a3f26d638fc31330f1a94
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
A weird behavior of the DTLS server example, when linked with 1.0.2,
exposed that client code, requesting an invalid protocol (for example, SSLv3)
can end-up with connection encrypted with DTLS 1.2 (which is not that bad,
but totally surprising). When we check the protocol version early in
setDtlsConfiguration() and find a wrong version, we leave our previous
configuration intact and we will use it later during the handshake.
This is wrong. So now we let our user set whatever wrong configuration they
have and later fail in TLS initialization, saying -
'Unsupported protocol, DTLS was expected'.
Auto-test was reduced - the follow-up patch will introduce a new
'invalidConfiguration' auto-test.
Change-Id: I9be054c6112eea11b7801a1595aaf1d34329e1d2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
with a case when we fail to ignore/pre-set one of possible
verification errors.
Change-Id: I23b06243b61acef1ef3576c51529f3ef6601ba7d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
When the connection has been encrypted we will,
in QHttpNetworkConnectionChannel::_q_encrypted, emit 'reply->encrypted'
in which user slots can be called.
In the event that the user calls abort it will, however, not abort until
the next time it goes back to the event loop (which might not happen
until after the request has already been sent).
Task-number: QTBUG-65960
Change-Id: I96865f83c47f89deb9f644c86a71948dbb0ec0d0
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
That's actually how ignoreVerificationErrors (and QSslSocket::ignoreSslErrors)
are used to set the expected/known verification errors before handshake.
Auto-test updated too.
Change-Id: I9c700302d81ddb383a4a750fafd594373fb38ace
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This change frees the tests of their dependence on the Qt internal test
server (qt-test-server.qt-test-net). It makes the developers run the
tests out of Qt testing infrastructure.
If the user has installed Docker engine on their host, the test servers
will be built up inside separate Docker containers, and then, the test
case goes with the Docker-based test servers. Otherwise, the test case
will keep using the Qt internal test server.
Task-number: QTQAINFRA-1686
Change-Id: I518bc3675bfd658938509744b0e7e0610bc8bf66
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
More Qt-style and more natural, also, shorter names.
Change-Id: I97bd68a8614126d518a3853027661435dc4e080d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This patch renames rather awkward 'remote' into more conventional
'peer' (similar to what we have in QAbstractSocket).
Change-Id: Ifc45e538b8adf9cc076bd7aee693277829fd94dc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The logic seems to be simple - if client code on error signal
tries to close TLS socket and this socket has buffered data,
it calls 'flush' and 'transmit' or even 'startHandshake' as
a result, which in turn will set and emit error again. To auto-
test this, we initiate a handshake with pre-shared key hint
on a server side and both client/server sockets incorrectly
configured (missing PSK signals). We also do early write
into the client socket to make sure it has some data
buffered by the moment we call 'close'.
Task-number: QTBUG-68089
Task-number: QTBUG-56476
Change-Id: I6ba6435bd572ad85d9209c4c81774a397081b34f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
According to RFC 6347 a DTLS server also must retransmit buffered message(s)
if timeouts happen during the handshake phase (so it's not a client only as
I initially understood it).
Conveniently so an auto-test is already in place and needs just a tiny
adjustment - handshakeWithRetransmission covers both sides.
Change-Id: If914ec3052e28ef5bf12a40e5eede45bbc53e8e0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It was observed on OpenSUSE VM in CI - apparently, even after succesfull
read from UDP socket error was not UnknownSocketError. While it's under
investigation, the DTLS auto-test should limit itself by DTLS things and
barely test IO success (socket-wise) when needed.
Change-Id: I0773a02c591432b0d6c894f4131f70e41dc7ed72
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It all started from the compiler's warnings about 'this' captured but
not used in lambdas. While fixing this it was noticed that 'client' socket
has a lifetime longer than the test case itself (the socket has a parent,
which is tst_QSslSocket object). The 'server' socket was simply leaked.
So there is no guarantee that some of them (or both) later, after the
test failed in one of QVERIFY, for example, does not emit 'encrypted'
upon receiving more data; this will result: in reading/writing from/to
invalid memory location (captured local 'encryptedCount') and/or probably
exiting event loop when it's not expected to do so.
Change-Id: I51de0493d989a5ba36de2cef58d35526c0e26cda
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This only enables compilation, it doesn't fix any test.
Qt on Android supports process, but not TEST_HELPER_INSTALLS. See also
acdd57cb for winrt.
android-ndk-r10e is used to compile, see
http://doc-snapshots.qt.io/qt5-5.11/androidgs.html .
corelib/io/{qdir,qresourceengine} need to be fixed later.
Done-with: Frederik Gladhorn <frederik.gladhorn@qt.io>
Done-with: Mårten Nordheim <marten.nordheim@qt.io>
Change-Id: I34b924c8ae5d46d6835b8f0a6606450920f4423b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
The test is somewhat similar to tst_QSslSocket but is smaller (in scope, will
grow in future), it has no QTcpSocket/QAbstractSocket-specific things and
has more DTLS-specific code. At the moment it does not use our network
test server, all work is done in the same process with two QUdpSockets
and two QDtls objects. We test (both on client/server ends):
- parameters validation (for all functions that do this) and
the correctness of error codes/handshake states
- handshake procedure (with/out certificates and with pre-shared keys)
- timeouts and re-transmissions during (D)TLS handshake
- peer verification (and related verification errors)
- aborted/resumed handshake
- encrypted I/O
- DTLS shutdown
For now, this test is OpenSSL-only.
Task-number: QTBUG-67597
Change-Id: I27006bfe3d6c02b89596889e8482a782c630402a
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This part of DTLS is relatively easy to test: we never do a complete
handshake. Certificates, verification, ciphers, etc. - do not matter
at this stage (to be tested in tst_QDtls). Errors are mostly insignificant
and can be ignored or handled trivially.
The test is OpenSSL-only: SecureTransport failed to correctly implement/
support server-side DTLS, the problem reported quite some time ago and
no fixes from Apple so far.
Task-number: QTBUG-67597
Change-Id: I21ad4907de444ef95d5d83b50083ffe211a184f8
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It was the same in all test rows, so move it from the _data() to a
fixed value in the test. Also, don't implicitly coerce C-string
literals to QString.
Change-Id: Ieee4c7ffbf251c4b69b5acd79125dfa93eb51d6e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Unlike QNAM, our toy http2 server sends payload as one big chunk as soon as
it fits in the receive window's size. Internally, 'frame writer' splits this
payload into many DATA frames of the appropriate size (imposed either by the
default value or the one from the client's SETTINGS frame). If some test fails,
we can end up with a server waiting for the writer to send all the DATA frames
though it is not needed anymore - there is nobody to receive them after a failure.
This patch moves such a loop into the test server instead and stops the loop early
if needed.
Change-Id: Iea2dcd718d8f83386fd16004807f6447bf999435
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Previously the test worked because the client was the last party to know
when encryption was established. However, due to changes in the TLSv1.3
handshake the server is now the last one.
In either case, relying on both to be encrypted when one of them is
finished is not great, so now we only quit the event loop when both
client and server have emitted 'encrypted'.
Change-Id: Ic1fc75671206d866f7ea983805fd58a99657aac6
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Replace with QSignalSpy or QTRY_COMPARE when possible.
Task-number: QTBUG-63992
Change-Id: I18dc8837301424855487a12ee62451a5aeb21bf0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The formatting of the output from QSslCertificate::toText has
changed slightly from before, so it no longer matches the test's
data.
From what I can tell we just do a manual sanity check and create
a new file with the new output and then augment the test.
Task-number: QTBUG-67463
Change-Id: I751e5a3f9a28015f97c895cea47384704fd68e38
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
... but only if the host it came from is an EXACT match. Also only apply
the cookie if the url is an EXACT match.
[ChangeLog][QtNetwork][QNetworkCookieJar] Cookies will no longer be
rejected when the domain matches a TLD. However (to avoid problems
with TLDs), such cookies are only accepted, or sent, when the host name
matches exactly.
Task-number: QTBUG-52040
Change-Id: Ic2ebd9211c48891beb669032591234b57713c31d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Added a few functions to derive keys from passwords. Currently it
supports PBKDF1 and PBKDF2 as defined in
RFC 8018 ( https://tools.ietf.org/html/rfc8018 ).
[ChangeLog][QtNetwork][QPasswordDigestor] Added QPasswordDigestor
Task-number: QTBUG-30550
Change-Id: I2166b518bd8b54e3486514166e76fd9ba2f219c8
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This patch adds the ability to decode keys which are encoded with PKCS#8
using the generic back-end (used in winrt and secure transport).
It works on both WinRT and macOS; however QSslKey seems unused in the
WinRT backend and it seems only RSA keys can be used for certificates
on macOS. Meaning that DSA and Ec, which in theory* should represent
their unencrypted versions, can't currently be tested properly.
* Can also be confirmed by loading the key using the ST or WinRT
backend, calling toPem(), writing the output to a file and then loading
the unencrypted key using openssl.
[ChangeLog][QtNetwork][QSslKey] Added support for PKCS#8-encoded keys
in the generic SSL back-end (used for SecureTransport on macOS and for
WinRT). Note that it does not support keys encrypted with a PKCS#12
algorithm.
Task-number: QTBUG-59068
Change-Id: Ib27338edc7dbcb5c5e4b02addfdb4b62ac93a4c3
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
QNetworkRequest is already aware of the Last-Modified header but
has been lacking support for the If-Modified-Since, ETag, If-Match
and If-None-Match headers. These headers are used with HTTP to
signal conditional download requests.
See RFC 7232 for more information.
Change-Id: I248577b28e875fafd3e4c44fb31e8d712b6c14f1
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QTestEventLoop (conveniently so) takes care of timeouts thus no
external QTimer/handling logic needed at all.
Change-Id: Id65ea928daec1e7d9380107e63916896f19d3d14
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
To read data from a named pipe, QWindowsPipeReader uses the ReadFileEx()
function which runs asynchronously. When reading is completed and the
thread is in an alertable wait state, the notified() callback is called
by the system, reporting a completion status of that operation. Then the
callback queues a readyRead signal and starts a new sequence. The latter
is skipped if the pipe is broken or the read buffer is full.
Thus, if an application does not run the event loop, the next call to
QWindowsPipeReader::waitForReadyRead() should emit the queued signal
and report true to the caller even if no new read operation was started.
Change-Id: I37102dbb1c00191d93365bfc2e94e743d9f3962a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
1. If a request was redirected or some error was encountered, we
try to reset the uploading byte-device.
2. Disconnecting from the byte-device is not enough, since we have a
queued connection, _q_uploadDataReadyRead() gets called even if
byte-device was deleted and thus sender() can return null -
we have to check this condition.
3. Update auto-test with a case where our server immediately
replies with a redirect status code.
Task-number: QTBUG-67469
Task-number: QTBUG-66913
Change-Id: I9b364cf3dee1717940ddbe50cba37c3398cc9c95
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
When we load DER-encoded keys in the openssl-backend we always turn it
into PEM-encoded keys (essentially we prepend and append a header and
footer and use 'toBase64' on the DER data).
The problem comes from the header and footer which is simply chosen
based on which key algorithm was chosen by the user. Which would be
wrong when the key is a PKCS#8 key. This caused OpenSSL to fail when
trying to read it. Surprisingly it still loads correctly for unencrypted
keys with the wrong header, but not for encrypted keys.
This patch adds a small function which checks if a key is an encrypted
PKCS#8 key and then uses this function to figure out if a PKCS#8 header
and footer should be used (note that I only do this for encrypted PKCS#8
keys since, as previously mentioned, unencrypted keys are read correctly
by openssl).
The passphrase is now also passed to the QSslKeyPrivate::decodeDer
function so DER-encoded files can actually be decrypted.
[ChangeLog][QtNetwork][QSslKey] The openssl backend can now load
encrypted PKCS#8 DER-encoded keys.
Task-number: QTBUG-17718
Change-Id: I52eedf19bde297c9aa7fb050e835b3fc0db724e2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Properly handle single protocol TLS configurations. Previously,
due to the use of generic (non version-specific) client/server method
they worked as ranges of protocols instead. This also fixes a couple
of previously broken tests.
Task-number: QTBUG-67584
Change-Id: Ied23113a4fab6b407a34c953e3bd33eab153bb67
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Except RHEL-6.6 and 7.4
It was blacklisted in f3939d943e, along
with a lot of other entries. No specifics are known about why it was
blacklisted originally, but now it only fails on RHEL because they
use OpenSSL 1.0.1.
Change-Id: I6d1d1b7b7bf5386b2115b8780163550cf03bbad7
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The test creates client and server sockets with mismatching protocol versions,
trying different combinations, for example: 1) server (TLS 1.0) vs
client (TLS 1.2) or 2) server (TLS 1.2) vs client (TLS 1.1), etc.
Since TLS v < 1.2 does not support signature algorithms, they are ignored
and handshake is always successful. But our new OpenSSL 1.1 backend uses
generic TLS_client_method and TLS_server_method when creating SSL_CTX.
This means, both server and client will support TLS v. 1.2, they
will have no shared signature algorithms, thus handshake will fail
with an error string similar to this:
"tls1_set_server_sigalgs:no shared signature algorithms".
For OpenSSL 1.1 this test makes no sense.
Task-number: QTBUG-67456
Change-Id: Ibb2a12eea5e5c0ebaeee7d0719cc721ecf4763e6
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It is suspected that the fault actually lies in CI infra.
Amends e3cf2a1ae9.
Task-number: QTBUG-66311
Change-Id: I967da283f0b94be1d0b99481d0cbd15ca7f98d45
Reviewed-by: Sami Nurmenniemi <sami.nurmenniemi@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Otherwise the ::debug() test fails when a build does not print qDebug()
messages.
Change-Id: I3f3c4b3c7d74004abe5ed8d7ac52164d4f88ef1f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When network access is disabled, every QNAM request returns a
QDisabledNetworkReply instance, which emits error and finished
immediately. However isFinished() was still false, which could confuse
application code.
Change-Id: Ifd43c86364b11a9583a38fde536e6c09c109b55f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Commit f55c73ede2 added various backendConfig methods;
API review for 5.11 pointed out that Config should not be abbreviated.
Change-Id: I3b294b44a030b2a6e4cdd034fa27583c228dfe42
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The stdout of the processes used in the test was dumped if there was an error,
but the processes write their error messages to stderr.
Use MergedChannels process channel mode to dump both output streams.
Change-Id: I1645fd31c394da0871ee6ae36d37ca9a04d86052
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The test's client processes are prepared for the server not being ready when
they try to connect and handle QLocalSocket::ServerNotFoundError by waiting and
trying again.
However, on Ubuntu 16.04 and 17.10 and possibly other systems, sometimes the
error returned by qt_safe_connect inside QLocalSocket is ECONNREFUSED instead of
ENOENT. This has caused flaky failures in CI, so wait and try again in the case
of QLocalSocket::ConnectionRefusedError also.
Task-number: QTBUG-66679
Task-number: QTBUG-66216
Change-Id: I61e3d5b052d84c5ba9d1746f2c71db37cedbf925
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
Has been failing a lot lately
Task-number: QTBUG-66247
Change-Id: Id940a573eb299379cacceb836890cbe0b3c896b7
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Without this fix, a fresh clean build of 5.9 will fail.
Change-Id: I69e4da382b07cc6e5e280e99478cbc3d44aa3f27
Reviewed-by: Jesus Fernandez <Jesus.Fernandez@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
With this change it is possible to use all supported
configurations in different backends without any new interfaces.
Change-Id: Ib233539a970681d30ae3907258730e491f8d3531
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Apparently this (undocumented) TESTDATA feature creates resource files,
but lets you use wildcards as well, which is very handy.
The reason I didn't know/realize this when adapting the tests to use a
".qrc"-file* was because some of the test-cases were using relative
paths instead of the 'testDataDir' variable.
This commit fixes the remaining uses of relative paths, removes a
usage of QDir::setCurrent, and adapts QSslSocket to use TESTDATA.
* in now-reverted commit e1600c1a73
Change-Id: Iee6d88f1e0810eeaadac90e7d44bc6db84bfeabf
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Jesus Fernandez <Jesus.Fernandez@qt.io>
The code used to fall back to anonymous login independently for username
and password; however, it should only use a fall-back password if the
username is missing or (case-insensitive) "anonymous". When a
non-anonymous username is given without password, we should simply skip
he PASS message to FTP.
If the FTP server requests a password, in the latter case, QFtp will
signal authenticationRequired; in all cases, if the server rejects the
given credentials, QFtp signals authenticationFailed. Either way, the
client code can then query the user for credentials as usual.
Task-number: QTBUG-25033
Change-Id: I2a4a3b2725819ab19c8a7e4baa431af539edcd8d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Then we don't need to add a leading slash. (minor clean-up)
Change-Id: I86af224841009fda838e7cb89d47d324963328c9
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This reverts commit e1600c1a73.
The commit missed the fact that TESTDATA exists. Which supports
wildcards and then can automatically pick up new files when added (as
long as they match a wildcard) and then you don't need to maintain a
giant qrc file.
Change-Id: Ie31fadb5ef6e8dfe6105f4f9764292f78cffb512
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Unlike higher scopes (like scope 4, admin-local, which the last commit
used), scopes 1 and 2 require a scope in order to bind, even if some
operating systems are lenient. So test that we are able to bind to them
and do bind properly.
Change-Id: Ifb5969bf206e4cd7b14efffd14fba153eab965b9
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Binding without an interface and expecting the OS to select something is
not supported in all OSes. On FreeBSD, I keep getting EADDRNOTAVAIL. So
modify our test to only join, leave and send to multicast groups with an
interface selection.
With this, all tests either pass or are skipped for me on Linux,
FreeBSD, and macOS. On Windows, this revealed an inconsistency in
behavior, which this commit adds a workaround for.
Change-Id: Ifb5969bf206e4cd7b14efffd14fb6815456494d2
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
tst_QUdpSocket::broadcasting and tst_QUdpSocket::pendingDatagramSize
fail on the new Ubuntu 16.04 clean template.
Task-number: QTBUG-65440
Change-Id: I0e973b9c90b7c5827406bac8138370b61992a115
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
The FreeBSD kernel treats them specially, just like link-local (that's
probably why it calls them "interface-local" instead of "node-local").
So instead let's use a random address, which will avoid multiple
tst_qudpsocket, when run on the same network at the same time,
receiving each other's datagrams. It could happen, considering this test
has an 800-second timeout limit.
Change-Id: Ifb5969bf206e4cd7b14efffd14fb592a3166547e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This is not an official feature of the networking stacks and does not
work portably across operating systems. So just stop trying to do that.
This was failing reliably (not flaky!) with IPv6 on FreeBSD and
Windows. For IPv4, Windows apparently accepts 239.255.0.0/16 but not
other addresses, so remove IPv4 too.
Change-Id: Ifb5969bf206e4cd7b14efffd14fb682c2839e95d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Test fails to start on FreeBSD:
FAIL! : tst_QUdpSocket::initTestCase() 'networkSession->waitForOpened(30000)' returned FALSE. ()
Loc: [/usr/home/tjmaciei/src/qt/qt5/qtbase/tests/auto/network/socket/qudpsocket/tst_qudpsocket.cpp(234)]
This commit is basically a revert of the Qt 4.8 commit
a951fb79139498774d021759d0466b4b2ff50e68. FORCE_SESSION was only used by
manual testing, as the commit message said
> 8. For manual testing, added the FORCE_SESSION macro to test behaviour
> of UDP sockets when they have an explicit network session associated
So I doubt it has been tested recently.
Change-Id: Ifb5969bf206e4cd7b14efffd14fb569ebf53497b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
I broke it in commit 4da2dda2aa. It wasn't
flaky or anything: it was plain broken and would never pass. That
indicates no node in the CI has an IPv4 link-local address (and
apparently neither did I at the time).
Change-Id: Ifb5969bf206e4cd7b14efffd14fb62176546916e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
FreeBSD, for example, does not have SO_NREAD and its FIONREAD returns
the full socket buffer size, including IP and UDP headers.
Change-Id: Ifb5969bf206e4cd7b14efffd14fb5d8ca778d16a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
setSession is only used if we have bearer management.
Change-Id: I64b9d29c01566e79bbca5d0dc11d6aee6d9b0bf0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The reason for each is given in the skip. It's mostly about the
server-side encryption, which is unimplemented for WinRT.
Change-Id: I036b95a4526e02fd047e193f2b3c9130bec08144
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This lets the tests run on devices which previously did not have access
to the files used (WinRT, mobile devices).
Change-Id: Ibdd85862eee6ab1a7d4da87ca321ee9bc9880bfa
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
We have had test.qt-project.org for close to 3 years now.
Change-Id: I71488efd29b645f7b228fffd14fadf4627288243
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
... and unblacklist it on Windows.
From what I can tell there is no particular reason why this test fails
other than that it is a little too slow sometimes (these things happen).
So, to fix the test I bumped the timeout, but to avoid the test running
for longer on every test-run it now also ends when the socket enters
the "Unconnected" state.
Previously it failed 171/500 times, and after this patch it failed
0/1000 times.
Change-Id: I4266bff6b91aaaf502ee66265d01c3a177706402
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jesus Fernandez <Jesus.Fernandez@qt.io>
... and unblacklist it.
It was blacklisted some years ago because it was failing too often.
It was failing because the ssl socket had already received and decrypted
all the data it was going to get, meaning the waitForReadyRead call was
just going to block forever.
Change-Id: Ia540735177d4e1be8696f2d752f1d7813faecfe5
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This test became a real pain recently. A close look at the test shows
several problems (strangely enough, the failure can never be
reproduced on real machines, only on VM - Ubuntu and RHEL 6.6).
There are several asserts that are firing from time to time here and
there. They show that the logic in test is broken/incorrect. QNAM can
open several connections to a host, our test then incorrectly resets
its 'client' data-member and bad things can later happen after
'bytesWrittenSlot' executed (and deleted a socket). For example,
I can reproduce this scenario in every second run:
1. incoming connection -> client = socket(descriptor), connect to
client's readyRead (s1)
2. incoming connection -> client = socket(descriptor), connect to
client's readyRead (s2)
QNAM sends a request on s1. We reply on s2 (which is already wrong)
and call client->deleteLater(), which resets client to nullptr.
If QNAM sends something else on s1, we hit assert(!client.isNull()).
To avoid this, whenever 'sender' in any slot is different from the
'client', we use the actual 'sender' to reply. Another problem is this
weird and rather cryptic waitForFinish which is not needed in this
particular test since we wait for reply error, not 'finished'.
As it happened before - it's not clear if these two problems
were the cause of guaranteed fails on CI - an integration failed
~10 times in a row in the same test (not happening anymore though).
Task-number: QTBUG-64569
Change-Id: Id9aa091290350c61fadf1c3c001e7c2e1b5ac8f4
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Also blacklist tst_QNetworkReply::ioHttpRedirectErrors(too-many-redirects)
on RHEL 6.6 in CI.
Conflicts:
tests/auto/network/access/qnetworkreply/BLACKLIST
tests/auto/network/ssl/qsslsocket/tst_qsslsocket.cpp
Task-number: QTBUG-64569
Change-Id: I7514fc0660c18fd3a3e1d0d0af3f15d879e3c6f4
The verifySessionProtocol() method in the SecureTransport backend did not
properly handle TlsV1_0OrLater, TlsV1_1OrLater and TlsV1_2OrLater.
This commit teaches verifySessionProtocol() about them.
It also adds TlsV1_0OrLater, TlsV1_1OrLater and TlsV1_2OrLater to the
protocolServerSide() test in tst_qsslsocket.
Backport from 5.10 to 5.9 (LTS).
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit 9c765522d1)
Change-Id: I58c53bdf43e0f19b4506f3696d793f657eb4dc6f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Looking at the failures in grafana it appears this test is also failing
on Windows 64. The same fix applies then, and we use Q_OS_WIN now.
Change-Id: Iafcfd6d1e747f3c816878cad072fbfae3aee19ca
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This allow retrieving the value of the known PMTU for the current
socket. This works on Linux (IPv6 and IPv4) and FreeBSD (IPv6 only) --
the other OSes don't have the necessary API.
Note: do we need add IP_MTU_DISCOVER?
Change-Id: I6e9274c1e7444ad48c81fffd14dcaf97a18ce335
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
We document that -1 is not a valid value. The Windows structure's type
is unsigned, so the value is actually ULONG_MAX.
Change-Id: Ic632b4163d784b83951cfffd14f668645c4da3a9
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This patch works around Windows X86 on QEMU antics.
It appears on this platform the test behaves in some unpredictable manner:
- WSAConnect with 255.255.255.255 does not always immediately fail with
some error, so socket engine waits for a connection timeout (30 s.),
but the test itself
- only waits for 5 seconds and then tests that a request has finished with
error, which is not true (we are still connecting).
To make it work - whenever we have bearermanager feature enabled, set
a connection timeout to something reasonable, not 30 s.
Since we try to connect to each address twice, make timeout 1.5 s
(so it's 3 s. in total and still is < 5 s.).
Task-number: QTBUG-64264
Change-Id: I1d40c140667fca8402ec9344e66d313b6df54256
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The vast majority is actually switched to QRandomGenerator::bounded(),
which gives a mostly uniform distribution over the [0, bound)
range. There are very few floating point cases left, as many of those
that did use floating point did not need to, after all. (I did leave
some that were too ugly for me to understand)
This commit also found a couple of calls to rand() instead of qrand().
This commit does not include changes to SSL code that continues to use
qrand() (job for someone else):
src/network/ssl/qsslkey_qt.cpp
src/network/ssl/qsslsocket_mac.cpp
tests/auto/network/ssl/qsslsocket/tst_qsslsocket.cpp
Change-Id: Icd0e0d4b27cb4e5eb892fffd14b5285d43f4afbf
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
[ChangeLog][QtNetwork][QNetworkInterface] Added dnsEligibility() to
QNetworkAddressEntry to indicate whether the address is eligible or not
for publication in DNS or similar mechanisms.
Change-Id: Id3ae5f853d964358ac1ab19b525334a426e0e052
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
[ChangeLog][QtNetwork][QNetworkInterface] Added preferredLifetime() and
validityLifetime() to QNetworkAddressEntry that report the remaining
lifetime of the address in the network interface.
Change-Id: I292b84e2193979446e43344b0727642812cba630
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
- Blacklist ioHttpRedirectPostPut for Windows
- Amend 84396a3f93:
Keys need to be on subsequent lines
Task-number: QTBUG-62583
Change-Id: I6360ec7bd87de65a3294a0d22148f13579fcd292
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Similar to the problem found in QTcpSocket auto-test recently.
While the failure on CI looks differently (apparently, server process
starts but does not print anything), fixing the dependency does not
hurt and at least fixes the 'make check' scenario.
Change-Id: I8f29f3e492d22410533407a527f5fc8f664e7f5c
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
While removing insignificant flag in commit
38a0909d4e and blacklisting
autotests that still failed, qtbase builds didn't
verify VS2017. That broke qt5 builds which do build VS2017.
Task-number: QTBUG-64264
Change-Id: I5fdfa5dac6192f449a05146a9a422e428a710c84
Reviewed-by: Liang Qi <liang.qi@qt.io>
Looks like I never even tested this. There were two problems:
1) when we asked for the recvmsg and sendmsg functions, we used the
wrong variable (socketDescriptor was still -1)
2) we extracted the destination addresses, but never set them in the
QIpPacketHeader object
The added tests confirm that this works on Windows, Linux, Darwin,
FreeBSD. There also seems to be a problem, obtaining the destination
address on an IPv4 socket with a dual-stack sender (I can reproduce that
on FreeBSD, macOS and Windows, plus an old version of Linux).
Task-number: QTBUG-63605
Change-Id: I638cf58bfa7b4e5fb386fffd14ea732bddbc0c42
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This test fails often and seems to be flaky.
Task-number: QTBUG-62583
Change-Id: Id3af283c89e392634a7af6e11bd05775a4295798
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
This test starts two processes - server and client - and requires
an external executable ('stressTest'). In .pro file we have SUBDIRS
containing both 'test' (test itself) and 'stressTest' (client/server app),
but there is no explicit dependency and as result we run the test before
we build 'stressTest' thus failing to start those processes. This patch makes
'test' dependent on 'stressTest'.
Task-number: QTBUG-36629
Change-Id: I286b08bcff86b9afc4bbee87a75e887527eaf5f2
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Neither the exit crash of QTBUG-21102 nor the Windows failure of
QTBUG-24226 appear to be reproduceable.
Add verbose error reporting to getErrors() and blacklist
getErrors:ftp-host which has been found to fail with timeouts
on Linux and ioHttpRedirectMultipartPost.
Task-number: QTBUG-21102
Task-number: QTBUG-24226
Task-number: QTBUG-62860
Change-Id: I6b29f6184e83de8ffebf6ff0d80606512dca6419
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
It fails for me on Windows 10. Therefore, this is wrong.
FAIL! : tst_QHostInfo::initTestCase() 'networkSession->waitForOpened(30000)' returned FALSE. ()
S:\qt\qt5-msvc2017-x64\qtbase\tests\auto\network\kernel\qhostinfo\tst_qhostinfo.cpp(194) : failure location
Change-Id: Ib17dde1a1dbb49a7bba8fffd14ed5691472a4760
Reviewed-by: Jesus Fernandez <Jesus.Fernandez@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
1. Recently we have updated our receive window size to a larger value.
Unfortunately, this also results in auto-test pumping through
more data, which probably takes more time on CI.
At the moment we do not have any public API on QNAM's level to
customize HTTP/2 parameters (aka 5.10/FF and so on). So we use the fact
that QNAM is QObject and we can set a property on it. This property
is our Http2::ProtocolParameters object that allows us to configure:
- HPACK parameters (in 5.10 - noop)
- session receive window size
- different SETTINGS as described by RFC 7540, 6.5.2.
2. Undocumented environment variable to set ENABLE_PUSH is not needed
anymore.
3. In 5.11 Http2::ProtocolParameter will become a public API
and we'll introduce a new setter in QNAM.
Change-Id: If08fd5e09e7c0b61cf9700b426b60b5837b6b2e6
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
c4cf90b1f7 made POST requests be
redirected properly, but this wasn't enough and should have included
every method/verb.
Change-Id: I37b12dc9fdffcbf2aadbd2360d4fc2584c024939
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The path wouldn't match if the cookie's path was root ('/') and the
URLs path was empty.
Change-Id: I6dcd10f1fdf4f48f14e50f1b169cbdfda7005849
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
All systems must implement it by now. If there's any system still
without it, that means it has no IPv6 support, so they can disable
QtNetwork entirely.
[ChangeLog][Deprecation Notice] Starting with Qt 5.10, IPv6 support is
mandatory for all platforms. Systems without proper IPv6 support, such
as the getaddrinfo() function or the proper socket address structures,
will not be able to build QtNetwork anymore.
Change-Id: I3868166e5efc45538544fffd14d8c28046f9191b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
