Live data from Hacker News

Malicious software libraries found in PyPI posing as well known libraries

nbu.gov.sk

31–40 of 254 posts

Re: Malicious software libraries found in PyPI posing as well known libraries

#31
post #21

Earlier quoted context omitted.

More needs to be done by package managers to warn end users. One scenario that worries me is where apps age and use popular trusted dependancies (e.g. gems on Github). When those gems stop being maintained but need to be updated to work (say with latest OSX) - it's common to quickly look at the latest forks available and select the one that now works correctly - but without a detailed inspection of the new code it's…

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.

Maybe most of those 500,000 packages simply shouldn't be trusted.

There's a precedent for curated subsets of package ecosystems. Stackage for Haskell is an example, although it doesn't have security as the primary goal.

I don't think we should focus on actual audits of packages. Just checking that packages seem basically credible seems like a better approach because it's doable.

Re: Malicious software libraries found in PyPI posing as well known libraries

#33
post #21

Earlier quoted context omitted.

More needs to be done by package managers to warn end users. One scenario that worries me is where apps age and use popular trusted dependancies (e.g. gems on Github). When those gems stop being maintained but need to be updated to work (say with latest OSX) - it's common to quickly look at the latest forks available and select the one that now works correctly - but without a detailed inspection of the new code it's…

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.

Re: Malicious software libraries found in PyPI posing as well known libraries

#35
post #33

Earlier 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 is the most popular language on GitHub by far, and npm is a public site where anyone can instantly upload as many new packages as they want...

Re: Malicious software libraries found in PyPI posing as well known libraries

#36
post #33

Earlier 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.

Not a typo, http://www.modulecounts.com/ has the details. npm is adding 497/day at the moment.

Re: Malicious software libraries found in PyPI posing as well known libraries

#37

well shit, I guess I should have followed up on this after I noticed it 2 months ago. https://twitter.com/JustinAzoff/status/881163562739277824

Yup, same: https://gist.github.com/Spotlight0xff/829b7ebf32c4feec60ec44...

Re: Malicious software libraries found in PyPI posing as well known libraries

#38
post #31

Earlier 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.

Maybe most of those 500,000 packages simply shouldn't be trusted. There's a precedent for curated subsets of package ecosystems. Stackage for Haskell is an example, although it doesn't have security as the primary goal. I don't think we should focus on actual audits of packages. Just checking that packages seem basically credible seems like a better approach because it's doable.

Credibility is an easier check but still tricky. Many of the package are uploaded by anonymous or pseudonymous authors, so there's no easy way to even tie that to an IRL identity, let alone check for credibility.

I'd agree that a curated small package repository would be a better way to address the problem, but the market doesn't seem very interested in that as a solution.

Re: Malicious software libraries found in PyPI posing as well known libraries

#39
Part of my dislike for the Node ecosystem in particular and I am sure others have a similar problem, is the dependency trees are super complex.

Because packages tend to be small and many, and each of those has their own dependencies, you can end up with hundreds of packages installed which is simply impractical to manually review.

It is not node, but we do in fact manually review each package we utilize for our given language because it's feasible and worthwhile as the dependency tree is small in this ecosystem. Each and every package is a possible attack vector whether that be intentionally or just because it's poorly written and we can't simply ignore that because it's the done thing and "the community reviews them".

Post reply on HN