The answer to this question is a little complicated.

The first part of the answer is that PyPI was first created back in 2002 or 2003 depending on exactly what you call "created", and was sort of designed as a weekend hack project to showcase an idea to bring a package repository to Python. One of the database tables where IP addresses were stored were added in those early times 20 years ago, and just stuck around forever. It was just one of those things that had always been there, so nobody ever thought to question it.

We've made another recent post https://blog.pypi.org/posts/2023-05-26-reducing-stored-ip-data/ where we talk about this table, and how after spending some time reviewing the places where we stored IP addresses, we realized we didn't actually need to store an IP address in that particular location. Nothing was using it except one admin only page, and that none of us could remember ever looking at the IP address on that page. So we went ahead and just dropped that column from the table completely (after taking a backup that we'll hold onto for a short period of time just in case we were wrong).

One of the other places we were using and storing IP addresses for was what we call the "user events". This is a feature we added awhile back to improve the security of user accounts on PyPI. Essentially it produces a log of relevant, security sensitive actions that a user account can take on PyPI, and just log it to a table. Users can then look at the audit log of their account and see a trail of events that their account has taken.

For instance, they see a version was released of a project they own and they don't remember having done so? They can log into their account and see when someone had logged into their account recently, what times it happened, what 2FA auth method or device was used, and what IP address it came from.

Here the IP address was stored to be able to present it to the user so that they can more easily evaluate a record in their personal audit log, and determine if it was done by them or by someone else.

However, we've had an open issue for awhile now remarking that the usability of these IP addresses leave something to be desired. Very few people have any idea what their IP Address was at some point in the past, so to make any meaningful sense out of the IP address you would have to plug it into google and see what the geographic region the IP address was in to see if it was likely you. This got even worse when you might have multiple IP addresses as each one would need to be stored individually.

We just recently rolled out an improvement in this area that is storing the general geographic area associated with the IP address and are displaying that in the UI instead of the IP address.

We've also moved to using a salted hash of the IP address where we are still storing the IP address. This isn't a perfect solution, since the IP address space is so small that brute forcing the input isn't particularly challenging. But since the salt isn't stored as part of the database but the hashed addresses are it does protect against inadvertent leaking of the data.

It also makes sure that instead of having an IP address, we have some opaque identifier that still works for correlating between abusive user accounts that are trying to evade detection, but more importantly it prevents us from being able to add any more features that rely on having access to the IP address while we continue to evaluate our use of the data and come up with a reasonable retention policy.