Future of KSSL

[Brad Hards]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20061112/cae0dca4/attachment.sig>