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...
They could make money on qt creator. It is a very good c++ IDE and people use it not only for creating Qt apps. Make a basic version free but allow installing extensions and other advanced features after paying for the license.
They could, but given the focus and revenue sources for The Qt Company (licensing their tech to run in embedded devices: cars, fridges, etc.), that would probably be very little money. Better spread shiny shiny QtCreator as widely as possible, for free, like a dealers' first free hit to the expensive dope and the ecosystem (which I'm not belittling, it's awesome!).
Disclaimer: I'm only a passersby, these are informal feelings based on observing the Qt world.
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.
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. ;>
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.
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.
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.
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. :)
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.
Ahh cool. The code we've written for this bit so far was just an initial concept implementation.
The server side code is taking most of the effort, so we'll return to the client side bits later when we have something more solid (less changing) for it to talk to. :)
Even if you do that, are certificates validated against a meaningful list of valid root certificates? (I can't imagine any being practical other than the operating system's).
He supplies his own. In situations where you control both endpoints, this is far more secure than trusting system CA certificates (which include all manner of foreign government and third-party certificates, including some from companies that have been known to issue intermediate CA certificates to third-parties, a big no-no).
After investigating further, it seems that doing manual verification is unnecessary, since Qt does verification during the handshake so long as the default verification mode is used (or the setting to force both server and client verification is used).
We're creating a "cloud" (will be at https://dbhub.io) for people to share/store/collaborate/publish/etc data in SQLite format. Kind of niche, but it should be really helpful for places needing to version+collaborate on (non huge) reference data sets.
There's a live dev server here if that's of interest:
Note - that page shows the expected look and feel. We have no real front page at the moment - it's just a list of public databases that have been uploaded for now - but that'll change as some other bits are completed. :)
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...
I (actually not only me but also a few other guys) wrote an open source GUI dictionary for Linux [1] (it uses Qt selection features that don't work the same way on other platforms, so although it compiles on, say, Mac, it doesn't fully work). It was started with Qt4 10 years ago, then it was ported to Qt5. So I think I can share my perception of Qt.
The framework is very solid, the components are easy to combine and in general, once you get used to it, it becomes quite easy to work with them. The resulting app is very performant and has low memory consumption in comparison to JS-based apps. Also, adding asynchronicity is actually not hard, at least for things like HTTP requests, as you can use Qt signal/slot system to receive events asynchronously so that in simple cases it is not necessary to mess up with threads.
However, the developer productivity is, in my perception, is a somewhat less than with modern JS frameworks. Not 10x less, but a bit less. I think one of the issues is C++ itself: after changes in the code, it is necessary to not only rebuild but rerun the app, and in general writing C++ code is something that requires some attention as otherwise, it is possible to have SEGFAULT somewhere in your app and then spend time looking for the place in your new code that causes this SEGFAULT.
Note that I'm talking here only about classical QtWidget/C++ apps, not QtQuick ones. I think productivity with the second ones should be better. However, one might argue that if you started to write your code in Javascript, it's better to do it in a way that allows you to have the same code running natively in browser (QtQuick experimentally runs in it, but it is experimental and not mainstream), so that you can share components and code for example between your site and your desktop app.
Assuming you require portability, the other options are generally all Chrome-based, so if you like you application to not look like shit, I mean, look native...
There's only really wxWidgets in this space, which is order of magnitude smaller.
I guess on Windows there's .NET if you don't care for other platforms as much. Do people still use other toolkits for writing native C++ apps with GUIs? MFC? Native win32 code?
MFC here! When you use it as a thin wrapper around win32 it's not bad. Actually I quite like it, but that's probably at least partly because I've been using it for so long and I know the warts.
I'm convinced that the time I spend on working around its age and oldschool architecture is less than what I would have spend had I switched/"upgraded" toolkits every 3-5 years as seems to be the common practise. Same goes for using C++, btw.
Oh in the Windos sphere there was Windows Forms, and XAML, and some others thatvI forgot; and html/css based ones (there were some 15+ years ago!); and some other 'universal' ones like wxWidgets but not open source existed years ago. New ones coming out not so much, no.
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.
That's for Qt for Devices. Conditions aren't public, but: "To learn about Qt for Device Creation pricing – developer licenses and embedded device distribution fees – start the conversation now"
also, it's LGPL or $80/developer-month, not and.
It's actually more like $300/dev/month unless you qualify as a startup.
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 it looks like the policy is unchanged but the wording around it has been softened a bit to encourage negotiation)
That is the license terms, but so long as you haven't distributed it before you go to sales and explain the situation they are willing to come to an agreement. Probably this means you pay for all the license term you should have. Something to that effect is even on their pages if you dig around.
The important part is once you realize you have the wrong license you contact sales admit your mistake and make a good faith effort to correct things.
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.
Royalties are way high compared to some of the other mature commercial toolkits out there (like Altia or VAPS).
Last time we quoted for our smallish product (1-2K EAU), Qt wanted $5 or $6/unit, purchased in blocks of 1,000 licenses at a time. That was too much of a hit on our BOM, so we went LGPL and haven't looked back.
Is there a good explanation somewhere as to what someone can and cannot make/sell/open/close with Qt? Last I saw, platforms that allow precompiled dynamically-linked libraries (i.e. everything but iOS) could have the LGPL stuff in a separate binary file. But if you linked the code in directly, you couldn't distribute your application without the source.
I wish there was a FAQ with easy answers like "If you write an iOS app with Qt, you can close the source if you pay us a license fee" or something along that line.
IIRC, Xamarin had similar problems, but that went away when they were purchased.
That is because in the iOS app store, Apple is distributing the app. And they are not willing to obey the obligations of the (L)GPL regarding offering the recipients the source code they have the right so. So Apple has banned code with such licenses from the appstore.
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...