Qt Crypto Architecture for KDE4?

[George Staikos]

On Monday 12 September 2005 19:52, Justin Karneges wrote:
> 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.

  The problem is linking.  OpenSSL changes and now QCA (and anything linked to 
QCA) crashes.

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

  Probably not.  We don't really use much of OpenSSL.  The big issues, again, 
are memory footprint and compatibility.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/