Changeset fd10d042b41d removed the wrappers on ssl.SSLSocket for 
the new socket.send/recvmsg() methods (since I forgot to check 
for the existence of the underlying methods - see issue #6560), 
but this leaves SSLSocket with send/recvmsg() methods inherited 
from the underlying socket type; thus SSLSocket.sendmsg() will 
insert the given data into the stream without encrypting it (or 
wrapping it in SSL in any way). 
 
This immediately screws up the SSL connection, resulting in 
receive errors at both ends ("SSL3_GET_RECORD:wrong version 
number" and the like), but the data is clearly visible in a 
packet capture, so it's too late if it was actually something 
secret. 
 
Correspondingly, recvmsg() and recvmsg_into() return the 
encrypted data, and screw up the connection by removing it from 
the SSL stream. 
 
Of course, these methods don't make sense over SSL anyway, but if 
the programmer naively assumes they do, then ideally they should 
not expose any secret information. 
 
Attaching a patch implementing Antoine Pitrou's suggestion that 
the methods should simply raise NotImplementedError.  I don't 
know if these versions should also be added only if present on 
the underlying socket - they're Not Implemented either way :-)

Adding an explanation message to the NotImplementedError would be more helpful. Otherwise, good catch.

On Thu 25 Aug 2011, Antoine Pitrou wrote:
> Adding an explanation message to the NotImplementedError would be more helpful. Otherwise, good catch.

OK, I've copied the messages from the ValueErrors the other
methods raise.

As Antoine said, good catch. I'll be able to incorporate this in the next couple of days.

New changeset b06f011a3529 by Nick Coghlan in branch 'default':
Fix #12835: prevent use of the unencrypted sendmsg/recvmsg APIs on SSL wrapped sockets (Patch by David Watson)
http://hg.python.org/cpython/rev/b06f011a3529