421–430 of 796 posts
Earlier quoted context omitted.
Which of these would you prefer to reimplement? Debug, chalk, ansi-styles? --- You can pretend like this is unique to JS ecosystem, but xz was compromised for 3 years.
It's telling that we keep remembering xz to this day, while npm has these incidents on what feels like every single week.
Earlier quoted context omitted.
in general npm does a not-too-great job with these things
Remember, NPM stands for Now Part of Microsoft! (Microsoft owns GitHub, which owns NPM.)
Earlier quoted context omitted.
Asking people to run random install scripts just feels very out of place given the context.
I would agree if this were one of those `curl | sh` scenarios, but don't we consider things like `brew` to be sufficiently low-risk, akin to `apt`, `dnf`, and the like?
I'm a little confused after reading everything. I have an Expo app and if I run `npm audit`, I get the notification about `simple-swizzle`. The GitHub page ( https://github.com/advisories/GHSA-hfm8-9jrf-7g9w ) says to treat the computer as compromised. What does this mean? Do I have to do a full reset to be sure? Should I avoid running the app until the version is updated?
>Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.
It sounds like the package then somehow executes and invites other software onto the machine. If something else has executed then anything the executing user has access to is now compromised.
As an outsider to the npm ecosystem, reading this list of packages is astonishing. Why do js people import someone else's npm module for every little trivial thing?
I can provide you with some missing background as I was a prior full time JavaScript/TypeScript developer for 15 years. Most people writing JavaScript code for employment cannot really program. It is not a result of intellectual impairment, but appears to be more a training and cultural deficit in the work force. The result is extreme anxiety at the mere idea of writing original code, even when trivial in size and sc…
After an npm incident in 2020 I wrote up my thoughts. I argue that this anxiety is actually somewhat unique to JS which is why we don't see a similar culture in other languages ecosystems
https://crabmusket.net/java-scripts-ecosystem-is-uniquely-pa...
Basically, the sources of paranoia in the ecosystem are
1. Weak dynamic typing
2. Runtime (browser engineers) diversity and compatibility issues
3. Bundle size (the "physics" of code on a website)
In combination these three things have made JS's ecosystem really psychologically reliant on other people's code.
Is the npm package ecosystem fixable at this point? It seems to be flawed by design. Is there a way to not accept any package version less than X months old? It's not ideal because malicious changes may still have gone undetected in that time span. Time to deploy AI to automatically inspect packages for suspect changes.
Hi, yep I got pwned. Sorry everyone, very embarrassing. More info: - https://github.com/chalk/chalk/issues/656 - https://github.com/debug-js/debug/issues/1005#issuecomment-3... Affected packages (at least the ones I know of): - ansi-styles@6.2.2 - debug@4.4.2 (appears to have been yanked as of 8 Sep 18:09 CEST) - chalk@5.6.1 - supports-color@10.2.1 - strip-ansi@7.1.1 - ansi-regex@6.2.1 - wrap-ansi@9.0.1 - color-conve…
Hey, no problem, man. You do a lot for the community, and it's not all your fault. We learn from our mistakes. I was thinking of having a public fake profile to avoid this type of attack, but I'm not sure how it would work on the git tracking capabilities. Probably keeo it only internally for you&NPM ( the real one ) and have some fake ones open for public but not sure, just an obfuscated idea. Thanks for taking the…
>> which silently intercepts crypto and web3 activity in the browser, manipulates wallet interactions, and rewrites payment destinations so that funds and approvals are redirected to attacker-controlled accounts without any obvious signs to the user. If you're doing financial transactions using a big pile of NPM dependencies, you should IMHO be financially liable for this kind of thing when your users get scammed.
using NPM at all must be treated as a liability at this point. it's not the first and definitely not the last time NPM got pwned this hard.
Luckily some of them actually import the packages to a local distribution point and check them first.
It wouldn't be a perfect solution, but I wonder why browsers don't indicate the registration date for a domain in the URL bar somehow? I bet junon would have seen that and gotten suspicious.