Request to merge the newssl branch

Andreas Hartmetz ahartmetz at
Wed Dec 12 13:14:18 GMT 2007

Hi all,

Judging by the feedback I've gotten it seems that the most nasty SSL problems 
(encrypted SMTP and IMAP in kmail not working(?), can't send files larger 
than ~13 KB) can be fixed by using the KSSL replacement branch
I've been working on. It is not complete, pretty much all customization by GUI 
is not there yet. The SSL Details dialog is mostly working again (and better 
suited to small screens) and remembering certificates is not very far from 
completion, i.e. the API is there and the most important parts of the 

Some things are completely missing like selection of a client certificate.
The most important regression however seems to be that my current version of 
the TCPSlaveBase/HTTP ioslave/KHTML part trio does not "understand" partly 
encrypted websites. The solution involves passing around KIO metadata between 
these three classes and that likely won't change. A little documentation 
about it would help a lot, though. Somebody who knows his way around that 
topic could he really helpful here. Frankly, I have no idea how dangerous or 
secure it is to have some parts of a site encrypted and some not. If the site 
is sound the important data will be safe, but I can't see how one can 
programmatically decide whether a site is encrypting the right/important 
things. That decision (or guess? But where is the security when you guess?) 
needs to be made programmatically to display the right security information 
in the URL and in the SSL Details dialog.

Having said that, the brokenness of the current KSSL seems to be worse than 
that so IMHO it makes sense to switch. I wouldn't want to export *any* new 
classes at first, just the modified TCPSlaveBase which is the base of all 
network protocol ioslaves. It can be done while keeping BC and SC but I'd 
personally prefer changing some return types from ints with several magic 
return values (like -3, 0 and 1) to enums, and moving all externally unused  
protected members of TCPSlaveBase into the private class. In fact that is how 
the branch looks like. Won't fly with the release team, right? It's easy to 
change back. FWIW, it seems to be possible to run a combination of 
the "branched" kdelibs with an otherwise unchanged KDE4 install.
I'm not particularly enthusiastic about switching now but merging at the next 
best possibility (next monday) looks like the best option to me right now 
because lack of features is better than basically not working at all. Of 
course there is no guarantee that, when the branch is merged, KDE won't start 
replacing random images on the web with green dragons or do other stupid 
Maybe there are volunteers to give the branch some more testing? Right now 
however the merge of this monday's changes into the branch is still pending 
so kdelibs from the branch may or may not work with the rest of your KDE4 
install. There is a known bug in the SMTP(IIRC) ioslave that is a simple 
consequence of changing the return type of TCPSlaveBase::startTLS() to an 
enum with values different from the previous int. That will be easy to fix 
one way or another.

Comments please!


More information about the kde-core-devel mailing list