Migrating Qt Crytpographic Architecture to KDE CVS
staikos at kde.org
Wed Sep 29 14:05:46 BST 2004
On Tuesday 28 September 2004 10:44, Thiago Macieira wrote:
> George Staikos wrote:
> >On Tuesday 28 September 2004 10:03, Jason Keirstead wrote:
> >> On September 28, 2004 09:21 am, George Staikos wrote:
> >> > KSSL and QCA have almost nothing in common besides being code and
> >> > having a loose relationship to cryptography algorithms.
> >> I know, thats the great part.
> > Well then how do you envision QCA to replace KSSL? It's impossible...
> > At best you could replace one class in KSSL, KOpenSSL.
> The idea is to keep the KSSL front-end (GUI, KSSLSettings, KSSLSession,
> KSSLPCKS12), while exchanging the back-end to the more-flexible QCA. That
> way, we won't be tied to OpenSSL, since it's just a matter of writing a
> plugin for a new back-end.
Basically a replacement for KOpenSSL. This is what I proposed many times
in the past (see for instance kde-core-devel archives). It was not welcomed
by most people, though I do agree that once something can be proven to be
functionally equivalent to OpenSSL (including bug-compatibility!), it would
be very nice to replace it.
> Another part to be replaced is the socket part of KSSL with a new class as
Well it was designed with KIO's design in mind. I think it's most
important to keep the KIO (TCPSlaveBase) portion easy to use, functional, and
bug free. It's always possible to make another class parallel to KSSL for
use in other applications. That's not the hard part though. The hard part
is the big mess of a certificate check algorithm in TCPSlaveBase...
> QCA doesn't handle the certificate database, for instance -- that's our
That was mostly my point. That's most of the code in KSSL too.
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/
More information about the kde-core-devel