QSslSocket

[Alon Bar-Lev]

On 6/7/07, Thiago Macieira <thiago at kde.org> wrote:
> > 165234 - Suggestion: QSslSocket - Add verifyPeer signal
> > http://trolltech.com/developer/task-tracker/index_html?method=entry&id=165234
> >
> > This is missing feature, TLS/SSL should verify peer before the socket
> > is opened for business. This is important in term of security.
>
> Agreed, but are we sure that a signal is best? Oh, well, let's see if
> Trolltech can come up with something better.

I am not Qt programmer... so I cannot tell... But is it seems the
design of Qt uses signals to notify the user of the class. So during
negotiation you should be notified that peer certificate is valid so
you can validate it... But I really don't know.

> > Reopen
> > 157892 - Allow OpenSSL to be located in non-default include and lib
> > paths on Windows
> > http://trolltech.com/developer/task-tracker/index_html?method=entry&id=157892
> >
> > They are loading OpenSSL shared library dynamically!!! I don't want to
> > guess why.
>
> For three reasons, at least:
> 1) One less library being in memory if you don't use it at all;

You can say this regarding any library you use...
It is best to use the TLS/SSL/crypto engine as a plugin... Just as QCA does...
The plugin is loaded using specific interface and statically linked
with whatever.
But this is not the discussion...

> 2) OpenSSL's historic inability to maintain binary compatibility;

True... But if you like with a specific version you also use this one.
So there is no runtime overhead.

> 3) OpenSSL's license.

There is no different in term of GPL if you statically or dynamically
link, all is derived work.

> > As long as they are doing so, the need at least not use hardcoded
> > library names, so different versions and locations may be specified.
> > I asked to reopen the Windows bug in order to provide getenv () with
> > QT_SSL_XXXX variables to specify which library to load. Of course the
> > hardcoded may remain as defaults.
>
> Hmm... I don't like the idea of using environment variables for that. I'd
> suggest you simply put your OpenSSL libraries in the \windows\system32
> directory.

The problem is NOT windows!!!
If new OpenSSL release is available... on POSIX.
Now, as you said it broke the ABI or it just has an issue.
Qt will automatically use the latest one.
This is invalid approach for dynamic usage.

If they will have environment/configuration/whatever the user may
instruct it to load specific library, such as /usr/lib/libssl.so.0.9.7
and no /usr/lib/libssl.so.0.9.8.

Of course linking with a specific version is better... But already
discussed this one.

Alon.