Qt Crypto Architecture for KDE4?

[George Staikos]

On Monday 12 September 2005 03:51, Brad Hards wrote:
> I think it is reasonable to treat KSSL as a special case.
>
> However there is a reasonable amount of other crypto-related code. How
> about the blowfish and sha1 code in kwallet?
> SHA1 in kuser?
> SHA1 in kopete?
> What about the various authentication stuff in kdelibs/kio/misc?
> The crypto stuff in KDEPIM?
>
> And what approach do we want to take for new code?

  Yes I'm a big supporter of using QCA for all of the custom implementations 
of ciphers and hashes.

> > Therefore, the idea that George and I agreed on was to adapt KSSL to
> > support two backends instead of one: QCA and KOpenSSL (which is a class
> > in KSSL wrapping OpenSSL). Then we'll evaluate whether it's feasible to
> > maintain both backends or if we'll have to decide on one. There are some
> > things that QCA already does that KOpenSSL doesn't and it could be a bit
> > hard to reimplement, and we're going to need those.
>
> Is this reversed? Are there things that KOpenSSL does that QCA needs to do?

  Basically no, except observe memory footprint issues.  KOpenSSL was designed 
purely to demand-load OpenSSL.  The overhead of linking directly to OpenSSL 
is quite large, and was a show-stopper for KDE 2.0.

> > Hmm... now I understand: no, KSSL is not going away. We NEED a special
> > handler for everything related to SSL in order to automatise the
> > necessary procedures. As George told me, there are so many pitfalls in
> > SSL handling that we'd rather have one central place where it's
> > implemented correctly and make it difficult to break it.
> >
> > That's not to say that QCA wouldn't be available for those authors who do
> > want to do everything themselves.
>
> I guess the question is "would it be better to move it all to QCA"? From
> what you've said above, I'm assuming that the answer is that it wouldn't
> be.

  If QCA does demand-load of OpenSSL and we can force it to use OpenSSL by 
default from KSSL, then that's reasonable.  (And assuming it doesn't add any 
new major overhead.)  Allowing users to change the backend already will 
multiply the support overhead by a large factor.  Not making OpenSSL the 
default is just insane from a QA point of view.  I will just close each bug 
report as it comes in at that point.  It's hard enough dealing with different 
OpenSSL versions.

> > Yes, we'd like to have support for more than one backend, but we have no
> > choice but to support OpenSSL right now. GNU TLS simply isn't up to the
> > same level as OpenSSL.
>
> We don't yet have a provider for CryptoAPI on windows, but that might be a
> potentially useful approach. I haven't looked closely, but mozilla-nss
> might be a contender too. GNU TLS might become a good option at some time
> in the life of KDE4.

   mozilla-nss is just downright nasty to work with.  I also fear it will have 
huge overhead.

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