Future of KSSL

[Michel Hermier]

2006/11/12, Brad Hards <bradh at frogmouth.net>:
> 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.

It was removed durring the port to KDE4, until KSSL comes with a
better solution (at least for the IRC plugin). So I think we still
want to use the KSSL code (at least for the gui common parts, if not
more).

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