KDE Cryptography Module

[Thiago Macieira]

Alon Bar-Lev wrote:
>> First things first: we're almost two months past the deadline for
>> major frameworks in KDE 4.0. So the CRYPTO framework we're discussing
>> now is a KDE 4.1 thing.
>
>But QCA was targeted to KDE 4.0... The fact that Trolltech wrote
>something should not have changed your plans without carefully analyze
>what is left out.

It has not.

We are carefully analysing, aren't we? But facts are facts: the deadline 
was April 1st for new modules. Therefore, no KDE CRYPTO module for KDE 
4.0.

>> Frankly, I'd rather avoid adding that class to KDE code, first because
>> it would be something more to maintain until KDE 5.0. Second, because
>> we already have two classes to choose from.
>
>No you don't!
>They are not equal... Please try to understand that.

They are not equal.

But for *my* purposes as an encrypted socket class, it is enough. All I 
want is encrypted communication. I want KDE 4.0 to have both https 
support in ioslaves as well as IMAPS/POP3S or STARTTLS support.

>We cannot implement smartcard support into QtSslSocket.
>We cannot implement policy without more OpenSSL code and much more
>issues I raised in my previous corresponding.

Let's get it straight: KDE 4.0 will not have smartcard support. Period. 
KDE 4.1 might.

And you're basing your conclusions on what QSslSocket is now, not what it 
can be. I still don't buy the argument that it can NEVER EVER support 
smartcards.

>> Whichever form we choose, we have to make the choice before KDE 4.0 is
>> out, since the class we choose will be used by applications and we'll
>> have to keep on supporting it (even if as a compatibility mode) until
>> KDE 5.0.
>>
>> Right now, in code, the choice is QSslSocket. And Mailody is already
>> using it.
>
>So you violated your own roadmap... Just because it seems nice?

What part of "I wanted a secure socket class" did you not understand?

Mailody is using QSslSocket without any certificate store or policy 
management. This is obviously not acceptable for a release. It's using 
QSslSocket for the simple fact that I wrote

   QTcpSocket *socket = new QSslSocket(parent);

somewhere in ksocketfactory.cpp because I thought "hey, that would be 
nice". That feature is not documented so, technically, no one should be 
using it. In fact, I plan to remove it, just to make sure that QSslSocket 
doesn't get widespread use before we implement the rest of the support it 
needs -- if we choose it at all.

>I 
>really don't understand. Your user community will have to wait at
>least one more year for progress? And then what? Trolltech will
>release some other small feature that will change your strategy?

Yes, the user community will wait another year. They will wait for KDE 4.1 
because 4.0 will not have smartcard support. We have no CRYPTO right now 
and, logically, no application can be using something that doesn't exist.

>I must say, to an external guy... this is a strange way to manage a
> project...

Two things are guiding the management:
1) "He who does the work decides"→ no one has done the work in the 2 years 
that KDE 4 is in development
2) KDE 4.0 is not the end of KDE 4.x

>So I guess you tell me that you are in favor of using QSslSocket...
>And we will have no smartcard support until KDE 5.

You are quite quick to jump to conclusions, aren't you?

No, I am not in favour of any solution. Right now, I am pending more 
towards to QCA, but I can still change my mind.

I am not afraid to say that. It wouldn't be the first time that KDE 
applications are prohibited from using a Qt class. That happens with 
QHttp, for instance. During KDE 3 times, QSocket was also off-limits.

We have not made that decision yet. And decision = code.

>OK... This is good enough... But I don't see any change in KDE 5,
>since the issues will be the same... and the political affiliation
>with Trolltech remains. So actually until Trolltech will supply a
>decent cryptographic solution your users will not be able to use
>hardware cryptography.

You're not making friends with that assumption.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- 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/20070523/67cd3173/attachment.sig>