This is a known problem for a while. For example when we (RhodeCode) had an installer based on pip we actually rolled our own PYPI index. Having one you host is very easy and there are nice projects in existence that allowed that. It basically solved a problem of deployment when pypi wasn't available, speed up our test installer builds, and also total control over the packages we ship.
Malicious software libraries found in PyPI posing as well known libraries
251–254 of 254 posts
Re: Malicious software libraries found in PyPI posing as well known libraries
#252Earlier quoted context omitted.
>both the pypi devs and the python security team decided to ignore it. Without trying to downplay the seriousness, I think that's a less-than-charitable take on the bind they felt they were in. It also sounds like there's a crack team of dedicated devs sitting around waiting for something to work on.
When I read things like, https://caremad.io/posts/2013/07/packaging-signing-not-holy-... I get the impression they don't care about security at all. They seem like children plugging their ears and shouting "nah nah nah" while putting repo users at risk. They've obviously done nothing since that post was made four years ago. In contrast, Maven central requires signing. Unsurprisingly, Maven central doesn't have typosq…
> https://caremad.io/posts/2013/07/packaging-signing-not-holy-...
Thanks, that's actually a great article that explains very well why you can't just throw signatures at the problem and claim that fixes everything.
As other commenters have pointed out, the reason Maven central doesn't have this problem has nothing to do with signatures, and everything to do with the fact that all new packages must undergo manual review, which is unfortunately a solution that doesn't scale. (See the "Linux Has Packaging Signing, Let’s Steal Theirs" section from the article you linked.)
Re: Malicious software libraries found in PyPI posing as well known libraries
#253Earlier quoted context omitted.
I have found the PyPI group of people to be very helpful in these cases. You also should probably, as an organization, have more than one owner of your packages. That way, unless two people leave, things aren't orphaned. We have gone as far to have a 'meta-user' that is on all packages. It is only ever used to recover a fully abandoned package.
I understand you are trying to be helpful, and of course you are right, but the fact is that sometimes things fall between the cracks, especially in, say, hard-pressed startups. There are so many shoulds in the world that don't make it to dids , it reminds me of the joke about the salesman trying to sell farming improvement techniques and being turned down by the old farmer, who says, "Son, I don't farm half as good…
UPDATE: I was helped out by a very nice person from PyPI, so kudos to them.
Re: Malicious software libraries found in PyPI posing as well known libraries
#254tiny open source project for this. https://github.com/williamforbes/pypi_hacked_names