And also, reduce the utter sloppiness, weirdness of the test and
make it more a test and not a joke. Since the test itself depends
on !QT_NO_SSL, why bother building and running its main, to create
a useless tst_QSslError and do nothing then? Exclude test from
no-ssl build.
Pick-to: 5.15
Pick-to: 6.0
Change-Id: I67879b0de036cbc8c2f75a18f4cf94e6c43c5af0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QSslCertificate::verify() has an undocumented and not very desirable property -
on some platorms it updates the default configuration, which can be surprising.
For example, we deprecated QSslSocket::setDefaultCaCertificates() and recommend
using QSslConfiguration::defaultConfiguration(), QSslConfiguration::setDefaultConfiguration(),
and QSslConfiguration::setCaCertificates(). If an application does this to select
CA roots it trusts explicitly, and then for some reason is calling verify, the
application can have its QSslSockets successfully connecting to a host, whose
root was not trusted by the application. Also, on Windows, defaultCaCertificates()
include system roots already, no need to have them twice.
[ChangeLog][QtCore][QtNetwork] QSslSocket::verify - do not change the default configuration
Pick-to: 5.15
Pick-to: 6.0
Pick-to: 6.0.0
Fixes: QTBUG-88639
Change-Id: I1cd40b259d0a6dcd15c78d1e7c027ff10859595c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
And extend an auto-test for this. When a cookie verification mechanism is
enabled, and verifier, indeed, verifies that some datagram is a 'Client Hello'
message with a proper cookie attached, we start a real DTLS handshake creating a
QDtls object and calling 'doHandshake'. In case cookie verification
was enabled, we need parameters from the verifier (it's a crypto-strong
'number' and hash algorithm) to 'lock and load' the TLS state machine in
a freshly created TLS session object. This code path previously was only
tested manually and was found by LCOV as untested.
Pick-to: 5.15
Pick-to: 6.0
Change-Id: Ieacb8c989997999ea10e15bda6ae106a0338b698
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
And do not run the test with QSslSocket::supportsSsl() returns false -
this may mean unresolved symbols and thus missing functionality,
like i2d_X509 etc. This also makes cases more like other, that already
had those checks.
Fixes: QTBUG-87386
Change-Id: If4e9a650ca325b6f70956f532891a4c1d50465c0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Some code-paths were never executed by auto-test, thus giving us LCOV's
diagnostic. Extend existing tests and add new ones.
Pick-to: 5.15
Change-Id: I648747547f0525a482216b1e1972fcc698c73f65
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
By extending (a bit) an auto-test to cover paths found by LCOV. All of them
is just to trigger the code that checks input parameters.
Pick-to: 5.15
Pick-to: 6.0
Change-Id: I62f9a9045038ff8d123fd1396f4bfd85e75c6d8f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
By adding auto-tests that were missing/not triggering the paths found
by LCOV.
Pick-to: 5.15
Pick-to: 6.0
Change-Id: I472f59e8e7292786c80d7c8dcebde53a2982e1ec
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
By simply extending the basic test to trigger qHash, isEqual and
a bunch of getters.
Pick-to: 6.0
Pick-to: 5.15
Change-Id: Ib1d88fc6d2ad623743cea77ac286ae6ac819dfd1
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
tst_qsslcipher was quite useless - now we test that default constructed
QSslCipher reports expected values. Test the non-default from the
different auto-test, where we are sure we have really useful
ciphersuites (with different parameters obtained from a TLS backend,
where it's possible).
Pick-to: 6.0
Pick-to: 5.15
Change-Id: Iff14a0580fed889cf9e0873bee01d968773626db
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The recent change handling missing elliptic curves introduced a problem
for '-no-ssl' configuration/build. The first version had some protection,
but it was openssl-specific and required a private feature, thus was
removed. Now the real ifdef must be with QT_NO_SSL
Fixes: QTBUG-88238
Pick-to: 5.15
Change-Id: I6fba26d6ab63850e1468e76f8b234703255a026c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
We want to re-enable Android tests in QTQAINFRA-3867. However,
many tests are failing already preventing that from happening.
QTBUG-87025 is currently keeping track (links) to all of those
failing tests.
The current proposal is to hide those failing tests, and enable
Android test running in COIN for other tests. After, that try
to fix them one by one, and at the same time we can make sure
no more failing tests go unnoticed.
Task-number: QTBUG-87025
Change-Id: Ic1fe9fdd167cbcfd99efce9a09c69c344a36bbe4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Move it to the section requiring SSL tests since it
requires QSslConfiguration.
Change-Id: I5c807976ce75fa5967bddb8edd7788dbfbb89375
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Interesting, it only exploded now - initially we were too fast (faster than
500 ms) so never noticed. Now that more tests with the similar event loop
handling were introduced, the last one was catching a single-shot timer
signal, accessing long dead object).
Fixes: QTBUG-87612
Change-Id: I52446fa7b08ef90a4742af3662da7837a8602941
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It's not possible to connect to microsoft.com with Schannel TLS 1.3 for
some reason (also tested with Internet Explorer), but other sites work
fine. Must be something they have to iron out for later.
In my experience this needs a preview release of Windows. One of my
machines is opted into the dev channel of Windows where they enabled TLS
1.3 by default, and it works well in my tests except for the part above.
On my other machine, after enabling TLS 1.3 through the registry, I fail
to complete the handshake with any site. So around March/April next year
is when this code would activate for most people.
MinGW apparently defines NTDDI_VERSION as the one for Windows Server
2003, so it currently doesn't build the new TLS 1.3 code. In Qt (as a
project) we could consider setting this higher, but that's out of scope
for this patch!
Fixes: QTBUG-81294
Change-Id: If329959c3a30ecbfbb8c0d335cc39ccb6d012890
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This time based on grepping to also include documentation, tests and
examples previously missed by the automatic tool.
Change-Id: Ied1703f4bcc470fbc275f759ed5b7c588a5c4e9f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Modify special case locations to use the new API as well.
Clean up some stale .prev files that are not needed anymore.
Clean up some project files that are not used anymore.
Task-number: QTBUG-86815
Change-Id: I9947da921f98686023c6bb053dfcc101851276b5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Clean up the state of the projects,
before changing the internal CMake API function names.
Task-number: QTBUG-86815
Change-Id: I90f1b21b8ae4439a4a293872c3bb728dab44a50d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
qt_add_test supports now QT_TEST_SERVER_LIST, which will add the test
servers as docker test fixtures.
The docker server will be started before the test is run, and stopped
after the test is run.
Running the tests in parallel is not supported.
Docker tests are currently only supported on Linux hosts.
Task-number: QTBUG-85034
Change-Id: If3cefe05c5dec19c14b05d2fa8b01a0b6d95e259
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Certain servers, like smtp.live.com, will send a request for a
certificate even though they don't require one. In Schannel this
manifests as a warning/info status (SEC_I_INCOMPLETE_CREDENTIALS).
In the cases where it's not needed we should suppress the warning and
try to connect anyway, which is done by calling
InitializeSecurityContext again when we get the status.
Pick-to: 5.15
Change-Id: I3c48140f2949d8557251a49a2b66946da9395736
Reviewed-by: Joshua GPBeta <studiocghibli@gmail.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
CentOS it seems not only backported some OpenSSL 3 functions,
but also raised the default security level to 2, making some of
our keys (and MDs?) 'too weak' and failing auto-tests here and
there as a result. For our auto-test we lower the level to 1,
as it is expected to be.
Fixes: QTBUG-86336
Pick-to: 5.15
Change-Id: I7062a1b292e8b60eb9c2b2e82bd002f09f9da603
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Remove around 1000 compiler warnings about missing overrides
in our auto tests.
This significantly reduce the compiler warning noise in our auto
tests, so that one can actually better see the real problems
inbetween.
Change-Id: Id0c04dba43fcaf55d8cd2b5c6697358857c31bf9
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It's not guaranteed that all curves we want to use are supported
by a specific build of OpenSSL library we have to link with. Filter
out files that contain EC, which is not among the curves, reported
by QSslConfiguration::supportedEllipticCurves.
Fixes: QTBUG-46203
Pick-to: 5.15
Change-Id: I70d7e6fcacb3d81f8c771e4a8d6cca06295e7474
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
And put a note about it in the documentation
Change-Id: I29126e4a80f83c256190e03b8fe01f3c869fd46d
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
At the moment it just exposes QTBUG-84676, that is, OpenSSL
and non-OpenSSL backend act differently. Went a bit overkill
in making it data-driven, so if someone wants to add more
samples it should be easier to do so.
Change-Id: I96538c9563d12d69c217415ba85e244dda5e0cd0
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Use pro2cmake with '--api-version 2' to force regenerate
projects to use the new prefixed qt_foo APIs.
Change-Id: I055c4837860319e93aaa6b09d646dda4fc2a4069
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We had such an overloaded version in QSslSocket, it was deprecated without
providing any alternative. Now this function has some use and may be
introduced in Qt6, as QSslConfiguration::setCiphers(const QString &).
Last but not the least - a useless and strange auto-test was removed
(it was creating a list of 5 QSslCiphers each with isNull() == true).
That's becasue '!MD5' or 'ALL' (for example) is not a cipher to be found
in supportedCiphers.
Change-Id: I47eb4c0faa9b52885e883751dd992cd9cb3d26fe
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Not to pollute the global namespace with rather generic names
(especially in case QT_NAMESPACE is none); also drop the
(now)redundant 'Q' prefix in the names.
Change-Id: I57ea7e3996cced705f7ddbdbc1e0231191b31c43
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
They were deprecated with replacements in QSslConfiguration proposed (and
some without alternative, which we'll provide if there is any demand
in such an API). Special thanks to M.N. for a nice hint on how to
amend the test without introducing a new API.
Change-Id: I7841a5b3f30469d8204b61cb65921c34275e0650
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
In Qt 5 we have to work with the esisting API (QSslCertificate::verify),
taking only the peer's chain and the name. We already have a private
API to have a CA's list as an additional parameter, the proper fix
in Qt6 will also introduce a public complement for this.
Pick-to: 5.15
Change-Id: Ib1f75c3056b135c6e6d42f977b5a7034fca658ee
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Whoever wrote this test, was a PROPER hacker: trying to force a TLS implementation
not to properly compress some data, they generated a sequence of bytes in a very fancy manner,
something like 255 0 0 0 255 0 0 0 123 0 0 0 255 0 0 0 - yeah, it's really a random sequence
of bytes, surely, it's impossible to compress! Meh.
Pick-to: 5.15
Change-Id: Ia10ae18a40b5b8f006c45147b06fe5be6efcb129
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
We deprecated several setters on QSslSocket, no need to test
them then (and I'm removing them in Qt 6 anyway, so changing
the test is the phase 1).
Pick-to: 5.15
Change-Id: I5807abfb280cbacd4fcc19468793f9d1f3b2ff20
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Macros and the await helper function from qfunctions_winrt(_p).h are
needed in other Qt modules which use UWP APIs on desktop windows.
Task-number: QTBUG-84434
Change-Id: Ice09c11436ad151c17bdccd2c7defadd08c13925
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Use 'errorOccurred' instead of 'error' and 'sslHandshakeErrors'
instead of 'sslErrors'.
Fixes: QTBUG-82605
Change-Id: I19d4845b16c7b636af7b0658d4fbbba4eef9d029
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Instead of manual string splitting (EW!), use QDateTime parsing.
Moreover, X.509 certificates *must* have a valid start/end date.
In case of parsing failure, reject the certificate. An autotest
for this last case is coming in a separate patch.
Change-Id: I934bf9e6a4a92e4befdb3b0f9450f76f67bad067
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
We end up with an absurd situation:
QSslConfiguration conf;
//we set CA certs so that on demand loading is disabled:
conf.setCaCertificates({...});
QSslSocket s;
s.setSslConfiguration(conf);
Q_ASSERT(conf == s.sslConfiguration); // this assert fails.
Pick-to: 5.15
Change-Id: I272bed145434082acc6ead95fe3640d222b21131
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Conflicts:
examples/opengl/doc/src/cube.qdoc
src/corelib/global/qlibraryinfo.cpp
src/corelib/text/qbytearray_p.h
src/corelib/text/qlocale_data_p.h
src/corelib/time/qhijricalendar_data_p.h
src/corelib/time/qjalalicalendar_data_p.h
src/corelib/time/qromancalendar_data_p.h
src/network/ssl/qsslcertificate.h
src/widgets/doc/src/graphicsview.qdoc
src/widgets/widgets/qcombobox.cpp
src/widgets/widgets/qcombobox.h
tests/auto/corelib/tools/qscopeguard/tst_qscopeguard.cpp
tests/auto/widgets/widgets/qcombobox/tst_qcombobox.cpp
tests/benchmarks/corelib/io/qdiriterator/qdiriterator.pro
tests/manual/diaglib/debugproxystyle.cpp
tests/manual/diaglib/qwidgetdump.cpp
tests/manual/diaglib/qwindowdump.cpp
tests/manual/diaglib/textdump.cpp
util/locale_database/cldr2qlocalexml.py
util/locale_database/qlocalexml.py
util/locale_database/qlocalexml2cpp.py
Resolution of util/locale_database/ are based on:
https://codereview.qt-project.org/c/qt/qtbase/+/294250
and src/corelib/{text,time}/*_data_p.h were then regenerated by
running those scripts.
Updated CMakeLists.txt in each of
tests/auto/corelib/serialization/qcborstreamreader/
tests/auto/corelib/serialization/qcborvalue/
tests/auto/gui/kernel/
and generated new ones in each of
tests/auto/gui/kernel/qaddpostroutine/
tests/auto/gui/kernel/qhighdpiscaling/
tests/libfuzzer/corelib/text/qregularexpression/optimize/
tests/libfuzzer/gui/painting/qcolorspace/fromiccprofile/
tests/libfuzzer/gui/text/qtextdocument/sethtml/
tests/libfuzzer/gui/text/qtextdocument/setmarkdown/
tests/libfuzzer/gui/text/qtextlayout/beginlayout/
by running util/cmake/pro2cmake.py on their changed .pro files.
Changed target name in
tests/auto/gui/kernel/qaction/qaction.pro
tests/auto/gui/kernel/qaction/qactiongroup.pro
tests/auto/gui/kernel/qshortcut/qshortcut.pro
to ensure unique target names for CMake
Changed tst_QComboBox::currentIndex to not test the
currentIndexChanged(QString), as that one does not exist in Qt 6
anymore.
Change-Id: I9a85705484855ae1dc874a81f49d27a50b0dcff7
[ChangeLog][Deprecation Notice] QAbstractSocket::error() (the signal) is deprecated; superseded by errorOccurred()
Change-Id: I11e9c774d7c6096d1e9b37c451cf0b99188b6aad
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This reverts commit 94b3dd77f2.
The patch fixes ambiguity between a getter and a signal by changing the
getter name, but we still have to rename the signal to follow the signals
naming convention.
Revert the commit to keep the getter as is and change the signal name instead.
Change-Id: I0dd60cf1ae9d1bd95beeb8ad58661ca4b1fb63b9
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is part of the migration of qtbase from QRexExp to
QRegularExpression.
If support for regular expression is disabled, fixed string can
still be used.
[ChangeLog][QtCore][QSslCertificate] Add overload of fromPath that does
not make use of QRegExp and deprecate the QRegExp variant.
Task-number: QTBUG-72587
Change-Id: I507d8941cc7d70166da0948375dc421fe5e7d967
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
We don't know which versions these blacklistings actually apply on
unless we actually get macOS 10.14 and 10.15 into the CI and running
tests, so let's start with that, and then granularize the blacklists
after that.
Task-number: QTBUG-75786
Change-Id: Id79642afa50cb20efa2cd209286b6933918d3a4a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
We were being inconsistent in how we handled this, some tests skipping
while others using QVERIFY. It makes more sense to skip the tests, since
the problem is a missing pre-condition of the test, not the test itself
being bad or exposing real failures in the implementation.
Change-Id: I20eacfe12dbce0b0d926e48cbe2d2772819fa4a5
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
To disambiguate &QSslSocket::sslErrors() expression. Add a new
getter - sslHandshakeErrors().
[ChangeLog][Deprecation Notice] QSslSocket::sslErrors() (the getter) was deprecated and superseded by sslHandshakeErrors()
Task-number: QTBUG-80369
Change-Id: I9dcca3c8499800c122db230753dc19b07654f8a2
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The one that is a getter for the last error found. This is to disambiguate
the expression '&QAbstractSocket::error'. Introduce a new member-function
socketError as a replacement.
[ChangeLog][Deprecation Notice] QAbstractSocket::error() (the getter) is deprecated; superseded by socketError().
Task-number: QTBUG-80369
Change-Id: Ia2e3d108657aaa7929ab0810babe2ede309740ba
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
1. Add a new verification callback. This gives an option
to report errors directly from this callback (by emitting
handshakeInterruptedOnError()). This allows an application
to explain to its peer why the handshake was interrupted (by
sending a corresponding alert message).
2. This also means we want to notice such alerts (in Qt,
from the application's point of view, they are mostly
informational only, no interaction is required). So we
also introduce a new 'info callback', that can notice alert
messages read or written. We also introduce two new enums
describing the level and type of an alert message. QSslSocket
gets three new signals (for incoming/outgoing alerts and
verification errors found early).
3. In case we requested a certificate, but the peer provided
none, we would previously abruptly close the connection without
a proper alert message (and such a situation is not handled
by any verification callbacks, since there is no certificate(s)
to verify essentially). So we now introduce a new verification
option that maps to what OpenSSL calls 'SSL_VERIFY_FAIL_IF_NO_PEER_CERT'.
This way, the proper alert will be generated.
Fixes: QTBUG-68419
Change-Id: I5d1e9298b4040a2d4f867f5b1a3567a2253927b8
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Instead of OID as string, OpenSSL returns a human-readable name.
No need to fail then, use such a name in QVERIFY if OID not found.
Fixes: QTBUG-80329
Change-Id: I4392fc9f37367f7c34c05d172db015b44e2a8497
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Also, change the notion of 'unsupported protocol' for QSslSocket,
previously it was SslV2 and SslV3, now instead it's all versions
of DTLS and UnknownProtocol:
- makes no sense at all to connect using TCP socket and then
suddenly start using DTLS_client/server_method
- UnknownProtocol is not to be set in a configuration,
unknown means that some ciphersuite's protocol version
cannot be established.
- 'disabledProtocols' auto-test becomes 'unsupportedProtocols'
and tests that QSslSocket fails to start encryption if the
protocol version is wrong.
Handling these enumerators (SslV2 and SslV2) as errors
not needed anymore. Removed from QSslContext and our
existing backends (qsslsocket_whatever).
TlsV1SslV3 enumerator is not making any sense at all (previously
was [SSL v3, TLS 1.0], then became "the same as TLS v. 1.0", but
now this name is very confusing. Removed.
Task-number: QTBUG-75638
Task-number: QTBUG-76501
Change-Id: I2781ba1c3051a7791b476266d4561d956948974a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
OpenSSL 1.0.2 will stop receiving all support at the end
of 2019. Qt 5.15 is our next LTS thus makes sense remove
OpenSSL 1.0.2 support there. This also allows us quite
a significant cleanup of an old heavily if-defed code
and all 'pre11' suffixed source files.
[ChangeLog][QtNetwork][SSL] Removed OpenSSL 1.0.x support, now 1.1.x is required
Change-Id: I70c70c56cbd8aeff793afe793335696d1b1b7408
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This is almost 100% source compatible with Qt 5. Exceptions are
* Stability of references for large or non movable types
* taking a PMF for types that are now overloaded with r-value references
in QVector
* The missing prepend optimization in QVector (that is still planned
to come for Qt 6)
Change-Id: I96d44553304dd623def9c70d6fea8fa2fb0373b0
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
And add a test for it so it can no longer happen in any current or
future implementation.
Change-Id: I3214aa90595e291b1e1c66befe185cfe1ea7bc6b
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Following the deprecation of add[Default]CaCertificate[s] let's update
the uses of it. While we're doing this, let's also use QSslConfiguration
more in some places where it makes sense.
Change-Id: I2c9e7c73fee8a405492410378f2babe67d3a3f25
Reviewed-by: Jesus Fernandez <jsfdez@gmail.com>
This patch was generated with tooling from patchset 31 of
https://codereview.qt-project.org/c/qt/qtqa/+/267034 in interactive
mode. General platform names were chosen if greater than 60% of the
currently active platforms of a given type in COIN recently failed.
Change-Id: Ia4bde7f0ec422bbb727dc9d7151295159094f146
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@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>
Conflicts:
configure.pri
Also required s/solid\.color/solidColor/ in a couple of places in:
src/gui/painting/qpaintengine_raster.cpp
Change-Id: I29937f63e9779deb6dac7ae77e2948d06ebc0319
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>
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>
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>
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>
... 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>
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>
[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>
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>
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>
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>
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>
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>
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>
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>
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>
Timur Pocheptsov
Allan Sandfeld Jensen
Assam Boudjelthia
Friedemann Kleint
Mårten Nordheim
Lars Schmertmann
Alexandru Croitor
Cristian Adam
Lars Knoll
Giuseppe D'Angelo
Jarek Kobus
Oliver Wolff
Qt Forward Merge Bot
Alexander Akulich
Simon Hausmann
Leander Beernaert
Samuel Gaist
Tor Arne Vestbø
Ulf Hermann
Frederik Gladhorn
Daniel Smith
Liang Qi
Sona Kurazyan
Edward Welbourne
Marc Mutz
Tony Sarajärvi
Oswald Buddenhagen
Kari Oikarinen