[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    Re: [Kopete-devel] [Bug 63457] SSL support for IRC
From:       Jason Keirstead <jason () keirstead ! org>
Date:       2004-02-08 23:32:32
Message-ID: 200402081932.32205.jason () keirstead ! org
[Download RAW message or body]

On February 8, 2004 06:16 pm, Thiago Macieira wrote:
> That's what I meant. You open the socket with KExtendedSocket, then you 
> call release(), delete the object, but the socket will stay open. That 
> way, you have your raw socket for OpenSSL (which it needs anyways).

Ewwww.... I like my method way better (just disconnecting the KExtSocket's
QSocketNotifier and connecting it to my own slot). Doesn't require deletions
of any sort and gives you the whole KExtSocket API still.

> >From what I can see you can't use KSSL with socks at all, since it
> > just wraps OpenSSL, and OpenSSl needs a raw socket to read and write
> > to. Unless you made an intermediary UNIX socket to buffer between
> > them or something.
> 
> ...that OpenSSL always requires a file descriptor and takes upon itself 
> to write and read from it. I've investigated the possibility of 
> intercepting the I/O at libopenssl's level (by implementing a private 
> BIO), but there's no easy way to do that. 

But could you do what I proposed? Use a UNIX socket in between the Socks layer
and OpenSSL ? Seems to me that it would work fine.

Like..

API::write() -> OpenSSL::write() -> write() on UNIX Socket -> API::unixRead() ->
	Socks::write()

API::read() -> OpenSSL::read() -> read() on UNIX socket -> API::unixWrite() ->
	Socks::read()

it seems like at a fundamental level it would work, except for the select() calls
would get tricky.


-- 
There's no place like 127.0.0.1

http://www.keirstead.org
_______________________________________________
Kopete-devel mailing list
Kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]