Qt Crypto Architecture for KDE4?

[Brad Hards]

On Monday 12 September 2005 00:03 am, Thiago Macieira wrote:
> The message-digests and simple encryption routines should certainly be
> implemented using QCA. There's no reason to duplicate code.
I'd agree. The question is whether we keep the KMD4 type classes at all 
(either as a first class citizen, or in kde3support).

> However, KSSL is a lot more complicated. Getting it right was really
> difficult in the KDE2 times and we don't have a complete test suite to
> make sure our reimplementation in QCA is working fine. So we have to do
> the bare minimum of changes necessary.
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?

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

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

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

> >* The providers aren't all done. Surely they will be more complete by
> > KDE4, but I worry a bit about holding up development because of lack of
> > functionality.
>
> Aside from OpenSSL and GNU TLS, which other ones are there?
I'm more thinking about things other than SSL/TLS, such as PKCS#11 tokens and 
SASL. The gnupg stuff probably needs some more work too.

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/20050912/f7930de9/attachment.sig>