
Qt 5.9 LTS released - jjuhl
http://blog.qt.io/blog/2017/05/31/qt-5-9-released
======
Vogtinator
Testing shows that it works better than Qt 5.8.0, but that's rather easy.

Some regressions introduced by 5.8 (some wayland related) aren't fixed yet and
Qt WebEngine does not build on AArch64.

There is a bug that breaks applications using kdialog horribly and in the 5.9
branch (to-be 5.9.1) there's already a change that changes behaviour in a
(incompatible with the 5.9 doc!) way that breaks some existing applications.

At least they can't make any excuses to not release 5.9.x releases this
time...

~~~
beojan
> There is a bug that breaks applications using kdialog horribly

That was fixed in the 5.8 branch. I wonder why the fix isn't in 5.9.

~~~
Vogtinator
That's a different bug then, the one I'm referring to was introduced in 5.9...

------
justinclift
One thing unfortunately (still) missing is validation of server side
HTTPS/TLS/SSL certificates on OSX.

eg if you've built a client application which runs on OSX, calling the
verify() function on the cert returned by a server just prints "Unimplemented
code." on stdout/stderr.

[https://bugreports.qt.io/browse/QTBUG-56973](https://bugreports.qt.io/browse/QTBUG-56973)

Not totally sure how to work around that before its fixed, but kind of
thinking maybe running some openssl (etc) commands on the client might do the
trick. Focused on other stuff atm anyway, so haven't really thought about it
in depth. ;>

~~~
tartboogers
Looks like there are a couple of other functions in the Secure Transport
backend that aren't implemented. Pretty irresponsible to put that kind of
insecure-default code into a production library. The workaround is to compile
Qt to use OpenSSL instead of Secure Transport.

~~~
justinclift
Oh good point. Thank you. :)

If we do that, we'd be able to make OSX versions of our app instead of having
to do some dodgy "validate the cert using direct openssl calls" approach. That
definitely sounds workable.

~~~
tartboogers
Also, you're using the "verify" function incorrectly. Take a look at the
documentation for that function; it doesn't do what you think it does anyway.
So even on non-Mac platforms, you weren't verifying the peer certificate.

I'm going to stop looking at that QSsl API. It looks very poorly designed.

[http://doc.qt.io/qt-5/qsslcertificate.html#verify](http://doc.qt.io/qt-5/qsslcertificate.html#verify)

~~~
justinclift
Thinking about this more, that's not clear. When you say it doesn't do what we
think it does... what are we misunderstanding?

Our desire is to make sure the server we're connecting to is "one of ours". eg
to validate the cert provided by the server against a cert chain we've bundled
with the client just for this purpose

The docs for the function seem to indicate that what it's for.

Er... suggestions/assistance (etc) on what we should be doing instead are
definitely welcome. :)

~~~
tartboogers
So the way you're using it:

    
    
      auto verificationErrors = reply->sslConfiguration().peerCertificate().verify(m_sslConfiguration.caCertificates());
      

implies that you want to see if "peerCertificate" validates under
"m_sslConfiguration.caCertificates()".

That's a reasonable (and necessary) thing to do, but the "verify" function
doesn't do that. It's a static function, thus it ignores "peerCertificate".
The way you're using it, it simply verifies
"m_sslConfiguration.caCertificates" using the system's default CA certificates
(I think; the docs are somewhat confusing about this).

Also, further down in that code, you ignore self-signed errors. Well that
pretty much negates the point of checking in the first place doesn't it?
Because if someone MITM's your connection with a self-signed certificate, your
code will say that's fine.

 _However_ , according to the docs for "QSslConfiguration::setCaCertificates",
those CA certificates are used to verify the peer certificate during the SSL
handshake. So do you even need to be doing any kind of verification manually?
I'm not a Qt programmer, but it seems to me that since you're using the
appropriate "QSslConfiguration::peerVerifyMode", it should verify the server
certificate during the handshake using the CA certificates you set (it happens
in the Mac code at [1]).

 __Bottom line: __your "RemoteDatabase::gotEncrypted" function can simply be
eliminated. This would both provide proper peer verification and eliminate
your problem on the Mac platform.

[1]
[https://github.com/qt/qtbase/blob/dev/src/network/ssl/qsslso...](https://github.com/qt/qtbase/blob/dev/src/network/ssl/qsslsocket_mac.cpp#L1121)

~~~
justinclift
> Bottom line: your "RemoteDatabase::gotEncrypted" function can simply be
> eliminated. (and the rest)

Awesome! Thank you. :)

------
wiz21c
Just a bit off topic, but are there many people still using Qt to write
desktop software ? I mean, Qt's not React or Angular, but I find it very easy
to work with as long as there is not much asynchronicity required...

~~~
mherrmann
I'm using PyQt to develop a file manager [1]. Pretty happy with it so far. I
chose it over Electron because of performance [2].

[1]: [https://fman.io](https://fman.io)

[2]: [https://fman.io/blog/picking-technologies-for-a-desktop-
app-...](https://fman.io/blog/picking-technologies-for-a-desktop-app-in-2016/)

~~~
jackmott
thank you

------
EStudley
It's a shame I'll never get to use features past Qt 5.4 after their insistence
on LGPLv3 and royalties per device sold..

~~~
moron4hire
What suggestion would you make for them to be able to make a living off of
open source software?

EDIT: also, it's LGPL _or_ $80/developer-month, not _and_. I don't see
anything about royalties. And considering the GPL doesn't apply until you
start distributing the software, you don't need to spend that money during
development. You can wait to license when you release and start getting
revenue.

~~~
cannam
I don't know whether this has changed, but they used to forbid you from
developing with the open source edition and then releasing under a commercial
licence. (They did this with a term in the commercial licence that specified
that it couldn't be used with code previously developed with the open source
edition.)

This was quite a confusing policy in some ways. I think in practice they
expected to resolve such situations by backdating payments for the commercial
licence to cover the development period.

(Edit: from
[https://www.qt.io/faq/#_Toc_3_13](https://www.qt.io/faq/#_Toc_3_13) it looks
like the policy is unchanged but the wording around it has been softened a bit
to encourage negotiation)

~~~
jononor
3.13 (and 3.12) sounds primarily for avoiding that a company has 30 developers
with only the 1 developer (or CI bot) that does the release having a Qt
commercial license.

Or that you develop for 12 months and get a commercial license the last
month,, when its going to be released.

------
IshKebab
Qt Lite is commercial only right?

Edit: Ah yes it does say:

> For the time being, the Configuration UI Tool is a commercial only tool,
> that adds value for our Device Creation customers.

~~~
dotti
Configuration tool may be, but Qt Lite is just a bunch of new configuration
options. Try ./configure -list-features

------
santaclaus
> The OpenGL paint engine does now work with OpenGL Core profiles as well.

Oh, this is pretty awesome! I was running into issues updating an old Qt
program with QPainter a few days ago, this is super timely.

