QSslSocket

Pau Garcia i Quiles pgquiles at elpauer.org
Thu Jun 7 10:35:05 BST 2007


Quoting Thiago Macieira <thiago at kde.org>:

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

I know OpenSSL is the de-facto standard library for cryptography but I  
wonder, if OpenSSL posed so many problems, why not use another  
library? For instance, libtomcrypt  
(http://libtom.org/?page=features&newsitems=5&whatfile=crypt) is  
public domain and implements more or less the same feature set.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to the amount of work, I usually need 10 days to answer)





More information about the kde-core-devel mailing list