If you want your package added it's as simple as sending an email to http://www.lvbagsgb.com
Malicious software libraries found in PyPI posing as well known libraries
81–90 of 254 posts
Re: Malicious software libraries found in PyPI posing as well known libraries
#82Yet another attack vector that doesn't exist at all in Linux distributions but invented by language package managers, sadly. They solved the issue 2 decades ago by heavily vetting packages before accepting them into repositories. Users are allowed to add and use packages from 3rd party repositories. Maybe solution to this is creating curated repositories based on publicly open ones and using them by default (and requ…
Sure its nice (and easier) to use the distro's package management system, but it often just isn't up to date enough. You end up using thing that are a while out of date and may have security flaws as a result.
This is incorrect of rolling release distros. Even Ubuntu is fairly quick to update, which is not a rolling release. CentOS on the other hand can be like pulling teeth. I'm going to be glad to stop dealing with CentOS 6.
Re: Malicious software libraries found in PyPI posing as well known libraries
#83some of this could be helped by intelligent naming of packages. If something is called urllib, name the package urllib because that's what people are going to look for.
Re: Malicious software libraries found in PyPI posing as well known libraries
#84Ok, here's some ugly backstory on this:
This problem has been known for a while, yet both the pypi devs and the python security team decided to ignore it.
Last year someone wrote his thesis describing python typosquatting and standard library name squatting: http://incolumitas.com/2016/06/08/typosquatting-package-mana...
However after that the packages used in this thesis - the most successful one being urllib2 - weren't blocked, they were deleted. Benjamin Bach was able to register urllib2 afterwards. Benjamin and I decided that we'd now try to register as many stdlib names as possible.
See also: https://www.pytosquatting.org/
Re: Malicious software libraries found in PyPI posing as well known libraries
#85Yet another attack vector that doesn't exist at all in Linux distributions but invented by language package managers, sadly. They solved the issue 2 decades ago by heavily vetting packages before accepting them into repositories. Users are allowed to add and use packages from 3rd party repositories. Maybe solution to this is creating curated repositories based on publicly open ones and using them by default (and requ…
> Yet another attack vector that doesn't exist at all in Linux distributions but invented by language package managers, sadly. Language package managers solve the problem that we don't have neither an universal package format that works across all programming language requirements and all sort of OSes, nor the time to create an OS specific package for all sort of OSes.
Solving that problem is orthogonal to vetting repositories.
There is nothing wrong with inventing their own solution if they're solving other problems, what is wrong is not learning from previous examples and fucking up creating problems that have been already solved in the process.
Re: Malicious software libraries found in PyPI posing as well known libraries
#86Earlier quoted context omitted.
Package managers are providing (in the most case) a free service, so it's hard to see a strong case for them providing more services here. The problem is one of scale. npm has over 500,000 packages, so no manual review will address their scale over the whole repository. Until the developer market shows that they'll pay for a more secure service (e.g. package signed, reviews done etc) I doubt much will change.
Five hundred thousand packages, am I reading it right? I dont believe top ten OS package managers combined would reach that number. Either this is a typo or it's crazy.
JS devs usually make packages that have single functions....
Re: Malicious software libraries found in PyPI posing as well known libraries
#87Earlier quoted context omitted.
I believe urllib3 is built-in. So if you have installed it from PyPI you've gotten a malicious version.
urllib and urllib2 are built-in for Python 2, and were merged and reorganized as just urllib in Python 3. urllib3 is a third-party module.
This is correct. In general, though, most packages don't rely on urllib3 directly, but on `requests`, which uses urllib3 but provides a friendlier API and built-in SSL cert verification.
Re: Malicious software libraries found in PyPI posing as well known libraries
#88Whoa urlib & urllib3. Those are pretty popular packages, especially to newbies. Hundreds of websites that teach web-scraping use those libraries. Wonder what is an effective form of protection against such attack vectors? Do digitally signed certificates fit into this usage scenario??
> Do digitally signed certificates fit into this usage scenario?? No, because either the package author would have to sign them, in which case you have to choose to trust each package author, or the repository would sign them, in which case there would be no improvement for this current issue, since the repo would sign the fake packages as well.
Any way in which blockchain technology can be used? Like, the transaction becomes the act of the author uploading the code and the repo and user verify the transaction in some form?
Re: Malicious software libraries found in PyPI posing as well known libraries
#89I'm glad Go completely sidestepped the name-rush induced by this type of package managers (composer, cpan, rvm, pypi, npm…). Just provide an URL. Done.
Re: Malicious software libraries found in PyPI posing as well known libraries
#90This seems to be getting more of a threat. Can't see how you prevent this sort of malicious spoofing without explicitly curating the list.
Personally, I prefer the uncurated, caveat emptor approach, but this could do witha third party stepping up. (moz seems keen to do anything to get us to like them)
Ultimately, sounds like something that could be solved with a blockchain of legitimisation. (ran by moz)
;)