Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gh-117566: fix IPv6Address.is_loopback for IPv4-mapped loopbacks #117567

Merged
merged 2 commits into from Apr 25, 2024

Conversation

paravoid
Copy link
Contributor

@paravoid paravoid commented Apr 5, 2024

While properties like IPv6Address.is_private account for IPv4-mapped IPv6 addresses, such as for example:

>>> ipaddress.ip_address("192.168.0.1").is_private
True
>>> ipaddress.ip_address("::ffff:192.168.0.1").is_private
True

...the same doesn't currently apply to the is_loopback property:

>>> ipaddress.ip_address("127.0.0.1").is_loopback
True
>>> ipaddress.ip_address("::ffff:127.0.0.1").is_loopback
False

At minimum, this inconsistency between different properties is counter-intuitive. Moreover, ::ffff:127.0.0.0/104 is for all intents and purposes a loopback address, and should be treated as such.

Copy link

cpython-cla-bot bot commented Apr 5, 2024

All commit authors signed the Contributor License Agreement.
CLA signed

@bedevere-app
Copy link

bedevere-app bot commented Apr 5, 2024

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

@paravoid
Copy link
Contributor Author

@encukou @gpshead, I noticed that you've reviewed this area of code before, and hopefully this is going to be a trivial one for you :) (Apologies beforehand if the direct ping is undesired/spammy, not sure about the etiquette here!)

@encukou
Copy link
Member

encukou commented Apr 23, 2024

Thanks for the fix.
Could you add a simple test as well?

While properties like IPv6Address.is_private account for IPv4-mapped
IPv6 addresses, such as for example:

    >>> ipaddress.ip_address("192.168.0.1").is_private
    True
    >>> ipaddress.ip_address("::ffff:192.168.0.1").is_private
    True
...the same doesn't currently apply to the is_loopback property:
    >>> ipaddress.ip_address("127.0.0.1").is_loopback
    True
    >>> ipaddress.ip_address("::ffff:127.0.0.1").is_loopback
    False

At minimum, this inconsistency between different properties is
counter-intuitive. Moreover, ::ffff:127.0.0.0/104 is for all intents and
purposes a loopback address, and should be treated as such.
@paravoid
Copy link
Contributor Author

Thanks for the fix. Could you add a simple test as well?

Thanks for the quick review! That's a good point, I added tests now as well.

Lib/test/test_ipaddress.py Outdated Show resolved Hide resolved
Copy link
Member

@encukou encukou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thank you!

@encukou encukou enabled auto-merge (squash) April 25, 2024 14:46
@encukou encukou added needs backport to 3.12 bug and security fixes and removed needs backport to 3.12 bug and security fixes labels Apr 25, 2024
@encukou encukou merged commit fb7f79b into python:main Apr 25, 2024
37 checks passed
@paravoid paravoid deleted the ipv4-mapped-loopback branch April 25, 2024 15:35
@paravoid
Copy link
Contributor Author

Looks good, thank you!

Thank you so much for the super quick turnaround! Is this something that should/could also make it to 3.12.x or does it sit outside of the stable bugfix policies?

@encukou encukou added the needs backport to 3.12 bug and security fixes label Apr 29, 2024
@miss-islington-app
Copy link

Thanks @paravoid for the PR, and @encukou for merging it 🌮🎉.. I'm working now to backport this PR to: 3.12.
🐍🍒⛏🤖 I'm not a witch! I'm not a witch!

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Apr 29, 2024
pythonGH-117567)

While properties like IPv6Address.is_private account for IPv4-mapped
IPv6 addresses, such as for example:

    >>> ipaddress.ip_address("192.168.0.1").is_private
    True
    >>> ipaddress.ip_address("::ffff:192.168.0.1").is_private
    True
...the same doesn't currently apply to the is_loopback property:
    >>> ipaddress.ip_address("127.0.0.1").is_loopback
    True
    >>> ipaddress.ip_address("::ffff:127.0.0.1").is_loopback
    False

At minimum, this inconsistency between different properties is
counter-intuitive. Moreover, ::ffff:127.0.0.0/104 is for all intents and
purposes a loopback address, and should be treated as such.
(cherry picked from commit fb7f79b)

Co-authored-by: Faidon Liambotis <paravoid@debian.org>
@bedevere-app
Copy link

bedevere-app bot commented Apr 29, 2024

GH-118391 is a backport of this pull request to the 3.12 branch.

@bedevere-app bedevere-app bot removed the needs backport to 3.12 bug and security fixes label Apr 29, 2024
encukou pushed a commit that referenced this pull request Apr 29, 2024
…ks (GH-117567) (GH-118391)

gh-117566: fix IPv6Address.is_loopback for IPv4-mapped loopbacks (GH-117567)

While properties like IPv6Address.is_private account for IPv4-mapped
IPv6 addresses, such as for example:

    >>> ipaddress.ip_address("192.168.0.1").is_private
    True
    >>> ipaddress.ip_address("::ffff:192.168.0.1").is_private
    True
...the same doesn't currently apply to the is_loopback property:
    >>> ipaddress.ip_address("127.0.0.1").is_loopback
    True
    >>> ipaddress.ip_address("::ffff:127.0.0.1").is_loopback
    False

At minimum, this inconsistency between different properties is
counter-intuitive. Moreover, ::ffff:127.0.0.0/104 is for all intents and
purposes a loopback address, and should be treated as such.

(cherry picked from commit fb7f79b)

Co-authored-by: Faidon Liambotis <paravoid@debian.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants