summaryrefslogtreecommitdiffstats
path: root/src/network/ssl/qsslsocket_mac.cpp
Commit message (Collapse)AuthorAgeFilesLines
* ssl: improve SecureTransport error loggingJeremy Lainé2015-07-151-42/+45
| | | | | | | | | | | This improves SecureTransport logging consistency: - include error code in SSL error when a native backend call fails - use qt.network.ssl category for debug / warning messages - do not use duplicate qWarning when error is already reported via QSslError Change-Id: I52d457b11f0cef2cc3579305e457663b61b92f3f Reviewed-by: Timur Pocheptsov <Timur.Pocheptsov@digia.com>
* ssl: fix SecureTransport handling of remote host disconnectJeremy Lainé2015-07-131-1/+6
| | | | | | | | | | | | | | Currently when the remote server disconnects gracefully (for example upon returning an HTTP request with Connection: close) the call to SSLRead will return errSSLCloseGraceful which is incorrectly reported as QAbstractSocket::SslInternalError. This patch aligns the behavior with that of the OpenSSL backend and instead reports QAbstractSocket::RemoteHostClosedError. Change-Id: I8c6679280ac0c6fbd71d5f0d29b25f692eca5b24 Task-number: QTBUG-47154 Reviewed-by: Timur Pocheptsov <Timur.Pocheptsov@digia.com>
* QSSLSocketPrivateBackend::transmit - fix Secure Transport versionTimur Pocheptsov2015-04-011-17/+9
| | | | | | | | | | | | | | | | | New SSL backend fails to read data most of the time. This patch: 1. Removes direct call to _q_SSLRead - it was never executed (intentionally) and is completely horrible and redundant. 2. Changes the reading loop - read not while we have bytesAvailable, but until we have errSSLWouldBlock. Change-Id: I3fc5ff94ded76fcc1748d4979f7af85740b4b6aa Task-number: QTBUG-45290 Reviewed-by: Richard J. Moore <rich@kde.org> Reviewed-by: Jeremy Lainé <jeremy.laine@m4x.org> Reviewed-by: Timur Pocheptsov <Timur.Pocheptsov@digia.com>
* Secure Transport - handle errSSLBadCert in server modeTimur Pocheptsov2015-03-121-4/+17
| | | | | | | | | | | Suddenly :(( With Security Framework v 7.0 dated by 17/02 SSLHandshake works differently when our server socket is requesting a client side authentication and client provides no certificate. Despite of kTryAuthenticate (this means, auth. _can_ fail) server receives an error from SSLHandshake too early. We have to handle this in startHandshake (when serveMode && canIgnore). Change-Id: Ie55540078e2944e80cf2f4ade8b000acf29d6ca2 Reviewed-by: Richard J. Moore <rich@kde.org>
* QSsl: teach the SecureTransport backend about TlsV1_0OrLater, TlsV1_1OrLater ↵Mikkel Krautz2015-02-151-0/+21
| | | | | | | and TlsV1_2OrLater Change-Id: I001ffebef30b47b63cae6ea9487d9e96ca85ff92 Reviewed-by: Richard J. Moore <rich@kde.org>
* Secure Transport - enable client authenticationTimur Pocheptsov2015-02-131-35/+45
| | | | | | | | | Enable certificate/trust validation when socket is in server mode. Change-Id: I8fbba587a9484084495722219d83cca57973a3e6 Reviewed-by: Jeremy Lainé <jeremy.laine@m4x.org> Reviewed-by: Richard J. Moore <rich@kde.org> Reviewed-by: Timur Pocheptsov <Timur.Pocheptsov@digia.com>
* Update copyright headersJani Heikkinen2015-02-111-21/+13
| | | | | | | | | | | | | | | | | | Qt copyrights are now in The Qt Company, so we could update the source code headers accordingly. In the same go we should also fix the links to point to qt.io. Outdated header.LGPL removed (use header.LGPL21 instead) Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing combination. New header.LGPL-COMM taken in the use file which were using old header.LGPL3 (src/plugins/platforms/android/extract.cpp) Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license combination Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
* Add SecureTransport based SSL backend for iOS and OS XJeremy Lainé2015-02-021-0/+1443
Add support for SSL on iOS/OS X by adding a SecureTransport based backend. [ChangeLog][QtNetwork][QSslSocket] A new SSL backend for iOS and OS X, implemented with Apple's Secure Transport (Security Framework). Change-Id: I7466db471be2a8a2170f9af9d6ad4c7b6425738b Reviewed-by: Richard J. Moore <rich@kde.org>