Future of KSSL

[Jernej Kos]

Hi,

the reason KFTPgrabber uses its own thin SSL class is because KSSL is broken 
when dealing with asynchronious sockets. So we do not use KSSL at all in the 
latest version.

There is also a libssh in KFTP that uses OpenSSL directly but that can't be 
avoided unless there exists a more high-level SSH library implementation 
(going the "kio way" and executing an external ssh process, then parsing the 
results is out of the question since that is IMO a really bad thing).

Otherwise KFTP can surely be ported to any new SSL interface (like QCA) 
without major problems if it is good enough. But as I see it, we first need 
to port KFTP to KDE4/Qt4 and that will take some time.

Regards,
Jernej Kos.

On Sunday 12 November 2006 11:51, 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