After all these incidents, I still can't understand why package registries don't require cryptographic signatures on every package. It introduces a bit more friction (developers downloading CI artifacts and manually signing and uploading them), but it prevents most security incidents. Of course, this can fail if it's automated by some CI/CD system, as those are apparently easily compromised.
NPM debug and chalk packages compromised
601–610 of 796 posts
Re: NPM debug and chalk packages compromised
#602Earlier quoted context omitted.
> sometimes the password manager does not auto-fill So pick one that does? That's like its top 2 feature > he does use one He doesn't since he has no autofill installed, so loses the key security+ convenience benefit of automatch
> So pick one that does? That's like its top 2 feature Still doesn’t work 100% of the time, because half of the companies on earth demote their developer time to breaking 1995-level forms. That’s why every popular password manager has a way to fill passwords for other domains, why people learn to use that feature, and why phishers have learned to convince people to use that feature. WebAuthn prevents phishing. Passwo…
Given recent vuln of password manager extensions on desktop leaking passwords to malicious sites, I have disabled autofill on desktop... And autofill didn't work for me on ycombinator on mobile... Autofill is too unreliable.
Re: NPM debug and chalk packages compromised
#603Earlier quoted context omitted.
The browsers mostly did away with EV certs[1], against sustained pushback from CAs, because of research invariably showing that the feeling of security is mostly unfounded. (Both because users are garbage at reading security indicators—and unscrupulous companies are eager to take advantage of that, see Cloudflare’s “security of your connection”—and because the legal-name namespace is much more Byzantine and locale-de…
> That said, it remains a perpetual struggle to get people to understand the difference between being connected to the legitimate operator of satan.example That's because the browser implementers gave up on trying to solve the identity problem. It's too difficult they said, we'd rather push other things. Google implemented certificate pinning in Chrome for themselves and a few friends, said fuck everyone else, and de…
How would you propose that it should work?
Re: NPM debug and chalk packages compromised
#604Earlier quoted context omitted.
Wouldn't they have been able to change your key if they had compromised your entire npm account? Also, junon.support++ – big thanks for being clear about all this.
Push to many repos with a brand new key would (should) trigger red flags.
Good point. But how should the red flag materialize?
Re: NPM debug and chalk packages compromised
#605I'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?
I mean the statement is pretty clear >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 s…
Confusing as hell. From code analysis shared malicious code replaces ethereum and other crypto wallet addresses in browser context. You can install malicious package, run it, run it in browser context (ie. in your playwright tests), then update package to not compromised version and you're fine - your system is clean.
This incident would be much more severe if the code would actually steal envs etc. because a lot of packages have dependency on debug as wildcard.
Re: NPM debug and chalk packages compromised
#606Earlier quoted context omitted.
I'm curious :) Does the AI detect the obfuscation?
It's actually pretty easy to detect that something is obfuscated, but it's harder to prove that the obfuscated code is actually harmful. This is why we still have a team of humans review flagged packages before we try to get them taken down, otherwise you would end up with way too many false positives.
Yeah, what I meant is that obfuscation is a strong sign that something needs to be flagged for review. Sadly, there's only a thin line between obfuscation and minification, so I was wondering how many false positives you get.
Thanks for the links in your other comment, I'll take a look!
Re: NPM debug and chalk packages compromised
#607Earlier quoted context omitted.
I blame the prevalence of package mangers in the first place. Never liked em, just for this reason. Things were fine before they became mainstream. Another annoying reason is package files that are set to grab the latest version, randomly breaking your environment. This isn't just npm of course, I hate them all equally.
I'm a little confused, is this rage bait or what? > Things were fine before they became mainstream As in, things were fine before we had commonplace tooling to fetch third party software? > package files that are set to grab the latest version The three primary Node.js package managers all create a lockfile by default.
I mostly share GP's sentiment, although they didn't argue their point very well.
> As in, things were fine before we had commonplace tooling to fetch third party software?
Yes. The languages without a dominant package manager (basically C and C++) are the only ones that have self-contained libraries, that you can just drag into your source tree.
This is how you write good libraries - as can be seen by the fact that for many problems, there's a powerful C (or C++, but usually C) library with minimal (and usually optional) dependencies, that is the de-facto standard, and has bindings for most other languages. Think SDL, ffmpeg, libcurl, zlib, libpng/jpeg, FreeType, OpenSSL, etc, etc.
That's not the case for libraries written in JS, Python, or even other compiled languages like Go and Rust - libraries written in those languages come with a dependency tree, and are never ported to other languages.
Re: NPM debug and chalk packages compromised
#608Earlier quoted context omitted.
But also respects .gitignore by default so I’m not sure you want to use ripgrep to scan your node_modules
For others who didn't know, the -u flag in the OP's command makes it so ripgrep _will_ search files even if they're gitignored
-u searches through ignored files
-uu searches through ignored and hidden files (eg dotfiles)
-uuu searches through ignored, hidden, and binary files (ie everything)
Re: NPM debug and chalk packages compromised
#609Yeah I know "everyone can be pwned" etc. but at this point if you are not using a password manager and still entering passwords on random websites whose domains don't match the official one then you have no business doing anything of value on the internet.
And I guess you can just withdraw your funding from him any time.
Re: NPM debug and chalk packages compromised
#610Earlier quoted context omitted.
I'm a fan of post-facto confirmation. Allow CI/CD to do the upload automatically, and then have a web flow that confirms the release. Release doesn't go out unless the button is pressed. It removes _most_ of the release friction while still adding the "human has acknowledged the release" bit.
Maybe even send a user an email notification with a link...
lol granted! But notice how in that universe since npm has to send the link, then access to the link is coupled to access to the email address, serving as an auth factor.
In the attack described above, the attacker did not have access to the victim's email address.