KDE Cryptography Module

[Alon Bar-Lev]

On 5/23/07, Thiago Macieira <thiago at kde.org> wrote:
>
> Now we're getting somewhere. I call this productive now.

It about time I do something right :)

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

> However, this has impacts on KDE 4.0: more specifically, on KSSL. As
> George said, he wants most of KSSL to be hidden and made private. Only
> the bare minimum should remain. I don't know how this public API would
> look like yet.

When you do, I am sure we can implement this using QCA.

> The way I see it, KDE 4.0 can't do without the secure sockets. All of the
> rest can reasonably wait for KDE 4.1 and a proper CRYPTO. As I said
> before (probably before we switched the thread to k-c-d), applications
> should not change certificates, policies or settings on the sockets.
> That's user configuration and/or KDE-wide policy.

I fully agree that it should be KDE wide policy.

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

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

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

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

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.

Best Regards,
Alon Bar-Lev.