Future of KSSL
bradh at frogmouth.net
Sun Nov 12 10:51:24 GMT 2006
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
kopenssl.h - declares one class - KOpenSSLProxy, which does the interface shim
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
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
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
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
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
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
ksslsettings.h - declares one class - KSSLSettings. Used in the KHTML part,
TCPSlaveBase in KIO (almost identical code) and within KSSL. No direct QCA
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
the crypto KCM
the X.509 certificate KPart.
(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
So much for where I'm seeing it from. How do you see it?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel