Projects automatically deleted from Pypi

I have been doing some research and had to create a bunch of python packages for it and upload them to Pypi. When I logged in today, I noticed that all my projects were deleted and I didn’t get any notification to my email regarding the deletion. Can someone please explain the reason behind it?

They are not even stale projects either. I just created them in the last month.

What packages have you uploaded? What is your user name on PyPI and what is your research?

I wonder if you are RemindSupplyChainRisks.

2 Likes

You are correct. The projects are were removed on 2021-05-03 and all project names were prohibited from re-registration.

1 Like

Additionally, PyPI is not a research platform. If you want to test whether it is possible to install packages unexpectedly, we’d suggest setting up your own controlled environment and demonstrating it there.

If your “research” requires them to be installed by unsuspecting users, we consider you malicious, not a researcher, and will remove/block packages and/or users without notice.

11 Likes

IIUC, this is the user on PyPI: Profile of cr4ck.pw · PyPI?

Their projects were similarly trimmed and it seems that they’ve started publishing on other names as well.

2 Likes

I have pinged @EWDurbin. They are going to look into the user again.

2 Likes

Yes, that is the user name on pypi.

No, this is not me. my username is cr4ck.pw and I was researching on dependency confusion.

I only registered the the package names and didn’t publish any code.

Are you actively trying to catch Facebook / Google / Microsoft projects by surprise?

I get some serious University of Minnesota vs Linux Kernel vibes here.

4 Likes

totally understand, I was not trying to push any code to the platform. I was only registering the package names. Mainly to understand the number of projects we are using which has internal dependencies that are not published on pypi and wanted to claim them so no one could register them.

We do use some open source projects from those companies.

I don’t see how it makes it ok to shotgun-squat random names on PyPI just to see if anything sticks.

We do

Also, out of curiosity, who’s “we”?

1 Like

I should have probably looked at the T&C before registering the names. My bad, sorry!

We → the company I work for.

Is that what you are asking?

The proper solution for a company who has internal packages is not to register all of those package names on PyPI. The proper solution is to ensure that your company’s systems block packages from PyPI which have the same (or even similar, as in typosquat) names as your internal packages. This is simplest to do when when your internal packages are consistently named with a common prefix (e.g. the company name).

Filling up PyPI with millions of package names that have no content is not going to be maintainable.

12 Likes

It looks like a bunch of packages have been removed from my account also.

Username: ylathouris

I am trying to understand why this might have happened. Can anyone help?

Hello Kevin
I saw your post on the proper way to prevent Supply Chain attacks on PyPI.You mentioned " your company’s systems block packages from PyPI which have the same (or even similar, as in typosquat) names as your internal packages". Is there a way to natively implement this with PIP only? From what I have read, it seems there is quite a few other things that would have to be done to achieve the blocking results you talk about. This seems like quite a bit more work for less results. I realize the namespace is flat and only so many combinations exist, but can you blame someone that wants to be sure to stop the attack with minimal effort?

1 Like

I’m not aware of any way to do that with pip; it would need to know what the names of your internal packages are in order to do the comparisons, but it doesn’t have any mechanisms which can be used that way. The most straightforward way to do this is to have some sort of centralized system (which could be just a proxy with some scripting, or a full-blown caching package repository) where that data can be stored and compared, and then configure pip to use it instead of pypi.org directly.

2 Likes

See GitHub - uranusjr/simpleindex for an implementation of the middleman proxying solution, along the lines of what @kpfleming mentions above.

3 Likes

Thanks for the response Kevin. I am looking into a centralized proxy at the moment to try and follow the best practice. It just seems like a lot of work compared to registering a few internal package names on PyPI to make sure someone else doesn’t register those names (maliciously). I want to do the right thing here, and I realize publishing packages to a flat namespace with little functionality (letting a dev know that they have the wrong config) isn’t great for the PyPI community. I truly hope that PyPI will soon support namespaces and give another avenue here. :smile:

1 Like

By Davidsyckle via Discussions on Python.org at 08Jun2022 12:41:

Thanks for the response Kevin. I am looking into a centralized proxy at
the moment to try and follow the best practice. It just seems like a
lot of work compared to registering a few internal package names on
PyPI to make sure someone else doesn’t register those names
(maliciously). I want to do the right thing here, and I realize
publishing packages to a flat namespace with little functionality
(letting a dev know that they have the wrong config) isn’t great for
the PyPI community. I truly hope that PyPI will soon support namespaces
and give another avenue here. :smile:

Has it not occurred to the OP to just put all their internal packages
inside a distinctive private prefix, like
internal.initials-of-company.packagename?

It doesn’t prevent use of these names in PyPI, but it does make it very
unlikely that there will be accidents, and also makes it obvious which
packages are internal private (and will never be published for others to
reuse) once and therefore which packages are likely from a public
location?

It just seems both simpler and less polluting of the public (visible to
the world) namespace.

Cheers,
Cameron Simpson cs@cskk.id.au