[issue24963] ipaddress.IPv6Network doc typo
New submission from zodalahtathi: This is probably not the biggest bug ever, but in the doc for ipaddress.IPv6Network: An integer packed into a bytes object of length 16, bit-endian should be changed to: An integer packed into a bytes object of length 16, big-endian -- assignee: docs@python components: Documentation messages: 249359 nosy: docs@python, zodalahtathi priority: normal severity: normal status: open title: ipaddress.IPv6Network doc typo versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24963 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24911] Context manager of socket.socket is not documented
New submission from zodalahtathi: socket.socket has a context manager to automatically close the socket with the `with` statement: https://hg.python.org/cpython/file/d1bf181afa82/Lib/socket.py#l138 However it is not documented, unlike socket.create_connection. -- assignee: docs@python components: Documentation messages: 248979 nosy: docs@python, zodalahtathi priority: normal severity: normal status: open title: Context manager of socket.socket is not documented versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24911 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22959] http.client.HTTPSConnection checks hostname when SSL context has check_hostname==False
zodalahtathi added the comment: Thank you -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22959 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22959] http.client.HTTPSConnection checks hostname when SSL context has check_hostname==False
zodalahtathi added the comment: I think it does, when passing a context with ssl_context.verify_mode != ss.CERT_NONE, and when not setting the check_hostname parameter: 1. will_verify will be True (https://hg.python.org/cpython/file/3.4/Lib/http/client.py#l1207) 2. check_hostname will be True too (https://hg.python.org/cpython/file/3.4/Lib/http/client.py#l1209) 3. ssl.match_hostname will be called after the handshake in wrap_socket (https://hg.python.org/cpython/file/3.4/Lib/http/client.py#l1230) The following code shows the problem: import http.client import ssl ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2) ssl_context.verify_mode = ssl.CERT_REQUIRED ssl_context.check_hostname = False https = http.client.HTTPSConnection(localhost, context=ssl_context) print(https._check_hostname) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22959 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22960] xmlrpc.client.ServerProxy() should accept a custom SSL context parameter
zodalahtathi added the comment: Thank you -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22960 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22959] http.client.HTTPSConnection checks hostname when SSL context has check_hostname==False
zodalahtathi added the comment: I agree that changing a default to something less secure is not something to do lightly, however I think forcing a check that is explicitly disabled is a bug and can be counter productive security wise. People who don't have time to look at the stdlib code, and file bug like this are likely to react with fuck it, I'll use plain HTTP. By the way, my use case is precisely xmlrpc. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22959 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22959] http.client.HTTPSConnection checks hostname when SSL context has check_hostname==False
New submission from zodalahtathi: http.client.HTTPSConnection has both a check_hostname parameter, and a context parameter to pass an already setup SSL context. When check_hostname is not set and thus is None, and when passing a SSL context set to NOT check hostnames, ie: import http.client import ssl ssl_context = ssl.create_default_context() ssl_context.check_hostname = False https = http.client.HTTPSConnection(..., context=ssl_context) The https object WILL check hostname. In my opinion the line : https://hg.python.org/cpython/file/3.4/Lib/http/client.py#l1207 will_verify = context.verify_mode != ssl.CERT_NONE Should be changed to: will_verify = (context.verify_mode != ssl.CERT_NONE) and (context.check_hostname) -- components: Library (Lib) messages: 231775 nosy: zodalahtathi priority: normal severity: normal status: open title: http.client.HTTPSConnection checks hostname when SSL context has check_hostname==False type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22959 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22960] xmlrpc.client.ServerProxy() should accept a custom SSL context parameter
New submission from zodalahtathi: When using xmlrpc.server it is possible (despite being intrusive) to use a custom SSL context, ie: import ssl import xmlrpc.server rpc_server = xmlrpc.server.SimpleXMLRPCServer(...) ssl_context = ssl.SSLContext() # setup the context ... rpc_server.socket = ssl_context.wrap_socket(rpc_server.socket, ...) However it is not possible (unless using some ugly monkey patching, which I am ashamed of writing) to do the same for xmlrpc.client. xmlrpc.client.ServerProxy() could accept a context constructor, and pass it to the SafeTransport instance, and then to the http.client.HTTPSConnection instance (https://hg.python.org/cpython/file/3.4/Lib/xmlrpc/client.py#l1338). I would allow passing a SSL context more secure than the default one, and thus improve security. -- components: Library (Lib) messages: 231778 nosy: zodalahtathi priority: normal severity: normal status: open title: xmlrpc.client.ServerProxy() should accept a custom SSL context parameter type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22960 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22712] Add 'input' argument to subprocess.check_call and subprocess.call
New submission from zodalahtathi: Python 3.4 added a 'input' argument to the subprocess.check_output function to send bytes to stdin, but it was surprisingly not added to other subprocess helpers. The same functionality should be added to subprocess.check_call and subprocess.call. -- components: Library (Lib) messages: 229889 nosy: zodalahtathi priority: normal severity: normal status: open title: Add 'input' argument to subprocess.check_call and subprocess.call type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22712 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22712] Add 'input' argument to subprocess.check_call and subprocess.call
zodalahtathi added the comment: I think the 'stdin argument can be any file like or stream for all subprocess functions' approach would be the best solution, because it is misleading to differentiate behavior based on internal implementation details (the use of communicate), when the function names are so close and are expected to have a similar behavior. It's not that I really need or miss the input argument for check call and call (as you said it is easy to circumvent). The issue IMO is that it is unintuitive that it is available for check_output and not others. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22712 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19840] The is no way to tell shutil.move to ignore metadata
New submission from zodalahtathi: shutil.move sometimes fail when the underlining filesystem has limitations. Here is a part of a stacktrace I'm getting : File /usr/local/lib/python3.3/shutil.py, line 534, in move copy2(src, real_dst) File /usr/local/lib/python3.3/shutil.py, line 244, in copy2 copystat(src, dst, follow_symlinks=follow_symlinks) File /usr/local/lib/python3.3/shutil.py, line 192, in copystat lookup(chmod)(dst, mode, follow_symlinks=follow) OSError: [Errno 38] This behaviour is expected because shutil.move uses shutil.copy2 under the hood to copy file data and metadata. However there is no way to tell shutil.move to use shutil.copy and to ignore metadata. Maybe a new copy_metadata parameter (defaulting to True) or copy_function (like in shutil.copytree) would be an elegant solution? -- components: Library (Lib) messages: 204807 nosy: zodalahtathi priority: normal severity: normal status: open title: The is no way to tell shutil.move to ignore metadata type: enhancement versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19840 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14539] logging module: logger does not print log message with logging.INFO level
zodalahtathi m8r-a70...@mailinator.com added the comment: Thank you for the explanation -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14539 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14539] logging module: logger does not print log message with logging.INFO level
New submission from zodalahtathi m8r-a70...@mailinator.com: The logging module does not print logging message when the logging level is set to a level inferior to the default level. I can reproduce it using the Python3 (3.2.2) package from Ubuntu 12.04 beta2, or using a hand compiled Python 3.2.2. The bug is NOT present in Python 3.2.1. ~ $ python3 Python 3.2.3rc2 (default, Mar 21 2012, 16:59:51) [GCC 4.6.3] on linux2 Type help, copyright, credits or license for more information. import logging logger = logging.getLogger() logger.getEffectiveLevel() = logging.WARN True logger.warn(warning message) warning message logger.setLevel(logging.INFO) logger.getEffectiveLevel() = logging.INFO True logger.info(info message) -- messages: 157908 nosy: zodalahtathi priority: normal severity: normal status: open title: logging module: logger does not print log message with logging.INFO level type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14539 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
