| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The key/certificate lifetime management in our Schannel backend is a
little lacking. We haven't guaranteed that the original contexts are
held alive for the full duration of their usage. Though with default
settings they get persisted to disk so it has been mostly fine.
One problem with that is that the legacy APIs in Windows for this is not
smart enough to figure out that a repeatedly-loaded key is the same one,
so it 'persists' a new file to disk every time we set up a credential
context for a connection. For a busy server this may end up with
creating a ton of small files that don't get deleted (or reused).
By using the ncrypt APIs we don't fully stop persisting _all_ data to
disk, but from testing we now only have one file per key. Regardless of
the amount of connections.
Another patch around lifetimes can be done for dev, and dev only, as
it's quite a bit more extensive, and not fit for picking back to the
LTS branches.
Fixes: QTBUG-136055
Pick-to: 6.10 6.9 6.8
Change-Id: I61398a3773ef8c25aab21df3e78b71f3ab11d488
Reviewed-by: Edward Welbourne <[email protected]>
|
|
|
|
|
|
|
|
| |
Fixes the build with QT_NO_CAST_FROM_BYTEARRAY.
Pick-to: 6.9 6.8 6.5
Change-Id: I7d26235cbb9d26dc4b6d12a68a5ae494574b82a2
Reviewed-by: Marc Mutz <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was added in 44cb71d6fdb0b7285d4ef74a1ef778323aa9e5ee to reduce the
size of the bootstrap lib.
Since commit c7f64d84fbd9b5b3cac41c1d81dc4d0479fc3fa1 removed
QCryptographicHash from the bootstrap lib, the macro is now
redundant (unless it's used by QtLite).
Change-Id: I5459a52507bc9e0a7b982b4382211be9a23c4ad9
Reviewed-by: Thiago Macieira <[email protected]>
|
|
|
|
|
| |
Change-Id: I92fddb36cd136fd1bd627955f15d0559b9942d7e
Reviewed-by: Allan Sandfeld Jensen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
It previously had to kludge a 1900-to-1999 date into a 1950-to-2049
range; it can now tell QDTP to do that for it. In particular, this
fixes a problem with 00-02-29, which failed to parse using 1900 as
base year so couldn't be corrected to 2000-02-29, which is now the
date it finds directly.
Task-number: QTBUG-46843
Change-Id: I7ac936bdfb15b78daed5d237c5d921c800af4951
Reviewed-by: Mårten Nordheim <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By parsing QDate and QTime separately it will internally parse the
values as-if-by UTC. This means we avoid the overhead of figuring out
what the local timezone is repeatedly for each certificate.
On Windows, with Schannel, this brings QAsn1Element::toDateTime
from consuming more than 97% of the test time to below 10%.
The test being tst_QSslSocket::systemCaCertificates. It also goes
from taking 1 minute in debug, to 1 second.
As a drive-by: add a (currently) failing test for Feb 29 2000, which
fails because we decode the date as 1900 before adjusting it to 2000.
But there is no 1900-02-29, so it returns an invalid date. As spotted
by Eddy.
Pick-to: 6.6 6.5
Change-Id: Iefa73a01d710129faf6412c4fa8bc2b5d7c98bbb
Reviewed-by: Timur Pocheptsov <[email protected]>
Reviewed-by: Edward Welbourne <[email protected]>
|
|
|
|
|
|
|
| |
Prefer QStringView overloads
Change-Id: Icc928a91056d661f9e7f187f42592f05ad081a84
Reviewed-by: Mårten Nordheim <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the missing functionality to the Schannel backend to
make QSslCertificate::importPkcs12() work on Windows.
[ChangeLog][QtNetwork][QSslCertificate] Add support for
PKCS12 import with Schannel backend.
Change-Id: Ibb501724d0dc78b0507ac8becf4776fbba0a0623
Reviewed-by: Qt CI Bot <[email protected]>
Reviewed-by: Mårten Nordheim <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
isHexDigit, isOctalDigit, isAsciiDigit, isAsciiLower, isAsciiUpper,
isAsciiLetterOrNumber.
This de-duplicates some code through out.
Rename two local lambdas that were called "isAsciiLetterOrNumber" to not
conflict with the method in QtMiscUtils.
Change-Id: I5b631f95b9f109136d19515f7e20b8e2fbca3d43
Reviewed-by: Thiago Macieira <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
On macOS we observe strange CA certificates that are coming from
Security framework and which it cannot later parse from the DER
format we feed it in. Add some more debugging in order to understand,
which certificate gives such result.
Pick-to: 6.4 6.2
Task-number: QTBUG-109135
Change-Id: I75cf4591e33c85db6fe80d37d84ede1456c56231
Reviewed-by: Timur Pocheptsov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is semantic patch using ClangTidyTransformator:
auto QtContainerClass = expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)
makeRule(cxxMemberCallExpr(on(QtContainerClass),
callee(cxxMethodDecl(hasAnyName({"count", "length"),
parameterCountIs(0))))),
changeTo(cat(access(o, cat("size"), "()"))),
cat("use 'size()' instead of 'count()/length()'"))
a.k.a qt-port-to-std-compatible-api with config Scope: 'Container'.
<classes> are:
// sequential:
"QByteArray",
"QList",
"QQueue",
"QStack",
"QString",
"QVarLengthArray",
"QVector",
// associative:
"QHash",
"QMultiHash",
"QMap",
"QMultiMap",
"QSet",
// Qt has no QMultiSet
Change-Id: Ibe8837be96e8d30d1846881ecd65180c1bc459af
Reviewed-by: Qt CI Bot <[email protected]>
Reviewed-by: Volker Hilsheimer <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <[email protected]>
Reviewed-by: Lars Knoll <[email protected]>
Reviewed-by: Jörg Bornemann <[email protected]>
|
|
|
|
|
|
| |
Task-number: QTBUG-98434
Change-Id: Ic235b92377203f7a1429ae7fd784c4a1fa893e9f
Reviewed-by: Mårten Nordheim <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ASN.1 parser for a date-time had to check the date-time string was
all digits to catch the case of a sign in the month field, which used
to be accepted when it should not be. That bug has now been fixed, so
remove the work-around and add a second date-time test-case, renaming
(and modernising) the existing one for consistency.
Task-number: QTBUG-84349
Change-Id: I649c5129312b6865af08b22ba6893cb4e29243f8
Reviewed-by: Giuseppe D'Angelo <[email protected]>
|
|
|
|
|
|
|
| |
'Use size() or length() instead'
Change-Id: I284fce29727c4c1ec9ea38a4e8ea13a9e0af5390
Reviewed-by: Sona Kurazyan <[email protected]>
|
|
|
|
|
|
| |
Change-Id: Iec42e4d0f3476bd421861a0139731ff89788ee23
Reviewed-by: Timur Pocheptsov <[email protected]>
Reviewed-by: Mårten Nordheim <[email protected]>
|
|
|
|
|
|
|
|
| |
With -static build lcTlsBackend was duplicated.
Pick-to: 6.2
Change-Id: I20ee0f9c7e2027a7033c9fbae628d0d91672e719
Reviewed-by: Mårten Nordheim <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The maximum size for a hash result is 64 atm. Even if, and esp when,
we'll get to 128 and 256 bytes in the future, there's no reason to use
dynamic memory, because the sizes will always be statically known.
So use, essentially, a std::array<char, 64> to hold the result
internally. Add a bit of convenience API on top to limit impact on the
rest of the code and add a few static_asserts that ensure this is large
enough. Then give users access to the internal buffer by adding
QByteArrayView resultView() const noexcept. The documentation snippet
is taken from QString::data(), suitably adjusted.
Use resultView() in a few places instead of result().
[ChangeLog][QtCore][QCryptographicHash] Changed to use a
statically-sized buffer internally. Added resultView() to access it.
Change-Id: I96c35e55acacbe94529446d720c18325273ffd2f
Reviewed-by: Edward Welbourne <[email protected]>
Reviewed-by: Mårten Nordheim <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
... instead of the "usual" rule of three: ctor, addData(), result().
Not only does it generate less code in the caller, it's now also
faster.
Change-Id: I67c7eeb01f527b90e80a08f60c1c7f2ec1e49dd4
Reviewed-by: Lars Knoll <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
As per the best practice laid forth in RFC-8996.
TLS 1.2 was recommended from 2008 until TLS 1.3 was released in 2018.
[ChangeLog][QtNetwork][QSslSocket] TLS 1.0, 1.1 and DTLS 1.0 are now
deprecated, as recommended by RFC-8996.
Fixes: QTBUG-92880
Change-Id: I90cebcfb07cfce623af7ac9f2b66ce9d02586b54
Reviewed-by: Timur Pocheptsov <[email protected]>
|
|
All TLS (and non-TLS) backends that QSsl classes rely
on are now in plugins/tls (as openssl, securetransport,
schannel and certonly plugins).
For now, I have to disable some tests that were using OpenSSL
calls - this to be refactored/re-thought. These include:
qsslsocket auto-test (test-case where we work with private keys),
qsslkey auto-test (similar to qsslsocket - test-case working with
keys using OpenSSL calls).
qasn1element moved to plugins too, so its auto-test have to
be re-thought.
Since now we can have more than one working TLS-backend on a given
platform, the presence of OpenSSL also means I force this backend
as active before running tests, to make sure features implemented
only in OpenSSL-backend are tested.
OCSP auto test is disabled for now, since it heavily relies on
OpenSSL symbols (to be refactored).
[ChangeLog][QtNetwork][QSslSocket] QSslSocket by default prefers 'openssl' backend
if it is available.
[ChangeLog][QtNetwork][QSslSocket] TLS-backends are not mutually exclusive anymore,
depending on a platform, more than one TLS backend can be built. E.g., configuring
Qt with -openssl does not prevent SecureTransport or Schannel plugin from being
built.
Fixes: QTBUG-91928
Change-Id: I4c05e32f10179066bee3a518bdfdd6c4b15320c3
Reviewed-by: Qt CI Bot <[email protected]>
Reviewed-by: Edward Welbourne <[email protected]>
Reviewed-by: Mårten Nordheim <[email protected]>
|