Request to merge the newssl branch

[Andreas Hartmetz]

Am Montag 17 Dezember 2007 17:05:48 schrieb Andreas Hartmetz:
> Am Freitag 14 Dezember 2007 16:49:13 schrieb David Faure:
> > On Thursday 13 December 2007, Andreas Hartmetz wrote:
> > > > 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.
> >
> > I'm missing one important bit of information: is this patch source+binary
> > compatible, assuming it affects any public API?
> > If it's BIC (and if it has to be BIC), then there is no choice, it -has-
> > to go in now...
> >
> > If we don't merge it now and the kdelibs-4.0 api forces us to keep broken
> > ssl stuff (at the API level) forever, we'll regret it.
>
> Damn, I have forgotten one thing: SSL with proxy is completely wrong in
> trunk. It uses the moste hideous hacks (which it calls "SSL tunneling")
> which are also incompatible with any sane way of handling it, modulo very
> ugly hacks. There is a special mode where you connect the ioslave to the
> proxy instead of to the actual remote host and then you give the address of
> the actual remote host (the ioslave connects to it via proxy) and then
> start SSL. All this special mode stuff needs special cases in TCPSlaveBase
> and the actual protocol implementation on top of it, there is special
> metadata involved... need I go on or do you feel a little sick already?
> It also only works with HTTP - other protocols will just fail when trying
> to use SSL and proxying at the same time.
> This seems to force the decision.

This is quite late but anyway...
Merged in revision 752527 last Monday, fixed by dfaure when I was doing 
christmas-ish stuff (I mainly forgot to svn add new files which fortunately 
were in public svn) and apparently working fine.
ioslaves not in kdelibs, kdepimlibs or kdebase (which I ported) will not 
compile anymore and the ported ones may now contain subtle bugs (this is just 
FYI, no specific reason to assume that). Some non-vital things I removed (the 
HTTP ioslave convenience hacks that make you go "huh?") may need to be 
re-added later in a cleaner way if at all possible.

Small print: proxying actually doesn't work at all ATM and support for proxy 
(authentication) types not supported by QTcpSocket may become *really* 
interesting.