homepage

I wrote a patch for Python 3 to expose the function
SSL_CTX_set_msg_callback in the module ssl.
Here is a description of this function:
"SSL_CTX_set_msg_callback() or SSL_set_msg_callback() can be used
to define a message callback function cb for observing all SSL/TLS
protocol messages (such as handshake messages) that are received or sent."
There is also a test case included in the patch.
Comments are welcomed.

In your test, is there a reason you don't need to verify that your callback is actually called?
+ def cb(packet):
+ self.assertGreater(len(packet), 0)
+ ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv23)
+ ctx.set_msg_callback(cb)

I'm not sure what would be the best way to verify that. 
What about:
 def test_connect_with_msg_callback(self):
 with support.transient_internet("svn.python.org"):
 self.called = False
 def cb(packet):
 self.assertGreater(len(packet), 0)
 self.called = True
 ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv23)
 ctx.set_msg_callback(cb)
 s = ctx.wrap_socket(socket.socket(socket.AF_INET))
 try:
 s.connect(("svn.python.org", 443))
 self.assertTrue(self.called)
 finally:
 s.close()

That is one way to do it. But it would be better to use a local variable rather than an attribute of the class (because otherwise you have to worry about resetting the value if more than one test uses the same pattern). Something like this would be better
called = []
def cb(packet):
 called.append(1)

I've updated the patch with this method of testing.

I haven't commented on the content of your patch (I'm not knowledgeable enough in this area), but as for your test, I noticed that you removed the part that asserted something about the argument passed to cb().
Ideally when testing a callback, you want to test whatever is important about it, like: that it gets called at the right times (and as many times as it should), and that it is getting passed the right data.
So you might also want to make whatever assertions are appropriate about the packet(s) passed to cb().

Thiébaud, I haven't reviewed the patch in detail, but why does the callback only receive the buffer contents? At the minimum, I think it should also receive write_p (whether the packet is an incoming or outgoing message is a rather useful piece of information).

When I wrote this patch, I was focusing on a particular usage and the buffer was the only parameter that interested me. But you're right, the other parameters should be included. Which brings the following questions:
* write_p looks like a boolean, would it be appropriate to make it like that? Or keep it integer?
* version can be SSL2_VERSION , SSL3_VERSION or TLS1_VERSION. However, these constants are not used yet in _ssl. Should they be mapped to the current ones (with the tricky exception of PROTOCOL_SSLv23)?
* content_type could just be passed as a regular integer.
Thanks

The patch won't be ready for 3.4 beta1 next weekend. Deferring to 3.5

I'm reluctant to add new features to the ssl module unless they increase security. The message callback is a debugging hook to analyse handshake and other low level parts of the protocol.

I talked with other ssl module maintainers. We agreed that the debug callback is out of scope for Python stdlib. The ssl does not try to be an all-encompassing wrapper of OpenSSL.