They absolutely do. In this case litellm 1.82.8 had been out for at least a week (can’t recall the exact date offhand). The compromised version was a replacement.
It actually wasn't. That was one of the reasons why I looked into what was changed. Even 1.82.6 is only at an RC release on github since just before the incident.
So the fact that 1.82.7 and then 1.82.8 were released within an hour of each other was highly suspicious.
> PyPI does not allow for a filename to be reused, even once a project has been deleted and recreated...
> This ensures that a given distribution for a given release for a given project will always resolve to the same file, and cannot be surreptitiously changed one day by the projects maintainer or a malicious party (it can only be removed).
They absolutely do. In this case litellm 1.82.8 had been out for at least a week (can’t recall the exact date offhand). The compromised version was a replacement.
It actually wasn't. That was one of the reasons why I looked into what was changed. Even 1.82.6 is only at an RC release on github since just before the incident.
So the fact that 1.82.7 and then 1.82.8 were released within an hour of each other was highly suspicious.
Ah, my mistake! Thanks for the correction.
But I believe you can replace versions on both, nonetheless. It’s a multi step process, unpublish then publish again. But the net effect is the same.
If you lock your dependencies, it should fail if the hash doesn't match.
PyPI enforces immutable releases.
https://pypi.org/help/#file-name-reuse
> PyPI does not allow for a filename to be reused, even once a project has been deleted and recreated...
> This ensures that a given distribution for a given release for a given project will always resolve to the same file, and cannot be surreptitiously changed one day by the projects maintainer or a malicious party (it can only be removed).
1.82.7 and 1.82.8 were only up for about 3 hours before they were quarantined on PyPI.