Hello! This seems extremely timely with the conversation around typosquatting. A security research friend and myself are worried about the security risks in the mcp-{noun} package space, and decided to something about it.
I don’t need to be the person responsible for this forever, I’m open to institutional answers here, I’m just trying to mitigate before attackers catch wise.
You should instead reach out to admin@pypi.org and get these names prohibited. Doing it your way is extra work for you, not to mention that you’re breaking PyPI’s terms of servicePEP 541.
Have you thought about making dep quality tool, in the line of code quality tools like Ruff that just scans whatever deps the agent needs? A simple allow list (or set) and block list, with overrides for user auditted packages, will be fast, even if it calls out on a cache miss, and would probably prevent 99% of typo-attacks.
With slop squatting prefixes, you now having to gatekeep the entire mcp-* namespace, and access to any name within it for legitimate projects, needs to be manually granted by yourself. Or by anyone willing to help you, that you deem trustworthy. So as this whole thing was motivated by “what if” theoretical security risks that haven’t happened yet, you’re still open to social engineering.
Right now, there are large companies spending millions of dollars convincing people of far less technical skill than the average user of this forum to implement behaviors that we, here, know has huge potential for harm. The point of what we’re trying to do is practice empathetic defense in depth for a new wave of users who are very possibly bumping up against PyPI for the first time, protecting and hopefully educating simultaneously.
One of the things I have loved about the Python community is our desire to be welcoming to newcomers, whatever their background, and to constantly improve the defaults and processes to make Python a place where people can be safe and grow.
Seth and Mike and the rest of the security team have done incredible work improving the security posture and primitives of the Python packaging ecosystem. We’re trying to extend that spirit to this new avenue for Python usage.
That’s all well and good. Very inspiring even. But the same risks are there outside the mcp-* namespace you’ve unilaterally mostly squatted en masse.
The responsible way to welcome new Python users is by getting the basics right, e.g. saying to them “Look, don’t run random untrusted code from the internet on your local machine. Despite the best efforts of the security team, do not assume PyPi is safe”.
You’re enabling such new users’ bad habits, and doing them a disservice.