Qt Crypto Architecture for KDE4?

[Justin Karneges]

On Monday 12 September 2005 03:26 pm, Thiago Macieira wrote:
> Take a look at KOpenSSL's initialisation code: it tries several versions
> of the SSL initialisation routines. That allows KDE to be mostly freed
> from upgrading everytime OpenSSL is released. The same can be
> accomplished by QCA with its plugin, but it will require (binary)
> distributions to release a new package containing the recompiled plugin.

The great thing about security is that the advancement is slow and the 
algorithms are clearly defined.  There are rarely any surprises, and even 
when flaws are found (e.g. the recent stories about SHA-1), the basic 
principles remain unchanged (e.g. the definition of a hash).

Thus, maintaining binary compatibility should be an easy task.  In fact, the 
QCA API is based more around specs and ideas (drawing most from JCA and 
Botan) than any particular implementation, and so even if OpenSSL goes 
breaking binary compatibility to add some foo feature, there will likely be 
little effect on QCA.

With that in mind, there could be some features missing from QCA that KDE 
needs, and those will need to be looked into and discussed.

> There's also the fact that OpenSSL is licensed under an old-BSD-like
> license, which is, AFAIU, GPL-incompatible (it contains the advertising
> clause).

Just to add to the discussion about alternatives: I have very high hopes for 
Botan (and the TLS-layer counterpart, Ajisai), as it is written in a very 
clean C++ and the license is BSD (w/o advertising clause).

-Justin