[Stackless] SocketBio and the mysterious sslwrap

Adam Turk adamlturk at gmail.com
Wed Oct 24 22:58:59 CEST 2012


That would be stupendous if you could submit a patch! It's obviously not a
commonly requested thing, but I think it could be useful.

On Wed, Oct 24, 2012 at 11:06 AM, Kristján Valur Jónsson <
kristjan at ccpgames.com> wrote:

>  doomed indeed!****
>
> Well, ****
>
> I could brush up on my ssl lore, but technically you could create a
> non-blocking socket.  then wrap it using _ssl.****
>
> When you try to send() (or whatever) on your _ssl socket, you should then
> get an exception, indicationg that a non-blocking read or write operation
> could not be done.****
>
> You could then poll select() for your socket until it is either readable
> or writable.****
>
> ** **
>
> All of this is a complete nuisance of course.****
>
> I’ll ask around to see if I can submit the patched _ssl source to the
> public domain.****
>
> ** **
>
> K****
>
> ** **
>
> *From:* stackless-bounces at stackless.com [mailto:
> stackless-bounces at stackless.com] *On Behalf Of *Adam Turk
> *Sent:* 24. október 2012 14:18
> *To:* The Stackless Python Mailing List
> *Subject:* Re: [Stackless] SocketBio and the mysterious sslwrap****
>
> ** **
>
> SocketBio makes a lot more sense now, and that might explain a different
> problem I had during my various attempts of SIGPIPE errors in the ssl
> writes. I'll look at the LoE of modifying _ssl, but I am not optimistic.
> You might hear from me again on that subject. In the meantime, I assume I
> am doomed to use blocking sockets of some kind to get this working?
>
> -Adam****
>
> On Wed, Oct 24, 2012 at 6:48 AM, Kristján Valur Jónsson <
> kristjan at ccpgames.com> wrote:****
>
> Ah.****
>
> The problem is that the patched _ssl module mentioned in stacklesslib is
> code that is proprietory to CCP J****
>
> I did this to allow one to wrap a python object, not just a socket, so
> that the _ssl module would call python callbacks for the actual data
> transfer, rather than attempt doing its own socket communications.****
>
> This would allow you to put any actual transport mechanism in place.****
>
>  ****
>
> I could make this part of the 2.x stackless distro.****
>
>  ****
>
> in 3.x, I think , they already use openssl, which is more low level and
> allows you to drive the ssl thingie yourself.  But I haven’t looked.****
>
>  ****
>
>  ****
>
> *From:* stackless-bounces at stackless.com [mailto:
> stackless-bounces at stackless.com] *On Behalf Of *Adam Turk
> *Sent:* 23. október 2012 14:47
> *To:* stackless at stackless.com
> *Subject:* [Stackless] SocketBio and the mysterious sslwrap****
>
>  ****
>
> List,
>
> 2.7.2 Stackless 3.1b3 060516 (default, Oct 22 2012, 11:45:30) [GCC 4.5.2]
> Stacklesslib Unreleased version  (1.0.4?)
> SleekXMPP 1.1.10
> OpenSSL 0.9.8
>
> I'm working on a project that requires SleekXMPP to run under Stackless.
> Sleek likes to make use of SSL and TLS, and everything seems good until
> Sleek calls do_handshake() on the SSLSocket and a call way down the C stack
> returns Errno 9 Bad file descriptor. The problem is that SSL will return
> this if there's a cert trust problem, but I don't think that's the whole
> issue. It's possibly related to the fact that I wasn't able to use
> SocketBio, using a proxy object instead to get the _socket.socket
> inheritance that _ssl.sslwrap seems to require. There's a note in the
> comments for patch_ssl() that mentions a modifed _ssl module that can wrap
> any object, not just _socket.socket, but I found no other reference. Sleek
> without Stackless and monkeypatching works flawlessly. Has anyone had
> similar issues using Stackless with SSL? Possibly even with Sleek?
>
> -Adam****
>
>
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless****
>
> ** **
>
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20121024/1e8ff7f5/attachment.html>


More information about the Stackless mailing list