KDE Cryptography Module

[Thiago Macieira]

Tom Albers wrote:
>> That's not the way it should be. Certificates should be global in KDE.
>> There should be a standardised window saying "here's a new
>> certificate, do you want to accept it"?
>
>That's exactly what i would prefer and use instantly as soon as there is
> code. QSslSocket is there so people will start using it - even if we
> decide to only support QCA.  So we if we do the latter, please provide
> an interface for QSslSocket where people can pass on the received
> certificate for verification. Delaying it to KDE 4.1 will bring big
> security risks imho.

Exactly.

So, this is being harsh: there is no security interface, so you're not 
allowed to use any in KDE applications. Doing so is a security risk.

>> No, that's the wrong approach.
>>
>> When we bless one alternative in KDE, that's the *only* alternative
>> that will be allowed in KDE code.
>
>Mailody is not part of the main modules. I've used QCA for the KDE3
> releases and implementing TLS/SSL with QCA correctly and for all
> mailservers is a pain to be honest. I will not switch back to QCA.
> Unless of course QCA is wrapped in functions identical to QSslSocket.

That may not happen.

>> If we decide it's QSslSocket, it's that and
>> QCA::TLS or plain sockets are not allowed. Same if we decide to go for
>> QCA::TLS: at that point, QSslSocket is simply not allowed. I don't
>> know if supporting both is possible or even desireable.
>
>'simply not allowed' is a bit harsh. You might mean 'not supported by
> the KDE security team'.  QSslSocket is simply there.

No, I meant "simply not allowed in a KDE application".

Using a class that is not supported means you will have none of the KDE 
configuration available. That may also mean you're connecting to servers 
which the user has explicitly disabled support for. That is a security 
risk.

Of course, it would be just like non-KDE applications. But I think we 
should aim for consistency, shouldn't we?

-- 
  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/20070524/6429bf94/attachment.sig>