Potential bug in left-padded hex encoded addresses about ipaddress HOT 3 CLOSED

I may think about this some more, but my first thoughts are that:

• it seems odd to be taking one number and converting it to some other number. It's hard to see why anyone would want this.
• it's not clear to me this truncation was ever intended, although it is clear there are plenty of tools (eg firefox and ping) that do this truncation wrt IPv4
• if I allow this by default, I'll probably get issues opened up by people claiming that an obviously invalid address is being accepted as valid
• when you are using the same parser to parse IPv6, it gets even murkier, there is no reason to assume you should truncate to get an IPv4 value, and it clashes with the support for single-segment hex IPv6 addresses
• unlike inet_aton in general, this does not seem like a security issue (like CVE-2021-29921), since this library rejects the initial value, rather than parsing it as something different

So, with my current thinking, I might allow this truncation with some kind of validation option, but for the moment I am leaning against allowing these IPv4 addresses by default.

from ipaddress.

I added the IPv4 parsing parameter allow_inet_aton_extraneous_digits to version 5.5.0. You have to use IPAddressStringParameters to use parsing options, there is an example showing the use of using parsing options in issue #123. When you choose this new IPv4 parsing option it will allow extra characters when parsing IPv4, although a given address might clash with IPv6. When you choose the option while also choosing to disallow IPv6, it will allow unlimited extra characters and mimic exactly the behaviour shown here. As I indicated before, I chose to not make it the default behaviour because it clashes with IPv6 and it seems to me most people would not prefer this behaviour. However, I added it so that people can choose to parse IPv4 in ways that are backwards compatible.
Closing.

from ipaddress.

This is the first time I've seen such a claim, that whatever number you choose will be truncated to 32 bits. This might clash with the heuristics used to distinguish ipv4 from ipv6, since a 32 char (128 bit) hex value is interpreted as an IPv6 address.

I'm also seeing that this is not consistent amongst browsers, since chrome will not treat that as an address, while it is true that firefox will.

inet_aton does not make this clear: "The value a is interpreted as a 32-bit value". It is not clear what "interpreted" means.

from ipaddress.