bpo-36384: Leading zeros in IPv4 addresses are no longer tolerated

[tiran]

Reverts commit e653d4d and makes
parsing even more strict. Like socket.inet_pton() any leading zero
is now treated as invalid input.

Signed-off-by: Christian Heimes [email protected]

https://bugs.python.org/issue36384

[serhiy-storchaka]

What's New entry?

[tiran]

I' leaving the whatsnew entry to release managers.

[vstinner]

I' leaving the whatsnew entry to release managers.

Usually, release managers don't maintain the What's New document. Since this change is backward incompatible, IMO it would deserve a "Notable changes in Python 3.x.y" in their What's New document in 3.6-3.9 branches. Example for a recent security fix:
https://docs.python.org/dev/whatsnew/3.7.html#notable-changes-in-python-3-7-10

For Python 3.10, it can be written in the https://docs.python.org/dev/whatsnew/3.10.html#changes-in-the-python-api section.

[zooba]

This looks ready to me, and Christian has asked someone else to finish the merge as he's out.

Any other feedback? @vstinner, @serhiy-storchaka, are you guys happy with the changes (pending the versionchanged being updated in each backport)?

[zooba]

Withdrawing the readiness - @ambv and I would prefer to see this behind a flag (probably "strict" parsing), on by default for 3.10, and maybe on by default for 3.9/earlier.

The main reasoning being that this isn't our vulnerability, but an inconsistency with other vulnerable libraries. The current fix is the best it can be, but it doesn't prevent the vulnerability, it just causes Python to break first. So it ought to be relatively easy to retain the flexible (though admittedly non-sensical) behaviour for those who currently rely on it.

[miss-islington]

Thanks @tiran for the PR, and @ambv for merging it 🌮🎉.. I'm working now to backport this PR to: 3.8, 3.9.
🐍🍒⛏🤖

[miss-islington]

Sorry, @tiran and @ambv, I could not cleanly backport this to 3.8 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker 60ce8f0be6354ad565393ab449d8de5d713f35bc 3.8

[bedevere-bot]

GH-25815 is a backport of this pull request to the 3.9 branch.

[kwiatekus]

Thanks @tiran for the fix.
Is it still planned to back-port the fix to 3.8 (in spite of conflicts) ?

[bedevere-bot]

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot AMD64 Windows10 3.8 has failed when building commit 03dd89d.

What do you need to do:

1. Don't panic.
2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/258/builds/43) and take a look at the build logs.
4. Check if the failure is related to this commit (03dd89d) or if it is a false positive.
5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/258/builds/43

Failed tests:

• test_compile

Failed subtests:

• test_stack_overflow - test.test_compile.TestSpecifics
• test_no_args_respects_force_flag - test.test_compileall.CommmandLineTestsNoSourceEpoch

Summary of the results of the build (if available):

== Tests result: FAILURE then FAILURE ==

392 tests OK.

10 slowest tests:

• test_multiprocessing_spawn: 3 min 9 sec
• test_tokenize: 2 min 43 sec
• test_tools: 2 min 21 sec
• test_concurrent_futures: 1 min 52 sec
• test_mmap: 1 min 43 sec
• test_lib2to3: 1 min 24 sec
• test_asyncio: 1 min 11 sec
• test_io: 1 min 9 sec
• test_socket: 1 min
• test_pickle: 52.2 sec

1 test failed:
test_compile

30 tests skipped:
test_curses test_dbm_gnu test_dbm_ndbm test_devpoll test_epoll
test_fcntl test_fork1 test_gdb test_grp test_ioctl test_kqueue
test_multiprocessing_fork test_multiprocessing_forkserver test_nis
test_openpty test_ossaudiodev test_pipes test_poll test_posix
test_pty test_pwd test_readline test_resource test_spwd
test_syslog test_threadsignals test_wait3 test_wait4
test_xxtestfuzz test_zipfile64

2 re-run tests:
test_compile test_compileall

Total duration: 11 min 21 sec

Click to see traceback logs

Traceback (most recent call last):
  File "D:\buildarea\3.8.bolen-windows10\build\lib\test\test_py_compile.py", line 22, in wrapper
    return fxn(*args, **kwargs)
  File "D:\buildarea\3.8.bolen-windows10\build\lib\test\test_py_compile.py", line 22, in wrapper
    return fxn(*args, **kwargs)
  File "D:\buildarea\3.8.bolen-windows10\build\lib\test\test_compileall.py", line 322, in test_no_args_respects_force_flag
    self.assertRunOK('-f', PYTHONPATH=self.directory)
  File "D:\buildarea\3.8.bolen-windows10\build\lib\test\test_compileall.py", line 271, in assertRunOK
    rc, out, err = script_helper.assert_python_ok(
  File "D:\buildarea\3.8.bolen-windows10\build\lib\test\support\script_helper.py", line 157, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "D:\buildarea\3.8.bolen-windows10\build\lib\test\support\script_helper.py", line 143, in _assert_python
    res.fail(cmd_line)
  File "D:\buildarea\3.8.bolen-windows10\build\lib\test\support\script_helper.py", line 70, in fail
    raise AssertionError("Process return code is %d\n"
AssertionError: Process return code is 1
command line: ['D:\\buildarea\\3.8.bolen-windows10\\build\\PCbuild\\amd64\\python_d.exe', '-X', 'faulthandler', '-S', '-m', 'compileall', '-f']


Traceback (most recent call last):
  File "D:\buildarea\3.8.bolen-windows10\build\lib\test\test_compile.py", line 698, in test_stack_overflow
    compile("if a: b\n" * 200000, "<dummy>", "exec")
MemoryError