Migrating Qt Crytpographic Architecture to KDE CVS

[George Staikos]

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.

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

   That was mostly my point.  That's most of the code in KSSL too.

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