Our company uses yarn 4 which has an option to prevent you from installing an npm package for the first number of days of its release. Most of these seem to be caught within that timeframe (1-3 days). https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...
If everybody starts to delay for 3 days, wouldn't it be the case that everyone would discover it on the 3rd day?
Malicious npm packages detected across Red Hat Cloud Services
241–250 of 494 posts
Re: Malicious npm packages detected across Red Hat Cloud Services
#242Earlier quoted context omitted.
Thank you for the thorough response. I got the following from yours and other responses: * The JS ecosystem has been and will most likely continue to be fast-moving, so it's quite a safe assumption that at no point will a quarantine period be wide-spread. * This quarantine period is for (semi-)automated scanners to catch the issue. Although considering the above there will always be a non-zero amount of end-user cana…
> Maybe NPM should run scanners before distributing malware? I suspect there's always a human checking these results. If NPM straight out rejects an update due to suspected malware, they might end up rejecting correct updates as well. If they grant some "safe" patterns a special pass, they might get exploited. So I think this only works if you have security scanners that are well-maintained and kept in secret. NPM fo…
Re: Malicious npm packages detected across Red Hat Cloud Services
#243Oh dear. Here we go again.
Re: Malicious npm packages detected across Red Hat Cloud Services
#244Re: Malicious npm packages detected across Red Hat Cloud Services
#245If this is what will take for folks to move away from JS ecosystem, I'll take it.
Re: Malicious npm packages detected across Red Hat Cloud Services
#246Earlier quoted context omitted.
> Furthering the idea that not all package managers are the same, there are entire cycles of the moon where I don't open nuget once. Some ecosystems simply don't need to vendor out very often, and these are the ones where you generally find the least news like this. This however is only to some degree the package manager's fault. The JavaScript culture is strongly ordering tiny packages by individual people doing sma…
> That small package mentality a trace to web usage: JavaScript code is often sent to the client, not having a huge library but having small dedicated libraries means that it is a lot simpler for the bundler to not bundle dead code which is sent to the browser client. Which is another part of this entire insanity: Browsers are already >. They're also built by > companies companies that collect > of analytics. You'd t…
The other issue is the sheer amount of tooling and “plugins” for those toolings. Like the babel and webpack situation, which is truly kafkaesque.
Re: Malicious npm packages detected across Red Hat Cloud Services
#247I came across this interesting rant the other day: https://github.com/uNetworking/uWebSockets.js/blob/master/mi... It does make sense that the right way would be to fork every dependency you use and install from your own repo reviewing and merging from upstream as needed. Would be a giant PITA though. :)
Re: Malicious npm packages detected across Red Hat Cloud Services
#248Earlier quoted context omitted.
The package might not ever be executed on the user's machine. Depending on your setup, it might only be ran on a server, where the data that can be exfiltrated is completely different.
Sure but like.. come on. Is that really a defense? Most packages are run on devs machines. And it's not like "Oh it's just running on my production server, what could go wrong there" is any better.
Re: Malicious npm packages detected across Red Hat Cloud Services
#249Why blame on NPM? Would you blame GitLab if an opensource maintainer was hacked and as a result the repo contains malicious changes? All of these recent incidents is just developers doing stupid things ... like using their compromised devices for making production changes, which is basically a big red flag to begin with. In fact, the entire situation has been exacerbated by coding agents because now practically every…
Days since last malicious packages in NPM: 0 (evergreen) Days since last malicious packages in PyPI: 30 Days since last malicious packages in Maven: 120 I'm sure this isn't 100% accurate, and there are probably better metrics (average number of malicious packages per year, average number of developers affected per year, etc) but they aren't as easy as a quick Google News search.
https://chatgpt.com/share/6a1da751-0d88-832e-ace7-572bc786e0...
Check the linked resource which has the actual data.
Re: Malicious npm packages detected across Red Hat Cloud Services
#250if RedHat is unable to secure their packages, what can we expect from mere mortals...
Is it really so hard for people to make releases manually?