Re: [Development] 5.7/5.8 gives unusable static ltcg x86 builds on MSVC 2015/2017

[Mikkel Krautz]

MSVC 2015 has buggy magic statics, see
https://bugreports.qt.io/browse/QTBUG-58318 and
https://connect.microsoft.com/VisualStudio/feedback/details/3121209

I worked around the issue by disabling them with -Zc:threadSafeInit-.

On Tue, Apr 18, 2017 at 3:46 AM, Kuba Ober  wrote:
> Are -static -ltcg -debug-and-release x86 builds tested and supported? It 
> seems that they are broken on at least MSVC 2015 and 2017, in both 5.7 and 
> 5.8. That's using most recent production releases of either version of MSVC 
> (no prereleases etc), and I build using most recent jom.
>
> For me; 5.8 in a debug build corrupts the heap early during static 
> initialization and doesn't even get to main's body. A release build is will 
> generally crash somewhere but due to lack of heap diagnostics it will get to 
> run first, on a partially corrupted heap.
>
> 5.7 crashes in the release if you as much as use add a shortcut to a dummy 
> widget and then return from main. Seems to be a different face of the same 
> problem, although the debug version didn't crash.
>
> IIRC 5.6 was also crashing for me.
>
> Since this is reproducible on 2 different machines, and seems to point to a 
> persistent problem - did anyone else run into it?
>
> I will file bug reports but would want to know first whether it's anything 
> known. To be completely frank, I couldn't get any Qt version between 5.6 and 
> 5.8, inclusive, to work under either MSVC 2015 or 2017 with -static -ltcg so 
> it seems like an untested configuration that's exposing undefined behavior 
> somewhere as the whole thing is globally optimized.
>
> I kinda need this to work. Unless I hear better ideas, I plan on stripping 
> away code to see what it takes to make it not crash. With 5.8 it crashes even 
> with no plugins linked in, the heap corruption is detected in a heap free 
> from one of the Q_GLOBAL_STATICs in somewhere in Qt.
>
> Cheers, Kuba Ober
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Incorrect TLS Session Verification on macOS with OrLater Options

[Mikkel Krautz]

On Sat, Jan 28, 2017 at 12:16 AM, Jason A. Donenfeld  wrote:
> Hi,
>
> The file src/network/ssl/qsslsocket_mac.cpp contains a nasty bug
> preventing the use of setProtocol(QSsl::TlsV1_2OrLater):
>
> bool QSslSocketBackendPrivate::verifySessionProtocol() const
> {
>bool protocolOk = false;
>if (configuration.protocol == QSsl::AnyProtocol)
>protocolOk = true;
>else if (configuration.protocol == QSsl::TlsV1SslV3)
>protocolOk = (sessionProtocol() >= QSsl::SslV3);
>else if (configuration.protocol == QSsl::SecureProtocols)
>protocolOk = (sessionProtocol() >= QSsl::TlsV1_0);
>else
>protocolOk = (sessionProtocol() == configuration.protocol);
>
>return protocolOk;
> }
>
> In the else clause, it checks for equality between sessionProtocol()
> and the configuration protocol. If the configuration protocol is
> *OrLater, this will always be false, and so verification will never
> succeed. And indeed, sessionProtocol() never returns an OrLater
> response:
>
> switch (protocol) {
>case kSSLProtocol2:
>return QSsl::SslV2;
>case kSSLProtocol3:
>return QSsl::SslV3;
>case kTLSProtocol1:
>return QSsl::TlsV1_0;
>case kTLSProtocol11:
>return QSsl::TlsV1_1;
>case kTLSProtocol12:
>return QSsl::TlsV1_2;
>default:
>return QSsl::UnknownProtocol;
>}
>
> The solution is to properly match the OrLaters and use the usual >= 
> comparison.
>
> A current workaround is to hard code the SSL version and not use an
> OrLater, which is a bummer. Please fix and backport to LTS.
>
> Thanks,
> Jason
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Hi Jason,

Thanks for reporting this.

I'm working on fixing it here (currently WIP):
https://codereview.qt-project.org/#/c/183781/

Thanks,
Mikkel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] CMake, PRLs, static Qt and private Qt deps

[Mikkel Krautz]

Before Qt 5.0 was released, the CMake helper files included a useful
feature that read .prl files in order to find and include Qt
dependencies (such as, say, libqtpcre, but also dynamic system
libraries, and whatever else) in CMake builds against a statically
linked Qt.

This was removed by the following change:

https://codereview.qt-project.org/#/c/37307/
https://github.com/qtproject/qtbase/commit/102e1822ffcdc9954d3c698f863734a8083e349c

This means that building against a static Qt simply isn't practical
using Qt's CMake support, in that you'd have to manually specify the
internal dependencies, or include a CMake-based prl reader in your own
source tree.

Are there any new developments regarding this?

The code review mentions that CMake might grow to support this use
case better in the future -- does anyone know whether anything has
improved on that front?

I realize that Qt 5.0 was a while ago, and there seemingly hasn't been
any great demand for this. But it is a feature I would like to have.

I'm not volunteering just yet, but would this feature be accepted back
in, if implemented properly?

Thanks,
Mikkel

P.S.
If anyone's interested, there is a bit of unused code in
qtbase/mkspecs//features/create_cmake.prf relating PRL files and CMake
that could probably removed for now. It was only added to support this
feature.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] OS X SDK set via configure is not used during build (dev branch)

[Mikkel Krautz]

On Wed, Jan 13, 2016 at 12:55 AM, Thiago Macieira
<thiago.macie...@intel.com> wrote:
> On Wednesday 13 January 2016 00:36:14 Mikkel Krautz wrote:
>> Hi,
>>
>> I'm currently on 10.10, Yosemite, using Xcode 7.1.1 (as of this writing).
>>
>> This version of Xcode only ships with the 10.11 SDK. But I am on 10.10.
>>
>> When I built Qt (dev branch), by passing -sdk macosx10.11 -- the only
>> SDK I have -- to configure, I get build failures.
>>
>> Inspecting the compiler flags, I see that the OS X 10.10 SDK is being
>> used (-isysroot, etc.).
>
> Remove all .qmake.{cache,super} files you may have. The build stores the
> version of the SDK it found when you first ran qmake and won't check again.
> This wasn't a problem in the past because Apple used to provide the same SDK
> for more than one version of Xcode, so you were unlikely to upgrade and lose
> the SDK you last had.

I am pretty sure I had the files cleaned before trying this, so I tried again:

$ cd qt5
$ git submodule foreach --recursive git clean -dfx -f
$ find . | grep qmake.cache
./qtbase/qmake/cachekeys.h
./qtbase/tests/auto/tools/qmake/testdata/export_across_file_boundaries/.qmake.cache
$ find . | grep qmake.super
$

Building:

$ cd qtbase
$ OPENSSL_LIBS="-L${MUMBLE_PREFIX}/lib -lssl -lcrypto" ./configure
-developer-build -opensource -nomake examples -sdk macosx10.11 -I
${MUMBLE_PREFIX}/include -openssl-linked
$ make

Full output at https://gist.github.com/mkrautz/2041003a8aeb63a792b8

Initially, I had MAKEFLAGS set to -j8.

When I did that, I observed that *some* clang++ invocations correctly
used the 10.11 SDK.

Here's me running "make -j8", right after I ran "make":

https://gist.github.com/mkrautz/d96d5329807addf8abc2

So, some things are using the correct sysroot.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] OS X SDK set via configure is not used during build (dev branch)

[Mikkel Krautz]

Hi,

I'm currently on 10.10, Yosemite, using Xcode 7.1.1 (as of this writing).

This version of Xcode only ships with the 10.11 SDK. But I am on 10.10.

When I built Qt (dev branch), by passing -sdk macosx10.11 -- the only
SDK I have -- to configure, I get build failures.

Inspecting the compiler flags, I see that the OS X 10.10 SDK is being
used (-isysroot, etc.).

It seems to be because qtbase/mkspecs/common/macx.conf sets
QMAKE_MAC_SDK to "macosx".

As a quick local fix, I set this to "macosx10.11", and I could
correctly build Qt again.

I don't think this is a configuration error on my end, or a bug in Xcode.
For example, xcodebuild correctly translates the non-versioned "macosx" SDK to
"macosx10.11".

$ xcodebuild -sdk macosx

Build settings from command line:

SDKROOT = macosx10.11

[...]

Does anyone know what's going on?

Thanks,
Mikkel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Support for custom Diffie-Hellman parameters in QSslSocket

[Mikkel Krautz]

Hi Rich,

Sorry for the clash of work -- I had this sketch done on Saturday, and
thought I would have more time during the weekend to hack on it.
However that turned out not to be the case, so I threw this out here.
I'll strive to be more communicative in the future. :-)

WRT tests and docs: I'm aware that they're lacking, this was mainly a
sketch of the API.

I will upload it as-is to Gerrit and get back to you, so I can get
people's comments early.

Thanks,
Mikkel

On Tue, May 26, 2015 at 11:34 AM, Richard Moore r...@kde.org wrote:
 Hi Mikkel,

 Please could you upload your change to gerrit so I can review it properly? I
 was actually implementing this yesterday, but since you've got it done I'll
 abandon my change. If you add me as the reviewer then I'll add the other
 relevant people. The change seems mainly okay, but there are a few minor
 things need fixing (some incorrect \since statements, missing autotest
 etc.).

 Cheers

 Rich.

 On 25 May 2015 at 23:16, Mikkel Krautz mik...@krautz.dk wrote:

 Hi,

 I've been working on adding the ability to set custom DH parameters
 for QSslSocket and I want to start discussing an API for the feature,
 rather than jumping directly to a code review.

 I have a preliminary patch that adds a sketch of the API I'm envisioning:
 https://gist.github.com/mkrautz/699f3c7fb22f48b7059c
 (It's untested, but it builds...)

 Basically, what I'm envisioning is

  - An opaque (for the user) QSslDiffieHellmanParameters class.
  - It loads DH parameters either as PEM or DER via a constructor that
 takes a QByteArray or a QIODevice (like QSslKey).
  - After loading, isNull() can be used to check if the DH parameters
 were loaded, and were valid (OpenSSL backend uses DH_check -- not sure
 what should be done on SecureTransport, if anything?).
  - Internally, the QSslDiffieHellmanParameters object stores a
 DER-encoded version of the parameters. (This makes it easily loadable
 in both OpenSSL and SecureTransport)
  - A public QSslConfiguration::setDiffieHellmanParameters() to set the
 DH parameters.
  - A public (but not in the public headers)
 QSslConfiguration::diffieHellmanParameters() for internal use by the
 backends.
  - QSslDiffieHellmanParametersPrivate will befriend QSslContext (for
 OpenSSL) and an equivalent for SecureTransport to allow the
 implementations to access the DER encoded data of the
 QSslDiffieHellmanParameters.

 I did a cursory web search for the ability to set DH parameters for
 WinRT listeners, but I don't think that's possible -- so I haven't
 considered that, for now...

 Let me know what you think.

 Thanks,
 Mikkel
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Support for custom Diffie-Hellman parameters in QSslSocket

[Mikkel Krautz]

For anyone following this, the change is now at:

https://codereview.qt-project.org/#/c/113070

On Tue, May 26, 2015 at 12:11 PM, Mikkel Krautz mik...@krautz.dk wrote:
 Hi Rich,

 Sorry for the clash of work -- I had this sketch done on Saturday, and
 thought I would have more time during the weekend to hack on it.
 However that turned out not to be the case, so I threw this out here.
 I'll strive to be more communicative in the future. :-)

 WRT tests and docs: I'm aware that they're lacking, this was mainly a
 sketch of the API.

 I will upload it as-is to Gerrit and get back to you, so I can get
 people's comments early.

 Thanks,
 Mikkel

 On Tue, May 26, 2015 at 11:34 AM, Richard Moore r...@kde.org wrote:
 Hi Mikkel,

 Please could you upload your change to gerrit so I can review it properly? I
 was actually implementing this yesterday, but since you've got it done I'll
 abandon my change. If you add me as the reviewer then I'll add the other
 relevant people. The change seems mainly okay, but there are a few minor
 things need fixing (some incorrect \since statements, missing autotest
 etc.).

 Cheers

 Rich.

 On 25 May 2015 at 23:16, Mikkel Krautz mik...@krautz.dk wrote:

 Hi,

 I've been working on adding the ability to set custom DH parameters
 for QSslSocket and I want to start discussing an API for the feature,
 rather than jumping directly to a code review.

 I have a preliminary patch that adds a sketch of the API I'm envisioning:
 https://gist.github.com/mkrautz/699f3c7fb22f48b7059c
 (It's untested, but it builds...)

 Basically, what I'm envisioning is

  - An opaque (for the user) QSslDiffieHellmanParameters class.
  - It loads DH parameters either as PEM or DER via a constructor that
 takes a QByteArray or a QIODevice (like QSslKey).
  - After loading, isNull() can be used to check if the DH parameters
 were loaded, and were valid (OpenSSL backend uses DH_check -- not sure
 what should be done on SecureTransport, if anything?).
  - Internally, the QSslDiffieHellmanParameters object stores a
 DER-encoded version of the parameters. (This makes it easily loadable
 in both OpenSSL and SecureTransport)
  - A public QSslConfiguration::setDiffieHellmanParameters() to set the
 DH parameters.
  - A public (but not in the public headers)
 QSslConfiguration::diffieHellmanParameters() for internal use by the
 backends.
  - QSslDiffieHellmanParametersPrivate will befriend QSslContext (for
 OpenSSL) and an equivalent for SecureTransport to allow the
 implementations to access the DER encoded data of the
 QSslDiffieHellmanParameters.

 I did a cursory web search for the ability to set DH parameters for
 WinRT listeners, but I don't think that's possible -- so I haven't
 considered that, for now...

 Let me know what you think.

 Thanks,
 Mikkel
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Support for custom Diffie-Hellman parameters in QSslSocket

[Mikkel Krautz]

Hi,

I've been working on adding the ability to set custom DH parameters
for QSslSocket and I want to start discussing an API for the feature,
rather than jumping directly to a code review.

I have a preliminary patch that adds a sketch of the API I'm envisioning:
https://gist.github.com/mkrautz/699f3c7fb22f48b7059c
(It's untested, but it builds...)

Basically, what I'm envisioning is

 - An opaque (for the user) QSslDiffieHellmanParameters class.
 - It loads DH parameters either as PEM or DER via a constructor that
takes a QByteArray or a QIODevice (like QSslKey).
 - After loading, isNull() can be used to check if the DH parameters
were loaded, and were valid (OpenSSL backend uses DH_check -- not sure
what should be done on SecureTransport, if anything?).
 - Internally, the QSslDiffieHellmanParameters object stores a
DER-encoded version of the parameters. (This makes it easily loadable
in both OpenSSL and SecureTransport)
 - A public QSslConfiguration::setDiffieHellmanParameters() to set the
DH parameters.
 - A public (but not in the public headers)
QSslConfiguration::diffieHellmanParameters() for internal use by the
backends.
 - QSslDiffieHellmanParametersPrivate will befriend QSslContext (for
OpenSSL) and an equivalent for SecureTransport to allow the
implementations to access the DER encoded data of the
QSslDiffieHellmanParameters.

I did a cursory web search for the ability to set DH parameters for
WinRT listeners, but I don't think that's possible -- so I haven't
considered that, for now...

Let me know what you think.

Thanks,
Mikkel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QSsl: finer-grained protocol selection

[Mikkel Krautz]

I've opened a code review for adding TlsV1_0OrLater and friends at:

https://codereview.qt-project.org/#/c/106080/

We obviously haven't reached agreement on the actual API for this, but
as I said, we're pretty happy with the 'OrLater' variant, which the
patchset implements.  Hopefully, the patchset gives a better overview
of the changes involved.

Rudimentary (as much as possible) support for WinRT is available in
the patchset.

SecureTransport should be easy to add, since it uses a (min, max)
protocol range...


On Fri, Jan 16, 2015 at 3:16 PM, Mikkel Krautz mik...@krautz.dk wrote:
 On Sun, Dec 28, 2014 at 2:26 PM, Thiago Macieira
 thiago.macie...@intel.com wrote:
 On Sunday 28 December 2014 13:11:13 Richard Moore wrote:
 At the moment there are still a lot of SSL accelerators out there with
 these problems. We can probably stop worrying in around a year once all the
 browsers have got around to disabling SSL3 and thereby forcing things to be
 fixed. Currently we will already fail to connect to these servers, but the
 API we provide allows users to implement workarounds in their own code. If
 we change the meaning of the TLSv1 constant in this way then it would no
 longer be possible for them to do this.

 Ah, I see.

 Then we just add to the list:

 TlsV1_0OrLater,
 TlsV1_1OrLater,
 TlsV1_2OrLater

 When TLS 1.3 comes into existence, we add:

 TlsV1_3,
 TlsV1_3OrLater

 We'd be fine with either of these proposals.

 However, I think this proposal would be less surprising to existing
 users of QSslSocket, so it's the one I'd prefer personally.

 Alternatively, we can add a

 /// if major == 0, sets to Secure Protocols
 void setMinimumTlsVersion(int major, int minor);
 int sessionTlsMajorVersion() const;
 int sessionTlsMinorVersion() const;

 And deprecate setProtocol.
 --
 Thiago Macieira - thiago.macieira (AT) intel.com
   Software Architect - Intel Open Source Technology Center

 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QSsl: finer-grained protocol selection

[Mikkel Krautz]

On Sun, Dec 28, 2014 at 2:26 PM, Thiago Macieira
thiago.macie...@intel.com wrote:
 On Sunday 28 December 2014 13:11:13 Richard Moore wrote:
 At the moment there are still a lot of SSL accelerators out there with
 these problems. We can probably stop worrying in around a year once all the
 browsers have got around to disabling SSL3 and thereby forcing things to be
 fixed. Currently we will already fail to connect to these servers, but the
 API we provide allows users to implement workarounds in their own code. If
 we change the meaning of the TLSv1 constant in this way then it would no
 longer be possible for them to do this.

 Ah, I see.

 Then we just add to the list:

 TlsV1_0OrLater,
 TlsV1_1OrLater,
 TlsV1_2OrLater

 When TLS 1.3 comes into existence, we add:

 TlsV1_3,
 TlsV1_3OrLater

We'd be fine with either of these proposals.

However, I think this proposal would be less surprising to existing
users of QSslSocket, so it's the one I'd prefer personally.

 Alternatively, we can add a

 /// if major == 0, sets to Secure Protocols
 void setMinimumTlsVersion(int major, int minor);
 int sessionTlsMajorVersion() const;
 int sessionTlsMinorVersion() const;

 And deprecate setProtocol.
 --
 Thiago Macieira - thiago.macieira (AT) intel.com
   Software Architect - Intel Open Source Technology Center

 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QSsl: finer-grained protocol selection

[Mikkel Krautz]

On Sat, Dec 27, 2014 at 11:52 AM, Richard Moore r...@kde.org wrote:


 On 26 December 2014 at 21:12, Thiago Macieira thiago.macie...@intel.com
 wrote:


 I don't think we need fine-grained detection, but we do need something
 better
 than what we have right now.

 My suggestion is to set a level. For example, if you set to TlsV10, then
 you
 get TLS v1.0 and anything newer, existing today or not, and disable
 anything
 older. The client will negotiate the highest version at connection time.
 The
 only reason to disable newer versions is when the server is buggy, but the
 application should not have to care about that. That's OpenSSL's job.


 Hmm, if you set TLS 1.0 you really need to only negotiate TLS 1.0. If not
 then if you're connecting to old servers the TLS extensions will lead the
 connection to hang.

Hi Rich,

Thanks for the clarification.

I assume this means that QSsl::SecureProtocols (the default) is also broken
when connecting to buggy servers? Or does Qt's HTTP logic do TLS-specific
retries if something fails?

How about a QSsl::SslOption for triggering the behavior Thiago suggested?
(Making it opt-in would also avoid a change in behavior for existing programs
using TlsV1_0 an friends).

Our use case in Mumble is a little special, since our main use of TLS isn't
HTTP-related, so hopefully the amount of buggy TLS implementations is
limited. I believe we only have implementations using OpenSSL,
PolarSSL and Go's crypto/tls in the wild, and I haven't seen problems with
Thiago's approach yet (but I'll admit that I haven't extensively tested it yet).

 Perhaps what we want is a minimum and maximum version
 (though this doesn't map very well to the underlying openssl API).

Well at least it seems to fit OpenSSL's API better than it fits the API that the
WinRT backend is using. I'm guessing that's a problem?

If an explicit QSsl::SslOption is required to trigger the behavior, the docs
for the option could at least explain that it might not work with all backends.

 Cheers

 Rich.


 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QSsl: finer-grained protocol selection

[Mikkel Krautz]

Hi,

For Mumble (http://mumble.info), we'd like the ability to select the
allowed protocols for a QSslSocket in more fine-grained manner.

Very old versions of Mumble, version 1.x, used SSLv3, where as newer
versions,
1.2 and above, use TLSv1.0. We'd like to upgrade to TLSv1.2, and we also
need
backwards compatibility with TLSv1.0 in order to be compatible with older
Mumble
clients and servers. But we're kind of stuck.

Specifying QSsl::TlsV1_2 means TLS 1.2 only!, so that won't work for us.

We could use QSsl::SecureProtocols, but from reading the documentation, it's
a moving target (and rightfully so). In Qt 5.4, QSsl::SecureProtocols means
TLS 1.0, TLS 1.1 and TLS 1.2. But in Qt 5.0, it also meant SSLv3.

(Aside: From a technical standpoint - not worrying about security for a
minute -
 we can't allow SSLv3. The 1.2 versions of Mumble displays a
 'backwards compatibility' warning if it connects to an SSLv3 server -
 which means a Mumble 1.x server. We would like to keep that behavior
around.)

For our use, we'd like to only allow TLS 1.0 and TLS 1.2. (But TLS 1.1 is
fine,
too!). So, the current QSsl::SecureProtocols in Qt 5.4 is fine for our use.
But since QSsl::SecureProtocols is a moving target, we're afraid that if we
commit to using it, a future Qt 5.x version may remove TLS 1.0 support. That
would break backwards compatibility to older Mumble servers and/or clients,
so
that's a no-no for us.

So:

Is QSsl::SecureProtocols guaranteed to be TLS 1.0, TLS 1.1 and TLS 1.2 for
the
rest of Qt 5?

If not, we'd like to discuss the possibility of adding more fine-grained
protocol
selection to QSslSocket. I'm happy to send code for review if we can find an
acceptable method.

One possibility would be to set the protocol to QSsl::AnyProtocol, and then
add
a new blacklist feature:

Protocol blacklist
==

   /*
* Sets the socket's protocol blacklist. Any protocols listed in the
blacklist
* can not be used as the protocol for the socket.
*
* This method can be used with the QSsl::AnyProtocol protocol
* to allow fine-grained selection of the allowed set of protocols
* for the socket.
*
* See also: setProtocol().
*/
   void setProtocolBlacklist(QListQSsl::SslProtocol protocolBlacklist);

Technically (at least when using OpenSSL as the backend) this would use
SSLv23_client_method()/SSLv23_server_method() along with, for example,
SSL_OP_ALL|SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3 to blacklist SSLv2 and SSLv3.

The API mirrors the blacklist approach used by OpenSSL itself (SSL_OP_NO*),
so it's a good match. But maybe it's not a good API.

Another option for the blacklist would be to add flags for each blacklist
candidate to QSsl::SslOptions, like so:

QSsl::SslOptionDisableSSLv2 = 0x080
QSsl::SslOptionDisableSSLv2 = 0x100
QSsl::SslOptionDisableTLSv1_0 = 0x200
QSsl::SslOptionDisableTLSv1_1 = 0x400
QSsl::SslOptionDisableTLSv1_2 = 0x800

These could be used with QSsl::AnyProtocol, and it would fit our use-case
perfectly.

Protocol list
=

Instead of a blacklist, a new set of methods specifying a protocol list
could be added.

/*
 * Sets the socket's SSL protocol list. This is the list of protocols
 * the socket will support in its handshake.
 */
void setProtocols(QListQSsl::SslProtocol protocols);

/*
 * Returns the socket's SSL protocol list.
 */
QListQSsl::SslProtocol protocols() const;

If these were introduced, a new member would probably need to be introduced
to QSsl::SslProtocol as well, signalling that a list has been specified.

Something like:

QSsl::ProtocolListSpecified. // This signals that a list of protocols has
been
 // specified using setProtocols(). Use
protocols()
 // to get the list of allowed protocols.

Perhaps the list needs to be more than a QListQSsl::SslProtocol (to have
an isNull() to
mean 'use the default'?). I don't know yet.

The simply way
==

For our use case, we'd also be perfectly happy to have an explicit
QSsl::SslProtocol
that says TLS 1.0 or greater.

QSsl::TlsV1OrGreater // This option allows the use of TLS 1.0 or greater

This would be equivalent to the QSsl::SecureProtocols of the current Qt 5.4
release.
But it would explicitly contain TLS 1.0, to avoid the moving target
problem of
QSsl::SecureProtocols.


These are just some of the possible implementations that I could come up
with to
get a discussion started.

I hope we can find an acceptable solution to this problem.  For Windows and
OS X,
where most of our users are, we build Qt ourselves, and can patch this in
ourselves.
But we'd like a solution that distros can make use of as well.

Thanks,
Mikkel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QSsl: finer-grained protocol selection

[Mikkel Krautz]

On Fri, Dec 26, 2014 at 2:47 PM, Thiago Macieira
thiago.macie...@intel.com wrote:

 On Friday 26 December 2014 13:12:47 Mikkel Krautz wrote:
  too!). So, the current QSsl::SecureProtocols in Qt 5.4 is fine for our use.
  But since QSsl::SecureProtocols is a moving target, we're afraid that if we
  commit to using it, a future Qt 5.x version may remove TLS 1.0 support. That
  would break backwards compatibility to older Mumble servers and/or clients,
  so
  that's a no-no for us.

 Suppose a flaw is detected in 1.0 that necessitates everyone to upgrade. Why
 would you not want it?

We definitely wouldn't keep supporting TLS 1.0 in that case.

But we would like to still be able to accept connections where the
handshake ends up using TLS 1.0. Then we can handle the rejection at
the application protocol level, and show an appropriate message to the
user and potentially disconnect them immediately. This would be
handled through an update to the server software. Clients could be
updated with a similar mechanism, too.

If we do it this way, it allows us to display an appropriate message,
via the server, even for clients that are not TLS 1.1 or TLS
1.2-aware. (Which is pretty much the whole user base.)

However, if there really is no interest in allowing a finer-grained
protocol selection in Qt itself, I suppose we could live with using
QSsl::SecureProtocols. That'll at least allow us to add a generic
error if a modern client attempts to connect to a server that only
allows TLS 1.0. But older clients would, unfortunately, be stuck with
a generic handshake error.

But in my opinion, that would not be ideal for our users.

 --
 Thiago Macieira - thiago.macieira (AT) intel.com
   Software Architect - Intel Open Source Technology Center

 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QSsl: finer-grained protocol selection

[Mikkel Krautz]

On Fri, Dec 26, 2014 at 10:12 PM, Thiago Macieira
thiago.macie...@intel.com wrote:
 On Friday 26 December 2014 16:55:34 Mikkel Krautz wrote:
 We definitely wouldn't keep supporting TLS 1.0 in that case.

 But we would like to still be able to accept connections where the
 handshake ends up using TLS 1.0. Then we can handle the rejection at
 the application protocol level, and show an appropriate message to the
 user and potentially disconnect them immediately. This would be
 handled through an update to the server software. Clients could be
 updated with a similar mechanism, too.

 If we do it this way, it allows us to display an appropriate message,
 via the server, even for clients that are not TLS 1.1 or TLS
 1.2-aware. (Which is pretty much the whole user base.)

 However, if there really is no interest in allowing a finer-grained
 protocol selection in Qt itself, I suppose we could live with using
 QSsl::SecureProtocols. That'll at least allow us to add a generic
 error if a modern client attempts to connect to a server that only
 allows TLS 1.0. But older clients would, unfortunately, be stuck with
 a generic handshake error.

 But in my opinion, that would not be ideal for our users.

 I don't think we need fine-grained detection, but we do need something better
 than what we have right now.

 My suggestion is to set a level. For example, if you set to TlsV10, then you
 get TLS v1.0 and anything newer, existing today or not, and disable anything
 older. The client will negotiate the highest version at connection time. The
 only reason to disable newer versions is when the server is buggy, but the
 application should not have to care about that. That's OpenSSL's job.

 That means old clients will use newer and more secure protocol versions as
 soon as OpenSSL and Qt are upgraded, with no change to the application.

I really like this approach.

I've taken a stab at implementing this for Mumble's Qt 5 tree - and it
works great. (I'll open a code review soon, for further discussion)

However, while doing that I stumbled upon the qsslsocket_winrt.cpp
file, and by extension I spotted the way WinRT implements this leveled
approach:

http://msdn.microsoft.com/en-US/library/windows/apps/windows.networking.sockets.socketprotectionlevel.aspx

Setting TLS 1.2 gives you TLS 1.2 and below (no SSL 3)
And so on...

However, your suggested approach of having QSsl::Tlsv1_0 mean TLS 1.0
or greater is obviously still achievable if we limit ourselves to
only doing it for QSsl::TlsV1_0, QSsl::TlsV1_1 and QSsl::TlsV1_2. (On
WinRT, all of these would simply be set to Tls12.). But I think
that's fine.

 --
 Thiago Macieira - thiago.macieira (AT) intel.com
   Software Architect - Intel Open Source Technology Center

 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats

[Mikkel Krautz]

On Fri, Nov 8, 2013 at 8:45 AM, Rutledge Shawn shawn.rutle...@digia.com wrote:

 Still, I don't see a good reason to try to avoid making it available on the 
 other platforms.

I agree.

 As long as we ensure that when the library is missing, the ability to decode 
 the larger versions of the icons is missing (or the ability to decode the 
 icons at all is missing), and that doesn't cause any other problems at 
 runtime, is there any other reason not to have it available?

Agreed, again.  The code already handles this case.  It checks for the
presence of the jp2k Qt image format plugin, and only then will it
attempt to decode the larger sized representations of the icon.

 It's not like we'd have to include the JPEG2000 decoder source with Qt, just 
 have the ability to detect the library and compile the plugin only if it's 
 there, right?

That's how I'm imagining it working as well.  No 3rdparty source tree
needs to be bundled (it isn't bundled in qt-solutions either, at the
moment) - but link against the JasPer lib if it's present on the
system, or JASPER_CFLAGS and JASPER_LIBS are specified to configure
(or however we want it to function).

Mikkel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats

[Mikkel Krautz]

On Fri, Nov 8, 2013 at 3:21 PM, Albert Astals Cid
albert.ast...@canonical.com wrote:
 On Friday 08 November 2013 14:18:24 Rutledge Shawn wrote:

 Why should it use jasper instead of OpenJPEG?  I'm not familiar with either
 one but wikipedia seems to say OpenJPEG implements more of the spec.

 And it's actually has an active upstream, while Jasper doesn't seem to be
 maintained at all.


I wasn't really picking sides. :-)  It's just my understanding that
the jp2k image format currently in qt-solutions currently only builds
against JasPer.

OpenJPEG seems preferable if it has more features and is actively maintained.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats

[Mikkel Krautz]

On Tue, Nov 5, 2013 at 9:57 AM, Saether Jan-Arve
jan-arve.saet...@digia.com wrote:

 Is there any big benefits in having ICNS support on other platforms than OSX?


I can comment a bit about my own use of the plugin.

The ICNS icon engine from the code review in my initial mail is used
in Mumble (http://mumble.info/) on OS X (and only OS X) to display
icons from appliactions on the system (you can add applications to a
black/white list for Mumble's overlay feature).  That's the extent of
its use in Mumble.

So my own use of the icon engine is restricted to OS X.  As such, my
own use of the engine could just as well be satisfied by having an
ICNS icon engine in QtMacExtras (or wherever) that wraps NSImage - or
some native code in Mumble to load the icons via native APIs.

Let's take a step back...

Having access to ICNS via QIcon on OS X would be very convenient for
Qt applications that need to integrate with native apps somehow. (For
example, a Web IDE providing a drop-down of available browsers on the
system, or obviously the Mumble use-case mentioned earlier).

So the question is, how do we implement such a thing?

My proposed implementation is an icon engine that only depends on Qt
functionality, and as such can work on any platform that Qt supports.
The unfortunate thing about it is that access to icons in the ICNS
container that have sizes greater than 128x128, we need a JP2K
decoder. (This check happens at runtime. If no jp2k decoder is
present, a QIcon with only the smaller sizes available is returned to
the caller.)

When I wrote the engine a couple of years ago, that seemed to be the
best approach, and the Qt way, if you will. All the pieces were
available in Qt (JP2K was available as separate component, but still
available).

Another implementation strategy could be, as I mentioned previously, a
wrapper around the native frameworks.  It would only run on OS X, but
it would not need the JasPer dependency to access the full range of
icons.

Back when I did my implementation, there was no QtMacExtras (Qt 4!),
so perhaps that's why it didn't seem very Qt-like to wrap the native
frameworks for an icon engine.  I don't know what the general feeling
on that subject is now.  It might be the sensible thing to do.

From what I can see, though, the real blocker here is the JasPer dep.
I wholeheartedly agree that including JasPer as a dependency just for
an icon engine seems like a rather insane requirement. But if there
are other users of the JP2K image format, then I don't see why a
native wrapper would be preferred for an icon engine over a Qt-native
solution that's able to run and be tested across all platforms.

(Also, it's worth noting that the JP2K image format is not a hard
dependency. For many use cases, including mine, displaying a small
icon in a dropdown or list view might be sufficient - and the JP2K
image format might not be needed at all.  In fact, I'm not even
building the JP2K image format myself at present - I only display the
small variants of the .icns.)

I am obviously also not opposed to just keeping it out of the Qt tree
like I've been doing previously.  It just seemed like something that
would be useful for others to have . :-)

(And other seem to agree.  The reason I'm upstreaming the code is
because Jake Petroules had wanted ICNS support In Qt, and was
considering writing an icon engine for it himself. Instead, he found
mine and asked me whether I was interested in submitting it
upstream...)

Mikkel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Moving JP2 imageformat from qt-solutions to qtimageformats

[Mikkel Krautz]

Hello,

I'm process of attempting to integrate support for the ICNS (OS X icon
files) format into Qt as an icon engine.
(https://codereview.qt-project.org/#change,60290)

An optional, but desirable part of the ICNS format is support for
JP2/JPEG2000 images. It's desirable because all variants of the icon
greater than 128x128 are stored as JPEG2000 - so without JPEG2000
support, the icon engine will only be able to render images at 128x128
and below.

It was pointed out during the review that a jp2 image format is
available in the qt-solutions repository:

https://github.com/qtproject/qt-solutions/tree/master/qtjp2imageformat

and that it might make sense to move it into qtimageformats along with
the icns icon engine itself.

Does anyone see and/or have any problems with moving qtjp2imageformat
to qtimageformats?

Thanks,
Mikkel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development