Qt Crypto Architecture for KDE4?

[Thiago Macieira]

Brad Hards wrote:
>One of the things I'd hoped to do at aKademy was to get some discussion
> going about using QCA in Qt4. Unfortunately I had a cold, and spent
> much too much time sleeping and feeling unmotivated instead. So I
> thought I'd try to kick off some discussion about it now.

Hello, Brad

I had a brief discussion with George Staikos about QCA and we came up with 
a simple plan: we are going to try it.

>1. Re-implement the kdelibs crypto related classes (stuff like
> KMD5/KMD4, perhaps part of KCodecs, KSSL) using QCA. So the API would
> remain pretty much the same, but would be implemented using QCA.

The message-digests and simple encryption routines should certainly be 
implemented using QCA. There's no reason to duplicate code.

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.

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.

>2. Remove most/all of the existing crypto code from kdelibs (and
> possibly other places) and use QCA instead. If there are things that
> QCA can't do that are needed, we just implement the additional parts in
> QCA. Applications then just use QCA for all their crypto needs.

Right, same as before.

>3. Use QCA for the simple stuff (removing KMD4/KMD5) and implement a
> different KDE specific API over the top of QCA for the more complex
> stuff (eg for SASL, SSL, PGP).
>As I see it, the second options would be the cleanest, but probably the
> most work for the application authors. The third is probably the most
> flexible, and might be needed to ensure that QCA doesn't become
> dependent on any part of KDE.

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.

>* Is there a desire to change out the current dependency on OpenSSL? It
> is a bit of work, and the advantages are really only in not having to
> deal with the ugly OpenSSL API (which might make it easier for more
> applications to support security/privacy functions), and for isolating
> the crypto parts (which might be a bigger deal for distributions).

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.

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

>* Requiring QCA does introduce another compile time dependency. We
> wouldn't need openssl, but then most people will already have it.

We'd introduce QCA as a compile-time dependency for kdelibs. OpenSSL is 
already a dependency, so there's no change in that. Currently, however, 
OpenSSL is loaded dynamically, so it's not a hard run-time dependency. 
And that doesn't change with QCA either, because it's loaded by a plugin.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

1. On frumscafte, hwonne time_t wæs náht, se scieppend þone circolwyrde 
wundorcræftlíge cennede and seo eorðe wæs idel and hit wæs gód.
-------------- 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/20050911/68c9d28b/attachment.sig>