You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Some IPv4 and IPv4-mapped IPv6 properties don't match #122792
The new behavior of the properties breaks backwards compatibility as code that already depends on the existing behavior (which I'll claim there are good reasons for) will now produce incorrect results. Breaking compatibility is fine if the old behavior is a legitimate mistake and didn't make much sense etc. but I don't see this here.
The proposed change makes the API more limiting. Previously, as the user of this API, I was free to decide what to do in case of IPv4-mapped IPv6 addresses – I could unwrap them or not before checking is_link_local, for example. With this change I'm left with no API at all to do the latter.
I think we're lacking the motivating reason behind the change, @sethmlarson can explain more.
Agreed with (2), we need a docs update. But the merged change does not make it inconsistent, the ipaddress docs today are sparse and don't specify the exact behavior when these are used on IPv6Address. To me this change matches what I would assume they would do based on the existing terse docs. https://docs.python.org/3/library/ipaddress.html#ipaddress.IPv6Address.is_multicast
Regarding (3) / (4) do you have practical examples of actual code in use that does not want the new behavior? (got links?) That'd help reason about where this falls into breaking change vs bug fix categories.
Some general background: We've gotten security reports over the years about the ipaddress module in various places because people write code using it for security purposes and wind up surprised when it doesn't behave in the manner their specific application needed and thus maybe they did something undesirable with network traffic as a result.
@jstasiak Thanks for the question, indeed the primary motivation for this change is security, specifically folks using IP address filtering before establishing a connection. Since an IPv4-mapped IPv6 address gets established as an IPv4 address I figured these properties should match the mapped IPv4 address and not the IPv6 address that's mostly being used for framing. If you have better guidance about this case, please share!
@jstasiak Do you have an opinion on the above comment? Otherwise we will continue back-porting this change, we want to make sure we're not breaking any legitimate use-cases unintentionally.
Activity
gh-122792: Make IPv4-mapped IPv6 address properties consistent with I…
pythongh-122792: Make IPv4-mapped IPv6 address properties consistent …
pythongh-122792: Make IPv4-mapped IPv6 address properties consistent …
pythongh-122792: Make IPv4-mapped IPv6 address properties consistent …
pythongh-122792: Make IPv4-mapped IPv6 address properties consistent …
[3.12] gh-122792: Make IPv4-mapped IPv6 address properties consistent…
jstasiak commentedon Sep 7, 2024
Hey, I learned about this issue just today and, as a user of this API, I'd like to express some opposition to it.
My reasons, in no particular order:
is_link_local, for example. With this change I'm left with no API at all to do the latter.cc @gpshead
gpshead commentedon Sep 7, 2024
I think we're lacking the motivating reason behind the change, @sethmlarson can explain more.
Agreed with (2), we need a docs update. But the merged change does not make it inconsistent, the
ipaddressdocs today are sparse and don't specify the exact behavior when these are used on IPv6Address. To me this change matches what I would assume they would do based on the existing terse docs. https://docs.python.org/3/library/ipaddress.html#ipaddress.IPv6Address.is_multicastRegarding (3) / (4) do you have practical examples of actual code in use that does not want the new behavior? (got links?) That'd help reason about where this falls into breaking change vs bug fix categories.
Some general background: We've gotten security reports over the years about the
ipaddressmodule in various places because people write code using it for security purposes and wind up surprised when it doesn't behave in the manner their specific application needed and thus maybe they did something undesirable with network traffic as a result.sethmlarson commentedon Sep 9, 2024
@jstasiak Thanks for the question, indeed the primary motivation for this change is security, specifically folks using IP address filtering before establishing a connection. Since an IPv4-mapped IPv6 address gets established as an IPv4 address I figured these properties should match the mapped IPv4 address and not the IPv6 address that's mostly being used for framing. If you have better guidance about this case, please share!
sethmlarson commentedon Sep 16, 2024
@jstasiak Do you have an opinion on the above comment? Otherwise we will continue back-porting this change, we want to make sure we're not breaking any legitimate use-cases unintentionally.
[3.13] gh-122792: Make IPv4-mapped IPv6 address properties consistent…
[3.11] gh-122792: Make IPv4-mapped IPv6 address properties consistent…
[3.10] gh-122792: Make IPv4-mapped IPv6 address properties consistent…
[3.9] [3.10] pythongh-122792: Make IPv4-mapped IPv6 address propertie…
[3.9] gh-122792: Make IPv4-mapped IPv6 address properties consistent …
ambv commentedon Dec 3, 2024
Given no further comments by jstasiak I backported the rest. This issue is now resolved. Thanks, everyone.
Domains: check for urlparse errors (#11824)
package/python3: security bump to version 3.11.11
[3.9] pythongh-122792: Make IPv4-mapped IPv6 address properties consi…