I am getting an error while getting distribution for 'ipaddress==1.0.22' using buildout which is not using wheel, but legacy source. The distribution for version 1.0.21 indeed can be found using buildout. Is this a case of a caching issue w/ pypi? I noticed the setup.py in the master branch still points to 1.0.21

Carlos

Unable to test if a subnet/network is wholly contained within another -- all comparisons return false:

>>> from ipaddress import *
>>> net1 = ip_network(u"192.0.2.0/24")
>>> net2 = ip_network(u"192.0.2.112/29")
>>> net1 in net2
False
>>> net2 in net1
False
>>>

Hi Philip,

I'm using 'ipaddress' in my python application 'jadm' which is freebsd jail framework. I want to make a freebsd port for easy distribution. In order to do that i should create freebsd ports for each missing python lib in freebsd ports

'ipaddress' is under PSF license in pypi.python.org which is not clean for third part application can i ask you for you approval to create freebsd port for it. This port still will be with all current license / owner data for 'ipaddress'. Also you will be able to check it in github before submission.

For more information:

port bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193574

jadm app: https://github.com/NikolayDachev/jadm

If i cannot have your approval, i will change my code to not use it.

Regards, Nikolay

Today when running OS updates on gentoo hosts I was greeted with a warning that ipaddress will be dropped from the portage tree in 30 days.

https://packages.gentoo.org/packages/dev-python/ipaddress https://bugs.gentoo.org/743724

I think this is because you're not keeping up with the ever-moving target of python versions. 2.7 and 3.6 are currently bad. Of these, 2.7 is a death sentence.

It would be nice if this important library didn't get pulled because of a lack of housekeeping. Can I help? I have a vested interest in keeping this package in gentoo. I'm not affiliated with the gentoo project. I'm just a programmer who needs this library for my job.

Hi,

NOTE: This is not a bug in ipaddress, documenting here for future reference

I recently encountered incorrect Github linking of this project to https://github.com/HaDiNet/python-ipaddress

I already reported the issue to Github since I think the wrong project is taking all the credits this project deserves.

Thank you.

When creating an IPv6Network with python2 / ipaddress-1.0.22, the network representation is screwed up:

[17:21] line:~% virtualenv testp2ipaddress
Running virtualenv with interpreter /usr/bin/python2
New python executable in /home/nico/testp2ipaddress/bin/python2
Also creating executable in /home/nico/testp2ipaddress/bin/python
Installing setuptools, pkg_resources, pip, wheel...done.
[17:22] line:~% . ./testp2ipaddress/bin/activate
(testp2ipaddress) [17:23] line:~% pip install ipaddress
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.
Collecting ipaddress
  Using cached https://files.pythonhosted.org/packages/fc/d0/7fc3a811e011d4b388be48a0e381db8d990042df54aa4ef4599a31d39853/ipaddress-1.0.22-py2.py3-none-any.whl
Installing collected packages: ipaddress
Successfully installed ipaddress-1.0.22
(testp2ipaddress) [17:23] line:~% which python
/home/nico/testp2ipaddress/bin/python
(testp2ipaddress) [17:23] line:~% python
Python 2.7.13 (default, Sep 26 2018, 18:42:22)
[GCC 6.3.0 20170516] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ipaddress
>>> ipaddress.ip_network("2001:db8:61::/64")
IPv6Network(u'3230:3031:3a64:6238:3a36:313a:3a2f:3634/128')
>>>

Expected result as seen in python3:

[17:28] line:~% python3
Python 3.5.3 (default, Sep 27 2018, 17:25:39)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ipaddress
>>> ipaddress.ip_network("2001:db8:61::/64")
IPv6Network('2001:db8:61::/64')
>>>

How to reproduce:

import ipaddress
ipaddress.ip_network(u"::0/64").subnet_of(ipaddress.ip_network(u"10.0.0.0/8"))

This throws:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File ".../.venv/local/lib/python2.7/site-packages/ipaddress.py", line 1115, in subnet_of
    return self._is_subnet_of(self, other)
  File ".../.venv/local/lib/python2.7/site-packages/ipaddress.py", line 1106, in _is_subnet_of
    raise TypeError("%s and %s are not of the same version" (a, b))
TypeError: 'unicode' object is not callable

instead of:

TypeError: ::/64 and 10.0.0.0/8 are not of the same version

It would be useful if releases were tagged and pushed as tags. There's a good chance you locally already do so, but haven't pushed them since git doesn't do this by default. You can use git push --tags or if you use annotated tags use followTags to automatically include them on git push.

See https://github.com/maxmind/GeoIP2-python/issues/41

On Ubuntu using 2.7.13, type(ipaddress.ip_address(u'128.101.101.101').packed) returns <type 'str'>, but the user in that issue is reporting receiving <type 'bytearray'> on macOS 10.12.2.

This example works, attempting to exclude a /31:

>>> from __future__ import unicode_literals
>>> from ipaddress import ip_network
>>> n = ip_network('10.0.0.0/24')
>>> n2 = ip_network('10.0.0.2/31')
>>> ns = list(n.address_exclude(n2))
>>> ns
[IPv4Network(u'10.0.0.128/25'), IPv4Network(u'10.0.0.64/26'), IPv4Network(u'10.0.0.32/27'), IPv4Network(u'10.0.0.16/28'), IPv4Network(u'10.0.0.8/29'), IPv4Network(u'10.0.0.4/30'), IPv4Network(u'10.0.0.0/31')]

However, if I change n2 to be a /32, I get...

>>> n2 = ip_network('10.0.0.2/32')
>>> ns = list(n.address_exclude(n2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/jwilhelm/.virtualenvs/thor_api/lib/python2.7/site-packages/ipaddress.py", line 921, in address_exclude
    s1, s2 = s2.subnets()
ValueError: need more than 1 value to unpack
>>>

It appears that this same bug exists upstream as well in Python 3.5.1.

The error message is:

Traceback (most recent call last):
  File "<builtin>/app_main.py", line 75, in run_toplevel
  File "<builtin>/app_main.py", line 601, in run_it
  File "<string>", line 1, in <module>
  File "/Users/alex_gaynor/.virtualenvs/tempenv-24da2037275be/site-packages/ipaddress.py", line 1358, in <module>
    class IPv4Address(_BaseV4, _BaseAddress):
TypeError: __weakref__ slot disallowed: we already got one

I believe putting __slots__ = () on _TotalOrderingMixin will fix it (but I haven't tested)

I am aware that it will not be possible to change this due to compatibility issues but would it be possible for the function to have a return value instead of raising an error? I can think of doing this using arguments or perhaps other function. Just a suggestion.

@phihag is this still maintained? There are three open security issues at the moment, one with a proof of concept developed and no response to tickets or a commit in a few years.

CVE-2020-14422 CVE-2021-29921 CVSS 5.3

In Python before 3,9,5, the ipaddress library mishandles leading zero characters in the octets of an IP address string. This (in some situations) allows attackers to bypass access control that is based on IP addresses.

The IPv6 address is 2002::1. So why does packednot include the inner "2" in the IPv6 address?

>>> 
>>> ip = ipaddress.ip_address('2002::1')
>>> ip
IPv6Address('2002::1')
>>> ip.packed
b' \x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01'
>>> 

I've managed to update this module to the version we currently have in CPython 3.8. The fix for #55 proposed in #56 is also included.

As I explained in #59, some changes might be a little bit backward-incompatible but not in a sense of compatibility with older Pythons but some parts just get deleted in CPython. I haven't seen anything important.

I had to do some small details in different ways or skip a commit or a part of it, here are some notes from the process:

• https://github.com/python/cpython/commit/58a10967619d0281adf346f227c254f1c3b3f32e Not implemented, uses new backward-incompatible str methods
• https://github.com/python/cpython/commit/e59ec1b05d3e1487ca7754530d3748446c9b7dfd Already implemented here (unused methods removed)
• https://github.com/python/cpython/commit/2430d532e240dea55f0082d1e9bf2e0f3d7505be Implemented partially - we have to keep handcrafted cache because functools.cached_property is available only in Python >=3.8.
• https://github.com/python/cpython/commit/6fa84bd12c4b83bee6a41b989363230d5c03b96c Implemented, just self.hostmask is still an attribute and not cached property because the same reason as above
• https://github.com/python/cpython/commit/dc8ce8ead182de46584cc1ed8a8c51d48240cbd5 Cherry-picked from https://github.com/phihag/ipaddress/pull/56 , fixed formatting

All tests are okay locally (in Docker containers) so they should be okay also in the CI. Reviews and tests appreciated.

Hello

I'd really like to see #55 fixed and released via #56 but it might be also possible to update this module to the version currently available in Python 3.8 (for start).

I'd like to be proactive here but I need to know what are your plans with backward compatibility. Are you okay to break backward compatibility to stay close to upstream or not? For example, this commit changes how ipaddress handles leading zeros in IPv4 addresses.

I think I've found all commits we have to backport to update to the version we have in Python 3.8 now. The last commit from upstream I see implemented here is https://github.com/python/cpython/commit/91dc64ba3f51100540b2ab6c6cd72c3bb18a6d49#diff-f67a8b5be6bdc48383d2ab907325a4c75ef998fa7cd0bba382ec2efa7e4f00b5 The list of commits: https://github.com/python/cpython/commits/3.8/Lib/ipaddress.py For example, the first commit in the list to backport (https://github.com/python/cpython/commit/58a10967619d0281adf346f227c254f1c3b3f32e) won't be backported because it uses str.isascii() available only in 3.7 and newer.

Any help appreciated!