Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
SSL: register OpenSSL threading callbacks when we can't access Qt's OpenSSL. #3174
We neglected to register our own callbacks for locking and thread IDs
This commit remedies that by providing our own set of callbacks for
Previously, we just expected that Qt would properly initialize OpenSSL.
6 times, most recently
Jul 15, 2017
changed the title
WIP: SSL: register OpenSSL threading callbacks when we can't access Qt's OpenSSL.
Jul 15, 2017
Kissaki left a comment
Looks plausible. Didn’t check the OpenSSL docs on this.
So apparently we forgot to initialize MumbleSSL in tests. We have no compile time guarantee that we do. Should we make it a compile time requirement (RAII) or leave it? Maybe the classes that depend on OpenSSL should require a MumbleSSL instance, which then either initializes an additional OpenSSL or not.
Apart from the two comments, LGTM.
I think it's hard to do well. A lot of the callers aren't a "class", but are static methods. If we had to call ensureInitialized() for each of them, I think that'd be excessive. (In terms of source-code noise, at least).
I'd like to keep what we have here now.
A better solution would perhaps be to have our own MAIN macro like http://doc.qt.io/qt-5/qtest.html#QTEST_MAIN
hacst left a comment
Also do you happen to have a link to documentation describing the callbacks? I pretty much found nothing except examples of other projects using it. I guess I should no longer be surprised by the horrible quality of OpenSSL documentation but maybe I just missed it...
On another note I found openssl/openssl#1260 which indicates
Apart from that looks sensible to me. As mentioned I couldn't find OpenSSL docs on the callback but our use matched other projects so it's hopefully fine (having to say that in crypto code context makes me cringe so hard...).
Those references were what I used.