Is it a good counter-measure for this kind of a situation?
No. Unfortunately what you're planning to do won't address this specific threat. Here, the attackers compromised the package on PyPI itself, hence it was downloaded from the original source, so limiting downloads only to PyPI would have no effect.
In most cases, these compromised packages come in two flavours:
- Attackers gain control of a legitimate package and inject malicious code into it. e.g. NPM event-stream
- Attackers create a malicious package that looks similar to the legitimate package (jeIlyfish vs. jellyfish) -- the form uses the upper-case 'i' instead of 'l'.
It's hard to address this without some tooling, ultimately it's nice to be able to build everything yourself, but sooner or later you're going to need external packages -- and sometimes those external packages get compromised. Even without attackers, legitimate CVEs are found in commonly used package and require upgrades on your part to protect your application.
For this you need a tool, that scans your requirements.txt file and validates against a list of known vulnerable packages (either through this type of compromise or something else). Of course this is more post-build rather than pre-build, but you can incorporate into your build pipeline if required (validate requirements.txt before building).
If you publish your code on Github, it automatically is scanned by Github against known vulnerable packages and warns you via email and on the repo homepage. There are other tools like pyup, synk, etc that do exactly the same thing.
