Future of KSSL

[George Staikos]

Hi Brad,

     I want to start out by saying that QCA looks really cool and I  
do hope to be able to use it in some of my projects in the future.   
However I'm really struggling to figure out what the goal is here.  I  
keep hearing people say they want to rewrite KSSL.  What is KSSL?

- SSL integration for KDE's I/O system
- A wrapper around a very heavy library to delay loading of it:  
Performance optimization
- A centralization of policy decisions

I will also add:
- It is very hacky
- Was implemented as a result of compounding needs as opposed to a  
clean initial design

However:
- The library is primarily an internal tool
- It generally works fairly well
- It has gone through very many bug fixes, especially for site  
compatibility problems


   In light of this, what is the goal of rewriting it?  I argue that  
solving the hacky implementation problem is not worth the risk of  
breaking anything else.  We don't have any sort of lack of progress  
because of this.  I also argue that it won't solve any problems with  
apps not using KSSL.  Apps circumventing KSSL are only due to two  
things: 1) a desire to circumvent policy decisions 2) missing  
features.  1 can't be solved and I think it should actually be a  
criteria for ejecting applications from KDE distribution.  2 is  
easily solved and doesn't require any rewriting.

   I said in the past that I'm not opposed to a QCA backend for KSSL  
and I would even be interested in seeing it.  I know it's not easy to  
do that.  It's probably downright ugly, which made me wonder why one  
would even bother.

    Instead of concentrating on a bottom-up approach of replacing a  
crypto library for something that is primarily a policy  
implementation, I would rather see the opposite.  Take a problem such  
as unimplemented ability to use SSL from sockets.  Make a socket SSL  
implementation that shares all policy decisions with KSSL.(I)   
Therefore factor some of KSSL out into a separate library.  Provide  
the UI (widgets) and other tools that all apps need to share.  Then  
the logic will remain the same but in a better form and only then  
will the backend be a simple replacement exercise - if someone even  
cares.  Also at this point we would need a very strong regression suite.

I: It might be nice to make KIO more useful for non-slave-based apps  
too.  That might be the real answer we're seeking.

On 12-Nov-06, at 5:51 AM, Brad Hards wrote:

> George,
>
> I've started looking at the port of KSSL to QCA. I was going to put  
> this off
> till either you or Thiago had a chance to do it, but I'm a bit  
> worried that
> QCA might be missing some things that are needed for KDE, and I'd  
> rather find
> those things out sooner rather than later.
>
> As I see it, there are two distinct ways the port could go:
> 1. Remove kopenssl.h, and substitute QCA.
> 2. A more extensive rework of KSSL and its users, such that  
> applications
> mostly use QCA directly.
>
> I had originally assumed that the first would be much easier,  
> however a bit
> more investigation showed that maybe this is not the case. In  
> particular,
> there is a fair amount of OpenSSL dependency throughout KSSL
>
> As it currently exists in trunk, KDE/kdelibs/kio/kssl has the  
> following header
> files:
>
> kopenssl.h - declares one class - KOpenSSLProxy, which does the  
> interface shim
> to OpenSSL.
>
> ksslcertificatecache.h - declares one class KSSLCertificateCache.  
> This is used
> in konversation, crypto KCM, TcpSlaveBase in KIO, within KSSL, in  
> KSSLD, and
> within the groupwise resource in kdepim. This class has no direct QCA
> equivalent.
>
> ksslconnectioninfo.h - declares one class - KSSLConnectionInfo.  
> Used in KSSL.
>
> ksslinfodlg.h - declares two classes - KSSLCertBox and KSSLInfoDlg,  
> both of
> which are dialogs that show information about certificates and SSL.  
> Used in
> the crypto KCM and the X.509 certificate KPart. This class has no  
> direct QCA
> equivalent, and probably can't since it would require at least QtGui.
>
> ksslpkcs12.h - declares one class - KSSLPKCS12, which represents a  
> PKCS#12
> cert/key pair. Appears to be a work in progress (for example,  
> exposes the
> private key as a EVP_PKEY*, which is OpenSSL specific). Used in a  
> few places
> in KSSL, plus KSSLD, the X.509 certificate KPart, the TcpSlaveBase  
> in KIO,
> and the crypto KCM. The QCA equivalent is KeyBundle.
>
> ksslsigners.h - declares one class KSSLSigners, which manipulates  
> KSSLD over
> dcop. Used by the X.509 certificate KPart and the crypto KCM. Part  
> of the
> functionality (checking for the allowable purpose of an X.509  
> certificate) is
> built into QCA Certificate validity checking. The database  
> manipulation
> functionality would be abstracted to operations on a QCA::KeyStore  
> with a KDE
> specific provider.
>
> ksslall.h - this is just a convenience header, which brings in most  
> of the
> other headers - those that basically make up the public API (not  
> kopenssl.h,
> ksslcsessioncache.h, ksslkeygen.h, kssldefs.h, ksslcertdlg.h,
> ksslpemcallback.h or ksmimecrypto.h)
>
> ksslcertificatefactory.h - declares one class -  
> KSSLCertificateFacoty, which
> just has one static member (generateSelfSigned()). Doesn't appear  
> to do
> anything.
>
> ksslcsessioncache.h - declares one class KSSLCSessionCache, which  
> is a couple
> of static members that allow access to a session cache. Appears to  
> only be
> used by SimpleJob in KIO. This class has no QCA equivalent.
>
> ksslkeygen.h - declares one class - KSSLKeyGen, which is  
> essentially a key
> generation wizard (currently using Q3Wizard, there is a warning  
> about porting
> to new KWizard). Only used by HTMLKeygenElementImpl in KHTML. The
> generateCSR() method and slotGenerate()  slot are only used  
> internally by
> KSSLKeyGen. This class has no direct QCA equivalent, and probably  
> can't since
> it would require at least QtGui.
>
> ksslpkcs7.h - declares one class - KSSLPKCS7, which is an  
> abstraction for
> PKCS#7, mostly just static methods. Used in KFtpGrabber (in  
> extragear), the
> crypto KCM, within KSSL, and the X.509 certificate KPart.
> The QCA::Certificate and QCA::CertificateCollection classes have  
> essentially
> equivalent functionality.
>
> ksslutils.h - declares three functions which are only used with  
> KSSL. QCA does
> something similar, but it is all hidden in the OpenSSL provider.
>
> ksslcertchain.h - declares one class - KSSLCertChain, representing  
> a chain of
> X.509 certificates. Used within KSSL, and for the Java applet  
> server in
> KHTML. The QCA equivalent is CertificateChain.
>
> ksslcertificate.h - declares one class - KSSLCertificate, which is  
> a X.509
> certificate. Used in Konversation, KHTML, TcpSlaveBase and Observer  
> in KIO,
> the crypto KCM, and the X.509 Certificate KPart, KSSLD, the groupwise
> resource for kdepim, the UIServer for KIO, plus within KSSL. I'm a bit
> worried about the Observer class, since it says "# warning FIXME  
> This will
> never work" just near it, but doesn't explain why. The QCA  
> equivalent is
> Certificate.
>
> kssldefs.h - defines four macros, used for openssl version  
> incompatibility.
>
> ksslpeerinfo.h - declares one class - KSSLPeerInfo. Used in a few  
> places
> (Konversation, TcpSlaveBase in KIO, groupwise resource in kdepim,  
> inside
> KSSL), but almost exclusively from KSSL. QCA can do something  
> similar, but it
> is just a CertificateChain object - the same kind of object for the  
> local
> chain andthe peer chain.
>
> ksslsession.h - declares one class - KSSLSession, which is some  
> kind of
> persistant storage for an SSL session (based on the session ID.  
> Appears to
> only be used for the TcpSlaveBase in KIO, and internally within  
> KSSL. QCA
> doesn't expose session re-use (may or may not be implemented by the  
> provider)
> - if you want to reuse the session, you just reuse the QCA::TLS  
> object [Under
> review, because this might mean you cannot do simultaneous requests].
>
> ksslx509map.h - declares one class - KSSLX509Map, which is a QMap  
> of the
> various elements with in the subject or issuer for a certificate.  
> Used in
> Konversation, the crypto KCM, the X.509 Certificate KPart, KSSLD,  
> and a
> couple of places within KSSL. Very similar to the CertificateInfo  
> class
> within QCA, except that CertificateInfo uses an enum for the key,  
> and there
> can be multiple values per key (QMultiMap).
>
> ksslcertdlg.h - delcares one class - KSSLCertDlg, which is a dialog  
> to display
> X.509 certificates. Only used by the KIO UIServer. This class has  
> no QCA
> equivalent, and probably can't since it would require at least QtGui.
>
> ksslcertificatehome.h - declares one class - KSSLCertificateHome,  
> which
> basically a bunch of static methods. Used by KSSLD, TcpSlaveBase in  
> KIO, and
> the crypto KCM. Some of the methods aren't used  
> (getCertificateByHost(),
> getDefaultCertificate(). This class has no equivalent in QCA.
>
> kssl.h - declares one public class - KSSL. Used by the groupwise  
> resource in
> kdepim, the java appletserver in khtml, TcpSlaveBase in KIO. Basically
> equivalent to QCA::TLS.
>
> ksslpemcallback.h - declares one class - KSSLPemCallback which is  
> essentially
> just a structure. Only used in the X.509 certificate KPart. No direct
> equivalent in QCA, although you can implement something similar using
> EventHandler.
>
> ksslsettings.h - declares one class - KSSLSettings. Used in the  
> KHTML part,
> TCPSlaveBase in KIO (almost identical code) and within KSSL. No  
> direct QCA
> equivalent.
>
> ksslx509v3.h - declares one class - KSSLX509V3, which represents  
> the V3 flags
> on a certificate. Only used within KSSL. The QCA equivalent is  
> built into the
> Certificate class (although not identical functionality).
>
> ksmimecrypto.h - declares one class - KSMIMECrypto - a SMIME
> signing/verifying/encrypting/decrypting interface. Doesn't seem to  
> be used
> anywhere in KDE. Equivalent capability provided by QCA::CMS.
>
>
> Out of all that, I conclude that there are only a few  
> applications / classes
> that use KSSL.
> KIO::TcpSlaveBase, TCP::Observer, TCP::SimpleJob
> KSSLD
> the crypto KCM
> the X.509 certificate KPart.
> Konversation
> KHTML
> groupwise resource
> KFtpGrabber
> (there was one more - the certificate metadata plugin in kdeaddons,  
> but I've
> already ported it to use QCA directly).
>
> I looked at how much of KSSL might be able to be removed. Out of  
> the users, it
> should be pretty easy to port the certificate KPart to use just  
> QCA. It might
> stand a useability review as well.
>
> Konversation should probably be ported to use the KIO framework. It  
> appears to
> use code that was originally borrowed from kopete, which is no  
> longer using
> it. Similar for the groupwise resource.
>
> The functionality that is really only supporting the KHTML java  
> applet server
> could be pushed into KHTML.
>
> KFtpGrabber looks to be using part of KSSL, part of openssl  
> directly, and part
> of its own code. I don't get it.
>
> After that, we have the main KIO Job classes, KSSLD, and the crypto  
> KCM. In
> addition to what QCA currently offers, there is a bit of  
> configuration/setup
> that would end up interfacing to QCA as a KeyStore plugin. It might  
> require
> some work to port, but it still might be easier than the port to  
> KOpenSSL.
>
> There are those KDialog subclasses that provide display. They could  
> be left in
> a modified libkio or moved to kdeui (which would then depend on  
> libqca).
>
> After some or all of that, there will be some (more) dead code that  
> can just
> be removed.
>
> So much for where I'm seeing it from. How do you see it?
>
> Brad

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20061115/d9f23abb/attachment.htm>