Geert Jansen added the comment:
Thanks Antoine. See my comments below:
> - is it necessary to start exposing server_hostname, server_side and
> pending()?
At the C level I need server_hostname and server_side exposed because they are
needed to implement the cert check in do_handshake(). SSLObject gets a C-level
_SSLSocket passed to its constructor and doesn't create it itself. So it can't
store these attributes.
At the Python level SSLSocket already had these, albeit undocumented, so that's
why I added them to SSLObject as well.
We can leave these undocumented at the Python level if you prefer.
> - SSLObject is a bit vague, should we call it SSLMemoryObject? or do you
> expect we may want to support other kinds of BIOs some day?
OpenSSL calls the struct just "SSL" which I think is even less descriptive. I
think the best description in words is an "SSL protocol instance", however
SSLProtocolInstance looks a bit too long to me. Maybe just "SSLInstance", would
that be better than "SSLObject"?
I don't think we want to tie the name to the Memory BIO as I think that it may
be useful some day to support other BIOs notably the Socket BIO. I believe that
the overall _ssl/ssl code could be simplified by:
- Making SSLSocket inherit from SSLObject and socket.
- Remove all socket handling from _ssl and use a Socket BIO instead.
- Implement the blocking semantics for do_handshake(), unwrap(), read() and
write() at the Python level.
For testing and benchmarks, the null BIO might be useful as well.
> - should the basic implementations in SSLObject be shared (using some kind of
> mixin) with SSLSocket, or is it unpractical to do so?
It's possible but I am not sure it would simplify the code a lot. For example,
there's no notion of a "closed" or an "unwrapped" socket in SSLObject. If you
look at the "cipher" method for example. This is how it looks for SSLSocket:
def cipher(self):
self._checkClosed()
if not self._sslobj:
return None
else:
return self._sslobj.cipher()
And this is how it looks for SSLObject:
def cipher(self):
return self._sslobj.cipher()
To use SSLObject as a mixin it would have to be aware of these two uses of its
subclasses. It could be done but I don't think it's 100% clean either.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue21965>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
