TypeError: object of type 'IPv6Address' has no len() when running tests with GeoDjango

[Natalia Bidart]

Following the security release for 5.1.5, 5.0.11 and 4.2.18, there seems to be an issue with the GeoDjango tests:

Traceback (most recent call last):
  File "/home/jenkins/workspace/pull-requests-focal/database/mysql_gis/label/focal-pr/python/python3.10/django/core/validators.py", line 305, in validate_ipv4_address
    ipaddress.IPv4Address(value)
  File "/usr/lib/python3.10/ipaddress.py", line 1305, in __init__
    self._ip = self._ip_int_from_string(addr_str)
  File "/usr/lib/python3.10/ipaddress.py", line 1192, in _ip_int_from_string
    raise AddressValueError("Expected 4 octets in %r" % ip_str)
ipaddress.AddressValueError: Expected 4 octets in '::ffff:27d:a0d8'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/jenkins/workspace/pull-requests-focal/database/mysql_gis/label/focal-pr/python/python3.10/django/core/validators.py", line 325, in validate_ipv46_address
    validate_ipv4_address(value)
  File "/home/jenkins/workspace/pull-requests-focal/database/mysql_gis/label/focal-pr/python/python3.10/django/core/validators.py", line 307, in validate_ipv4_address
    raise ValidationError(
django.core.exceptions.ValidationError: ['Enter a valid IPv4 address.']

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/jenkins/workspace/pull-requests-focal/database/mysql_gis/label/focal-pr/python/python3.10/tests/gis_tests/test_geoip2.py", line 131, in test_country
    self.assertEqual(g.country(query), self.expected_country)
  File "/home/jenkins/workspace/pull-requests-focal/database/mysql_gis/label/focal-pr/python/python3.10/django/contrib/gis/geoip2.py", line 207, in country
    response = self._query(query, require_city=False)
  File "/home/jenkins/workspace/pull-requests-focal/database/mysql_gis/label/focal-pr/python/python3.10/django/contrib/gis/geoip2.py", line 157, in _query
    validate_ipv46_address(query)
  File "/home/jenkins/workspace/pull-requests-focal/database/mysql_gis/label/focal-pr/python/python3.10/django/core/validators.py", line 328, in validate_ipv46_address
    validate_ipv6_address(value)
  File "/home/jenkins/workspace/pull-requests-focal/database/mysql_gis/label/focal-pr/python/python3.10/django/core/validators.py", line 315, in validate_ipv6_address
    if not is_valid_ipv6_address(value):
  File "/home/jenkins/workspace/pull-requests-focal/database/mysql_gis/label/focal-pr/python/python3.10/django/utils/ipv6.py", line 59, in is_valid_ipv6_address
    _ipv6_address_from_str(ip_str)
  File "/home/jenkins/workspace/pull-requests-focal/database/mysql_gis/label/focal-pr/python/python3.10/django/utils/ipv6.py", line 10, in _ipv6_address_from_str
    if len(ip_str) > max_length:
TypeError: object of type 'IPv6Address' has no len()

[Mariusz Felisiak]

Sorry, I've notice the ticket when I had a patch ready. Feel-free to close it, ​PR.

We have two issues here:

• first GeoIP2._query() unnecessarily calls validate_ipv46_address for always valid query,
• second validate_ipv46_address() and validate_ipv6_address() crash on ipaddress.IPv6Address instances.

I know that calling validate_ipv46_address()/validate_ipv6_address() is pointless, but it worked for years so I'd fix it.

[Natalia Bidart]

Thank you Mariusz, let's push forward your PR, mine needs tests still and release note. I will re-assign this to you. I guess I should issue releases ASAP? Is there a precedent for how to handle cases like this?

We also need to update the docstrings of the two validator helpers because they clearly state that a string is expected (and this is what caused the issue in the first place). I agree with you that we can't change that behavior (i.e. the validators should work with ipv4 and ipv6 instances), so we need to update the docstrings. I will add further comments in the PR.

[Mariusz Felisiak]

I guess I should issue releases ASAP? Is there a precedent for how to handle cases like this?

It depends how serious a regression is. It's not very urgent, but releasing a hot-fix wouldn't hurt. The last time I remember was in 2021, when we issued 9 releases in two week :)

• ​https://www.djangoproject.com/weblog/2021/may/04/security-releases/
• ​https://www.djangoproject.com/weblog/2021/may/06/security-releases/
• ​https://www.djangoproject.com/weblog/2021/may/13/bugfix-releases/

[Natalia Bidart]

Replying to Mariusz Felisiak:

I guess I should issue releases ASAP? Is there a precedent for how to handle cases like this?

It depends how serious a regression is. It's not very urgent, but releasing a hot-fix wouldn't hurt. The last time I remember was in 2021, when we issued 9 releases in two week :)

• ​https://www.djangoproject.com/weblog/2021/may/04/security-releases/
• ​https://www.djangoproject.com/weblog/2021/may/06/security-releases/
• ​https://www.djangoproject.com/weblog/2021/may/13/bugfix-releases/

Thank you for the pointers, I will consider doing releases tomorrow morning, before Sarah cuts the new stable branch (will add Sarah as cc).