[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Change by Julian Berman : -- nosy: +Julian ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Steve Dower added the comment: > I don't think that adding a parameter for opt-in for security is a good > approach. I meant to have it set by default on 3.10, when we do not have to worry about breaking users. If it takes years for users to get to 3.10, we should reevaluate our release

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

STINNER Victor added the comment: > In this case, having it off by default goes further to prevent breakage PyYAML was unsafe by default: it allowed to execute arbitary Python code by default. It took years to change the default to "safe". I don't think that adding a parameter for opt-in

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Steve Dower added the comment: The important quote from the linked issue seems to be: > Our new separator= parameter does not allow one to achieve the previous > behavior if mixing and matching & And ; was intended to be allowed, as it is > a single separator rather than a set of

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

STINNER Victor added the comment: > 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. Last time we added a new parameter in a stable branch, it didn't go well:

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Steve Dower added the comment: (Copied from my comment on the PR, following the one where I said this was ready to go.) 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

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Łukasz Langa added the comment: Deferred the blocker to the next regular release due to lack of activity in time for the current expedited releases. -- ___ Python tracker ___

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Change by Łukasz Langa : -- priority: release blocker -> deferred blocker ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Change by Christian Heimes : -- nosy: +lukasz.langa priority: critical -> release blocker ___ Python tracker ___ ___

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Change by George-Cristian Bîrzan : -- nosy: +gc2 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

STINNER Victor added the comment: > The patch should not have landed in 3.8. At a bare minimum the patch should > have been postponed until documentation was updated. Since 3.8 the ipaddresss > does not behave as documented. A similar security issue in NPM was published > two days ago,

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Change by Christian Heimes : -- keywords: +patch pull_requests: +23844 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/25099 ___ Python tracker

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Christian Heimes added the comment: Serhiy was right, this is a security issue. The patch should not have landed in 3.8. At a bare minimum the patch should have been postponed until documentation was updated. Since 3.8 the ipaddresss does not behave as documented. A similar security issue

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Nick Coghlan added the comment: The recommended handling in the article that Serhiy mentions is to strip the leading zeroes, which the ipaddress module will still do - it's only being made more tolerant on input. That means it will become usable as a prefilter step (pass string with

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Eric V. Smith added the comment: I think it should be 3.8 only, and the docs should be updated. Apologies for not catching that earlier: I searched via Google, which was a mistake. -- ___ Python tracker

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Serhiy Storchaka added the comment: See also the article "Ping and FTP Resolve IP Address with Leading Zero as Octal" (https://web.archive.org/web/20061206211851/http://support.microsoft.com/kb/115388). This is still true in Windows 10. So it is safer to reject IPv4 addresses with leading

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Ned Deily added the comment: ipaddress is behaving as documented: "The following constitutes a valid IPv4 address: A string in decimal-dot notation, consisting of four decimal integers in the inclusive range 0–255, separated by dots (e.g. 192.168.0.1). Each integer represents an octet

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Change by Karthikeyan Singaravelan : -- status: open -> pending ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Change by Karthikeyan Singaravelan : -- nosy: +ned.deily status: pending -> open ___ Python tracker ___ ___ Python-bugs-list

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Nick Coghlan added the comment: I've merged the change for Python 3.8 (thanks Joel!). I'm not sure whether to classify it as an enhancement or as an interoperability bug fix, though, so I've put the status to pending and added Ned to the nosy list to get his thoughts as the Python 3.7 RM.

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Nick Coghlan added the comment: New changeset e653d4d8e820a7a004ad399530af0135b45db27a by Nick Coghlan (Joel Croteau) in branch 'master': bpo-36384: Remove check for leading zeroes in IPv4 addresses (GH-12577) https://github.com/python/cpython/commit/e653d4d8e820a7a004ad399530af0135b45db27a

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Change by Serhiy Storchaka : -- nosy: +ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Change by Roundup Robot : -- keywords: +patch pull_requests: +12521 stage: -> patch review ___ Python tracker ___ ___

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Eric V. Smith added the comment: I agree that this is not a useful check. -- nosy: +eric.smith ___ Python tracker ___ ___

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

Change by SilentGhost : -- nosy: +pmoody versions: -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.9 ___ Python tracker ___

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal

New submission from Joel Croteau : I understand to a certain extent the logic in not allowing IPv4 octets that might ambiguously be octal, but in practice, it just seems like it creates additional parsing hassle needlessly. I have never in many years of working on many networked systems seen