Request to merge the newssl branch

[Andreas Hartmetz]

Am Mittwoch 12 Dezember 2007 14:14:18 schrieb Andreas Hartmetz:
> 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
> branches/work/newssl
> 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 implementation.
>
> 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 things.
> 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!
>
The number of comments gives me some hint about why nobody else took care of 
SSL. I should mention that I'm doing this on paid time by KDAB; it's not like 
I like to read books about SSL in my free time :P
However, I am very interested in getting a KDE 4.0(.0) out of the door in a 
condition that at least the lunatic fringe 
http://www.sunsite.ualberta.ca/jargon/html/L/lunatic-fringe.html
can enjoy.
It seems that at least basic surfing on HTTPS sites works with mainline KSSL 
which is why I am not pushing harder to merge newssl.
A peek on the release-team list gives me the impression that the chance 
of getting this in is not very big. In that case I *STRONGLY* suggest merging 
the branch at the next possible bugfix release. This is about fixing 
something that doesn't work even though it means new code. IMO it would be 
silly to wait longer "because rules are rules".
I should mention that most tricky security relevant things are being handled 
by the backend (QSslSocket(OpenSSL) for now) so you don't have to trust me to 
get these things right at the first try. I wouldn't trust me on that either.