[issue24169] sockets convert out-of-range port numbers % 2**16
Kurt Rose added the comment:
I think this may in fact be a bug. There are other places in the socket module
where port is checked, create_connection() just seems to have been missed.
create_connection() and socket.connect() have different behavior:
>>> socket.create_connection( ('google.com', 0x1 + 80) )
>>> socket.socket().connect( ('google.com', 0x1 + 80) )
Traceback (most recent call last):
File "", line 1, in
File "C:\Python27\lib\socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
OverflowError: getsockaddrarg: port must be 0-65535.
https://hg.python.org/cpython/file/712f246da49b/Modules/socketmodule.c#l1395
if (port < 0 || port > 0x) {
PyErr_SetString(
PyExc_OverflowError,
"getsockaddrarg: port must be 0-65535.");
return 0;
}
--
___
Python tracker
<http://bugs.python.org/issue24169>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24169] sockets convert out-of-range port numbers % 2**16
Kurt Rose added the comment: Totally agree this needs to be managed carefully. My goal here was just to raise awareness and see if there is consensus that the behavior should be changed. I came across this because an upstream process had a bug which led to impossible TCP ports being specified. So, for my use case it would have been better if create_connection() had rejected the invalid data. If we are talking about enhancements to the socket module, it would also be nice if errors included the address :-) -- ___ Python tracker <http://bugs.python.org/issue24169> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24169] sockets convert out-of-range port numbers % 2**16
Kurt Rose added the comment:
Sorry, dumb mistake on my part. I should have been calling getpeername(), not
getsockname()
In that case the result is 80:
>>> socket.create_connection( ('google.com', 2**16 + 80) ).getpeername()
('74.125.239.41', 80)
The "random" ports were the client-side ephemeral ports.
--
___
Python tracker
<http://bugs.python.org/issue24169>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24169] sockets convert out-of-range port numbers % 2**16
Kurt Rose added the comment:
I was incorrect -- the result of getsockname() appears to be some garbage port:
>>> socket.create_connection( ('google.com', 2**16 + 80) ).getsockname()
('10.225.89.86', 56446)
>>> socket.create_connection( ('google.com', 2**16 + 80) ).getsockname()
('10.225.89.86', 56447)
>>> socket.create_connection( ('google.com', 2**16 + 80) ).getsockname()
('10.225.89.86', 56448)
>>> socket.create_connection( ('google.com', 2**16 + 80) ).getsockname()
('10.225.89.86', 56449)
>>> socket.create_connection( ('google.com', 2**16 + 80) ).getsockname()
('10.225.89.86', 56450)
>>> socket.create_connection( ('google.com', 2**16 + 80) ).getsockname()
('10.225.89.86', 56451)
>>> socket.create_connection( ('google.com', 2**16 + 80) ).getsockname()
('10.225.89.86', 56452)
Java's stdlib gives a proper error message:
>>> java.net.Socket("google.com", 2**16 + 80)
Traceback (most recent call last):
File "", line 1, in
at java.net.InetSocketAddress.(Unknown Source)
at java.net.Socket.(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Sou
rce)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at org.python.core.PyReflectedConstructor.constructProxy(PyReflectedCons
tructor.java:210)
java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: port out
of range:65616
The .NET runtime also rejects invalid ports:
>>> System.Net.IPEndPoint(0x7F01, 2**16 + 80)
Traceback (most recent call last):
File "", line 1, in
ValueError: Specified argument was out of the range of valid values.
Parameter name: port
IronPython by extension rejects the invalid port:
>>> socket.create_connection( ('google.com', 2**16 + 80) )
Traceback (most recent call last):
File "", line 1, in
ValueError: Specified argument was out of the range of valid values.
Parameter name: port
However, Jython recreates the behavior of CPython:
>>> socket.create_connection( ('google.com', 2**16 + 80) ).getsockname()
(u'10.225.89.86', 63071)
--
___
Python tracker
<http://bugs.python.org/issue24169>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24169] sockets convert out-of-range port numbers % 2**16
New submission from Kurt Rose:
This appears to affect all versions of Python. In a behavior inherited from C,
TCP ports that are > 2 bytes are silently truncated.
Here is a simple reproduction:
>>> socket.create_connection( ('google.com', 2**16 + 80) )
Needs more investigation, but one likely place to make the fix is here:
https://hg.python.org/cpython/file/9d2c4d887c19/Modules/socketmodule.c#l1535
if (!PyArg_ParseTuple(args, "O&i:getsockaddrarg",
idna_converter, &host, &port))
Instead of parsing port with i, use H. This is a deep change to the behavior,
but I think it is very unlikely that users intentionally mean to pass a TCP
port > 2**16. More likely, this is silently swallowing errors.
There no indication that the passed port parameter is not being used for the
actual TCP communication (which is physically impossible because TCP only has a
2 byte port field).
In fact, the socket will continue to "lie" to the user and obfuscate the actual
port being used if getsockname() is called:
>>> socket.create_connection( ('google.com', 2**16 + 80) ).getsockname()
('10.225.89.86', 54899)
--
messages: 242987
nosy: Kurt.Rose
priority: normal
severity: normal
status: open
title: sockets convert out-of-range port numbers % 2**16
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue24169>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21546] int('\0') gives wrong error message
New submission from Kurt Rose:
int() ignores everything after a null byte when reporting an error message.
Here you can see an example of how this manifests, and why could be a problem.
Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> int('a')
Traceback (most recent call last):
File "", line 1, in
ValueError: invalid literal for int() with base 10: 'a'
>>> int('\0a')
Traceback (most recent call last):
File "", line 1, in
ValueError: invalid literal for int() with base 10: ''
>>> int('abc\0def')
Traceback (most recent call last):
File "", line 1, in
ValueError: invalid literal for int() with base 10: 'abc'
--
components: Interpreter Core
messages: 218859
nosy: Kurt.Rose
priority: normal
severity: normal
status: open
title: int('\0') gives wrong error message
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue21546>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20468] resource module documentation is incorrect
New submission from Kurt Rose: The documentation in the resource module for get_page_size() is incorrect. resource.getpagesize() Returns the number of bytes in a system page. (This need not be the same as the hardware page size.) This function is useful for determining the number of bytes of memory a process is using. The third element of the tuple returned by getrusage() describes memory usage in pages; multiplying by page size produces number of bytes. On Linux, the value returned in getrusage().ru_maxrss is in kilobytes. On OS-X it is in bytes. Ideally, this could be put into the documentation, but at least remove the inaccurate recommendation to multiply maxrss by page size :-) -- assignee: ronaldoussoren components: Macintosh messages: 209844 nosy: Kurt.Rose, ronaldoussoren priority: normal severity: normal status: open title: resource module documentation is incorrect versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue20468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
