Earlier this year, I wrote briefly about new functionality added to PyPI, the ability to quarantine projects. This feature allows PyPI administrators to mark a project as potentially harmful, and prevent it from being easily installed by users to prevent further harm.
PyPI has concepts of Projects, Releases, and Files1. These are all discrete data models2, and behave slightly differently based on their characteristics. A Project may have 0 or more Releases, a Release may have 1 or more Files.
Researchers will often report a given Project as malware, and will link to a specific location in a File for a given Release, per the PyPI Security process.
PyPI will receive malware reports3 that are often relevant to an entire Project. Simply put: a Project, along with all of its Releases (usually 1) and Files (usually 1-2) are all part of a similar campaign, and should be removed from PyPI to protect end users. This is not universally true, as malware has been added to established, mature Projects via a new Release after some sort of account access takeover, so there may be a need to consider reporting malware for a given Release/File - something not yet fully implemented via Observations or the beta Malware API.
When reviewing and acting on malware reports, PyPI Admins had one main tool at their disposal: complete removal of the Project from the PyPI database. This is often coupled with prohibiting the Project name from being reused. PyPI has functionality irrespective of malware to prevent File name reuse.