It's important to understand that this issue was specifically caused by a deficiency in Python's packaging system: dependencies are specified by name and version, and if the user configures multiple package repositories, there's no way to control which repository they get the package from. So if a package is normally only available on PyTorch's nightly package index, someone can upload the same package name and version on PyPI and it will take precedence.
It would be better if packages could specify a cryptographic hashes of the packages they depend on and/or specify the package repo that a package should come from. There is some prior art for this in e.g. the Javascript and Rust ecosystems.
This problem did not occur simply because pytorch has many dependencies and one of them got compromised. If pip allowed you to specify dependencies in a more secure way, this would not have happened.
It would be better if packages could specify a cryptographic hashes of the packages they depend on and/or specify the package repo that a package should come from. There is some prior art for this in e.g. the Javascript and Rust ecosystems.
This problem did not occur simply because pytorch has many dependencies and one of them got compromised. If pip allowed you to specify dependencies in a more secure way, this would not have happened.