[issue22559] [backport] ssl.MemoryBIO

2017-06-12 Thread STINNER Victor
STINNER Victor added the comment: Christian Heimes: "You have to include the changes from #29334, too." Right now, we are only allow to squash a patch serie into an unique patch. I would prefer to keep the fix of bpo-29334 as a separated commit, so merge it after MemoryBIO is merged. The

[issue22559] [backport] ssl.MemoryBIO

2017-06-12 Thread STINNER Victor
STINNER Victor added the comment: I converted issue22559.diff to a pull request. I only had one conflict! --- Lib/ssl.py +++ Lib/ssl.py @@ -727,11 +857,7 @@ class SSLSocket(socket): if not self._sslobj: raise ValueError("Read on closed or unwrapped SSL socket.")

[issue22559] [backport] ssl.MemoryBIO

2017-06-12 Thread Christian Heimes
Christian Heimes added the comment: You have to include the changes from #29334, too. -- ___ Python tracker ___

[issue22559] [backport] ssl.MemoryBIO

2017-06-12 Thread STINNER Victor
Changes by STINNER Victor : -- pull_requests: +2187 ___ Python tracker ___ ___

[issue22559] [backport] ssl.MemoryBIO

2017-05-11 Thread Geert Jansen
Geert Jansen added the comment: Glyph, if this is just for Twisted you could ship the "sslcompat" module that I'm shipping with Gruvi. It backports the async IO stuff and a few other pieces through an extension module. https://github.com/geertj/gruvi/blob/master/src/sslcompat.c and

[issue22559] [backport] ssl.MemoryBIO

2017-05-11 Thread Glyph Lefkowitz
Glyph Lefkowitz added the comment: For what it's worth, it would still be great if this could be merged. It could help a lot with 2/3 migrations of async code that uses Twisted and wants to adopt some asyncio parts. Right now the stdlib SSL module is de-facto useless in those scenarios and

[issue22559] [backport] ssl.MemoryBIO

2016-09-15 Thread Christian Heimes
Changes by Christian Heimes : -- assignee: -> christian.heimes components: +Extension Modules, SSL type: -> enhancement ___ Python tracker

[issue22559] [backport] ssl.MemoryBIO

2015-09-20 Thread Nick Coghlan
Nick Coghlan added the comment: Guido specifically asked for a new PEP for each resync that explicitly enumerated the changes being backported, after earlier drafts of PEP 466 requested blanket future permission for network security related backports. That approach actually turns out to be

[issue22559] [backport] ssl.MemoryBIO

2015-09-19 Thread Donald Stufft
Donald Stufft added the comment: Now that 3.5 is out, does that mean we can sync 2.7 with the 3.5 ssl again and land this patch? -- ___ Python tracker

[issue22559] [backport] ssl.MemoryBIO

2015-09-19 Thread Antoine Pitrou
Antoine Pitrou added the comment: I don't know or remember what the whole PEP says. In doubt, I suggest floating it by python-dev to get a more informed answer. -- ___ Python tracker

[issue22559] [backport] ssl.MemoryBIO

2015-02-12 Thread STINNER Victor
STINNER Victor added the comment: Since this is such a new feature (not even released in 3.x), I don't think we should put it in 2.7.9. While ssl.MemoryBIO would be very useful on Windows for Trollius (to support SSL with the IOCP event loop), I also consider it as a new feature. It's a

[issue22559] [backport] ssl.MemoryBIO

2015-02-11 Thread Nick Coghlan
Nick Coghlan added the comment: While I agree with the idea of backporting this at some point after it has been published in a 3.x release, Guido also specifically requested that we *not* treat PEP 466 as blanket permission to backport other network security features to Python 2.7. (I

[issue22559] [backport] ssl.MemoryBIO

2014-10-13 Thread Benjamin Peterson
Benjamin Peterson added the comment: We can reevaluate when we know when 2.7.10 will be released. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22559 ___

[issue22559] [backport] ssl.MemoryBIO

2014-10-13 Thread Arfrever Frehtes Taifersar Arahesis
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22559 ___

[issue22559] [backport] ssl.MemoryBIO

2014-10-12 Thread Alex Gaynor
Alex Gaynor added the comment: Would you be ok with it going into 2.7.10? The biggest argument in favor of this is that it significantly reduces the diff between 2.x and 3.x's SSL module, specifically it removes the one major difference between the two of them. --

[issue22559] [backport] ssl.MemoryBIO

2014-10-10 Thread Alex Gaynor
Alex Gaynor added the comment: Updated patch cherry-picks in some of the documentation updates that were pushed by Victor. -- Added file: http://bugs.python.org/file36868/issue22559.diff ___ Python tracker rep...@bugs.python.org

[issue22559] [backport] ssl.MemoryBIO

2014-10-10 Thread Benjamin Peterson
Benjamin Peterson added the comment: Since this is such a new feature (not even released in 3.x), I don't think we should put it in 2.7.9. -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22559

[issue22559] [backport] ssl.MemoryBIO

2014-10-06 Thread Alex Gaynor
Alex Gaynor added the comment: As suggested by Benjamin, I've filed issue22569 to add weakref support to _socket.socket; that will address this and further reduce teh diff with Python3. -- dependencies: +Add support for weakrefs to _socket.socket

[issue22559] [backport] ssl.MemoryBIO

2014-10-06 Thread Alex Gaynor
Alex Gaynor added the comment: New patch works and passes all tests. It's on top of issue22569. -- Added file: http://bugs.python.org/file36827/issue225593.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22559

[issue22559] [backport] ssl.MemoryBIO

2014-10-06 Thread Alex Gaynor
Alex Gaynor added the comment: New patch is the same, it just rebases the socket changes out since Benjamin landed that (thanks!) -- Added file: http://bugs.python.org/file36829/issue22559.diff ___ Python tracker rep...@bugs.python.org

[issue22559] [backport] ssl.MemoryBIO

2014-10-05 Thread Alex Gaynor
New submission from Alex Gaynor: Attached patch is a first-cut at a backport patch. Note that it is not quite a 1-1 with the original: The SSL module backport added a new field for the Python-level SSLSocket reference (ssl_sock), which was a different object from the _socket.socket

[issue22559] [backport] ssl.MemoryBIO

2014-10-05 Thread Geert Jansen
Changes by Geert Jansen gee...@gmail.com: -- nosy: +geertj ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22559 ___ ___ Python-bugs-list mailing

[issue22559] [backport] ssl.MemoryBIO

2014-10-05 Thread Geert Jansen
Geert Jansen added the comment: It seems that SSLSocket.close() doesn't actually close the socket, and that's why the server side read() blocks. It's a bit of a mystery to me how socket.close(), which is called by SSLSocket to do the actual close, is supposed to work. I don't see any calls to

[issue22559] [backport] ssl.MemoryBIO

2014-10-05 Thread Alex Gaynor
Alex Gaynor added the comment: Right, socket._socketobject mearly nulls out the reference to _socket.socket, and lets reference counting take care of the rest. I've more of less got this figured out: * When do_handshake() raises an exception (say, a CertificateError), then a reference to a

[issue22559] [backport] ssl.MemoryBIO

2014-10-05 Thread Geert Jansen
Geert Jansen added the comment: Right, socket._socketobject mearly nulls out the reference to _socket.socket, and lets reference counting take care of the rest. Ugh this is bad... I thought close() was exactly there when you don't want to depend on refcounting for cleanup. * When

[issue22559] [backport] ssl.MemoryBIO

2014-10-05 Thread Alex Gaynor
Alex Gaynor added the comment: Unfortunately it can't be a weakref in python2 :-( In Python3 socket._socketobject *subclasses* _socket.socket, so when we pass self to stuff, it's has the right C-level fields but it's also a Python-levle object so it can have a weakref. In Python2

[issue22559] [backport] ssl.MemoryBIO

2014-10-05 Thread Geert Jansen
Geert Jansen added the comment: In Python2 socket._socketobject composes with _socket.socket, so we pass self._sock, that way it has teh right C-level fields. Unfortunately taking a weakref of _socket.socket is not allowed. I see, and agree that making it weakref-able would be a bad idea