51–60 of 86 posts
Are other languages/runtimes also that risky as Node with npm? npm packages seem like a cardhouse. I know that the node_modules folder is often times criticized for its sheer amount of 3rd party libraries. Is it because of JavaScripts "missing" standard library?
Reminder that people should seriously consider disabling the install-scripts. Personal system-wide config: npm/yarn config set ignore-scripts true -g and add & commit a .npmrc/.yarnrc file with ignore-scripts true Yes, this will cause headaches in some (increasingly rare) cases where some package actually needs those scripts. You can fix this with custom install scripts that take care of running install for those spe…
I think NPM should consider flipping the default on this. Code that requires an install script should be the odd case that draws scrutiny.
Would this mean any project using a package.lock/yarn.lock was 'safe' going through deploys? So only new installs and builds without lock files could have grabbed the higher version?
If so, I wonder if it's hard or impossible to swap a release version on NPM. Seems like that would hit a much wider audience before being detected.
Are other languages/runtimes also that risky as Node with npm? npm packages seem like a cardhouse. I know that the node_modules folder is often times criticized for its sheer amount of 3rd party libraries. Is it because of JavaScripts "missing" standard library?
The amount of churn in JS ecosystem, security incidents like this and general crappiness of websites can be generally explained by how immature these hipsters are.
Why can’t there just be multiple curated repositories like how Linux distros do it? Having NPM just be a free-for-all is a ticking time bomb. It is only a matter of time before an event like this results in something very serious.
NpmJS echo system is cancer.
Earlier quoted context omitted.
-name "*coa*" is a bit too eager. It will flag other packages too, like the fairly popular babel-plugin-nullish-coalescing
If you have an index for the locate command it's probably easier to do: locate "/coa/package.json" | xargs -I {} jq .version {} 2>/dev/null
Are other languages/runtimes also that risky as Node with npm? npm packages seem like a cardhouse. I know that the node_modules folder is often times criticized for its sheer amount of 3rd party libraries. Is it because of JavaScripts "missing" standard library?
I will be downvoted to hell for saying this. But javascript ecosystem is where most newbies come. (Low barrier to entry and it also seems hip). With no regards to security, maintainability or reliability, fashion chasing blog-happy hipsters. The amount of churn in JS ecosystem, security incidents like this and general crappiness of websites can be generally explained by how immature these hipsters are.
Perhaps because dependencies are more curated in PHP due to clusters of dominant frameworks, rather than a proliferation of smaller libraries.
It seems that all of these should be cryptographically signed by a developer's private key before publication and then verified by others before use. Is that not the case?
What a worthless advisory, how about sharing who could possibly be affected at the very top, or at least anywhere? Going to the issue, it seems the `preinstall` field was changed to `start /B node compile.js & node compile.js",` which means this would only run on Windows machines, everyone else seems to be unaffected. Here is how you can find out if you have the affected package on your machine/instance: find ~/proje…
gci -r -dir | where name -eq coa | % { gc $_/package.json -EA si | ConvertFrom-Json | select version }(Of course this malware was in a preinstall script, which should also be disabled... but any module you import in a node app can do bad things when you run your app, preinstall script or no.)