[issue34747] SSLSocket.context cannot be changed on non-connected sockets
Vincent Pelletier added the comment: Added: affects Python 3.9 This bug is still preventing (...or shall I say "discourages", as the setter is effective but raises) server-side SSL certificate reloading on long-running services. This codepath on listening sockets is necessary for seamless certificate renewal, so the new certificate is used on any accepted connection past the setter call. Is there anything that needs to be changed to the fix I proposed ? Should I open a merge/pull request somewhere ? -- versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue34747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34747] SSLSocket.context cannot be changed on non-connected sockets
Vincent Pelletier added the comment: The reason which led me into this is server certificate renewal: my service crashed on that setter 2 months after starting, when it received a new certificate. I toyed with the idea of closing the listening sockets, but without closing would be even better - code changing socket certificate is much simpler than having to stop all worker treads (SocketServer.ThreadingMixIn), close the listening sockets, and start them all again in new threads with a new wrap_socket'ed listening socket. -- ___ Python tracker <https://bugs.python.org/issue34747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34747] SSLSocket.context cannot be changed on non-connected sockets
Change by Vincent Pelletier : -- assignee: -> christian.heimes components: +Library (Lib), SSL nosy: +christian.heimes ___ Python tracker <https://bugs.python.org/issue34747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34747] SSLSocket.context cannot be changed on non-connected sockets
New submission from Vincent Pelletier : >From ssl.py, both on 2.7.15 and 3.6.6: class SSLSocket(...): ... @context.setter def context(self, ctx): self._context = ctx self._sslobj.context = ctx _sslobj is only set when socket is connected. While this is not a big issue for client sockets as user could just wrap the socket with correct context to begin with, and not a big issue for server sockets for the same reason, it is an issue for listening sockets: they are never connected, by definition, and do not care about _sslobj: upon accept() they only use self._context to wrap created socket. Suggested fix: @context.setter def context(self, ctx): self._context = ctx if self._sslobj: self._sslobj.context = ctx (consistently with how _sslobj is evaluated as a boolean elsewhere in the same class) Suggested workaround (ex: if this fix is not backported to 2.7): try: ssl_socket.context = new_context except AttributeError: pass as _context is changed first, and it's all that matters. -- messages: 325847 nosy: vincent-nexedi priority: normal severity: normal status: open title: SSLSocket.context cannot be changed on non-connected sockets type: behavior versions: Python 2.7, Python 3.6 ___ Python tracker <https://bugs.python.org/issue34747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29404] "TypeError: 'int' does not have the buffer interface" on memoryview over bytearray
Vincent Pelletier added the comment: My original point of view was that: - python3 is right to only accept integers, consistently with "str != bytes" - python2 is rather right to accept str, consistently with "str == bytes" - maybe the bug is that python2 should not reject integers, making the upgrade path to python3 (or the backward compatibility with python2, same thing) easy. The context is that I develop a (pure-python) module interfacing with a C library, and somewhere in there I want to expose a read/write memory area (the bytearray) which first few bytes must not be accessible from the application using my module (because the application does not care about these bytes, and slicing everywhere is not convenient). Also, I do not want to expose ctypes instances (I'm supposed to be the python/C interface so the application does not have to care). So exposing that memory chunk via a memoryview slice over the original bytearray seems (and please do correct me if I am wrong) the right way to implement this: >>> b = bytearray(16) # the "real" buffer >>> c = (ctypes.c_char * 16).from_buffer(b) # for C library >>> v = memoryview(b)[8:] # for host program But because of this memoryview behaviour difference my API will behave inconsistently between python2 and python3. My (naïve) initial idea submitting this bug report was that python2 would be modified to tolerate integers passed to memoryview.__setitem__. But I later realised such change would not be sufficient: python2's memoryview.__getitem__ returns strings where python3's returns integers. I agree that changing such visible behaviour in python2 would be bad. Am I stuck with developing my own proxy class then (likely wrapping memoryview with type-casting glue) ? -- ___ Python tracker <http://bugs.python.org/issue29404> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29404] "TypeError: 'int' does not have the buffer interface" on memoryview over bytearray
New submission from Vincent Pelletier: Quoting a github gist[1] (not mine, I found it while googling for this error) clearly illustrating the issue: # Python 2 >>> b = bytearray(8) >>> v = memoryview(b) >>> v[0] = 42 Traceback (most recent call last): File "", line 1, in TypeError: 'int' does not have the buffer interface >>> b bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00') # Python 3 >>> b = bytearray(8) >>> v = memoryview(b) >>> v[0] = 42 >>> b bytearray(b'*\x00\x00\x00\x00\x00\x00\x00') This is especially annoying as on python3 bytearray.__setitem__ only accepts integers, making working py2 code totally incompatible with py3 in a 2to3-undetectable way. [1] https://gist.github.com/superbobry/b90c0cc7c44beaa51ef9 -- messages: 286567 nosy: vpelletier priority: normal severity: normal status: open title: "TypeError: 'int' does not have the buffer interface" on memoryview over bytearray type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue29404> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15253] xmlrpclib.ServerProxy does not support 2-tuple value for uri parameter
Vincent Pelletier added the comment: Then I guess SafeTransport should be cleaned to remove its dead code (tuple host handling), and the class you link to should be included (in spirit if not verbatim) in xmlrpclib. Also, sorry, I realized after posting that this bug is a dupe of #1581. But the closing reason here is more convincing to me than on #1581. Thanks. -- ___ Python tracker <http://bugs.python.org/issue15253> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15253] xmlrpclib.ServerProxy does not support 2-tuple value for uri parameter
New submission from Vincent Pelletier :
SafeTransport class supports a 2-tuple as uri, in order to pass x509 parameters
to httplib.HTTPSConnection .
xmlrpclib.ServerProxy.__init__ fails when given such tuple, because it calls:
urllib.splittype(uri)
without checking uri type first.
Minimal test case to reproduce is:
import xmlrpclib
xmlrpclib.ServerProxy(('https://example.com', {}))
--
messages: 164676
nosy: vpelletier
priority: normal
severity: normal
status: open
title: xmlrpclib.ServerProxy does not support 2-tuple value for uri parameter
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue15253>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15240] ctype Structure keeps reference to function pointers
Vincent Pelletier added the comment: Trying to generate a graph on several python and several uncommented lines, I see that my test case is incomplete. Time to review my copy. -- resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/issue15240> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15240] ctype Structure keeps reference to function pointers
New submission from Vincent Pelletier : When storing a ctype function pointer in a ctype structure field, a reference remains even when that field is overwritten with some values: - None - None cast into a function pointer But the reference is somehow removed when overwriting the field with a "real" function pointer (a lambda in attached test case). This causes problem when the structure is a class property and function pointer is created out of a method of the same class: a circular reference is created, which is not garbage-collected. To run the attached test case, you need objgraph[1], and to uncomment one (or none) of the commented-out lines in "close" method. [1] http://mg.pov.lt/objgraph/ -- components: ctypes files: reproduce.py messages: 164534 nosy: vpelletier priority: normal severity: normal status: open title: ctype Structure keeps reference to function pointers type: behavior versions: Python 2.6, Python 2.7, Python 3.2 Added file: http://bugs.python.org/file26234/reproduce.py ___ Python tracker <http://bugs.python.org/issue15240> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13840] create_string_buffer rejects str init_or_size parameter
Vincent Pelletier added the comment: Thanks for the quick reply. FWIW, in 2.7 doc ctype.create_string_buffer is said to accept unicode objects as parameter. I don't use this personally, so I don't mind 3.x only working on bytes - and already fixed my code accordingly. It's just that I noticed this after your answer. Also, I didn't try to confirm if it actually works. -- ___ Python tracker <http://bugs.python.org/issue13840> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13840] create_string_buffer rejects str init_or_size parameter
New submission from Vincent Pelletier :
ctypes.create_string_buffer documentation[1] says init_or_size parameter should
accept a string. As of 3.2, it raises:
>>> import ctypes
>>> ctypes.create_string_buffer('foo')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.2/ctypes/__init__.py", line 59, in create_string_buffer
buf.value = init
TypeError: str/bytes expected instead of str instance
It works fine as of 2.7 (and very probably any 2.x up to ctypes introduction):
>>> import ctypes
>>> ctypes.create_string_buffer('foo')
[1] http://docs.python.org/py3k/library/ctypes.html#ctypes.create_string_buffer
Regards,
Vincent Pelletier
--
components: ctypes
messages: 151800
nosy: vpelletier
priority: normal
severity: normal
status: open
title: create_string_buffer rejects str init_or_size parameter
type: behavior
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue13840>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1785] "inspect" gets broken by some descriptors
Vincent Pelletier added the comment: Sorry, I forgot to mention I'm using python2.7 . -- ___ Python tracker <http://bugs.python.org/issue1785> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1785] "inspect" gets broken by some descriptors
Vincent Pelletier added the comment: This change causes the following behaviour: >>> import inspect >>> class B(object): ... def f(self): ... pass ... >>> inspect.getmembers(B, inspect.ismethod) [] While I would expect the result to contain f: >>> inspect.ismethod(B.f) True Isn't this a regression ? Regards, Vincent Pelletier -- nosy: +vpelletier ___ Python tracker <http://bugs.python.org/issue1785> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
