QSslSocket

Thiago Macieira thiago at kde.org
Thu Jun 7 09:12:01 BST 2007


Alon Bar-Lev said:
> Hello all,
>
> After the discussion of smartcards support in KDE, I've opened a few
> feature requests in Trolltech.

Thank you for your commitment and the help you provide.

> 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.

> 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;
2) OpenSSL's historic inability to maintain binary compatibility;
3) OpenSSL's license.

Since OpenSSL breaks BC more often than not, the code has to determine
which function signature to use. But it can only do so at runtime. That's
the only way to maintain that QtNetwork doesn't have to be recompiled
again and again. (The running joke is that we should lock the OpenSSL
developers in a room and keep changing the voltage in the power outlets)

As for the license, I could be wrong, but I am not sure how GPL-compatible
it is. AFAIR, it still contains a provision inherited from SSLeay that is
incompatible. Therefore, Qt/GPL can't link to it, directly. Again, I could
be wrong.

Moreover, KSSL does the same thing: it dlopens OpenSSL.

> 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.

But I'll again defer to the developer in the case.

> It is so fun to work with their task tracker... You may discuss the
> problem freely and watch for changes... And have a complete
> description of a what required. Well... at least I wish this was the
> case.

I know the feeling.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358






More information about the kde-core-devel mailing list