Conflicts:
configure.pri
Also required s/solid\.color/solidColor/ in a couple of places in:
src/gui/painting/qpaintengine_raster.cpp
Change-Id: I29937f63e9779deb6dac7ae77e2948d06ebc0319
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>
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>
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>
[ChangeLog][QtNetwork][SSL] The Schannel backend now supports ALPN and
thus HTTP/2.
Change-Id: I1819a936ec3c9e0118b9dad12681f791262d4db2
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@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>
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>
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>
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 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>
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>
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>
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>
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>
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>
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>
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>
... 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>
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>
The original test is quite unfortunate - it has cipher names hardcoded,
and it fails with OpenSSL 1.1 - no matching cipher found for 'RC4-SHA'
and QSslContext::initSsl fails with 'Invalid or empty cipher list'.
We skip this test entry for 1.1.
Change-Id: I810b80a62d9e27a60db71fd412af0c80630d976c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Several tests are not valid for 1.1 anymore:
1. SSL2 was removed, but there is no OPENSSL_NO_SSL2 and the 'protocolServerSide'
test is trying to use QSsl::SSLv2 and thus is failing.
2. We now use the generic TLS_server/client_method instead of version specific
methods we have in pre-1.1 back-end. So, for example, a client socket with
QSsl::TLS_V1_0 in its SSL configuration will be able to negotiate
TLS 1.2 if our server socket wants it, while with TLSv1_client_method
(OpenSSL < 1.1) our test was expecting SSL handshake to fail.
Change-Id: I18efd5921c79b189e4d9529be09299a361a8a81d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
As QAbstractSocket::readData does and as the documentation of QIODevice says
"this function returns -1 in those cases (that is, reading on a closed
socket..."
Change-Id: I1e64673f6a6d792a640bd6cb28b2bb5a0f18dc36
Reviewed-by: Aleix Pol
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
