[dead]
NPM stylus package contained malicious code and was removed from the registry
21–30 of 45 posts
Re: NPM stylus package contained malicious code and was removed from the registry
#22I have to say NPM packaging is terrible. I probably spend 1 month of the year fiddling with upgrading packages due to security issues. That is just the amount of time I spend on my repos alone. All of this extra effort to avoid code signing and making package owners accountable.
It seems like every week there is a new security high sev ticket to fix some webpack dependency.
Not to mention that even if you do successfully run “npm audit fix” (—force), Npm may not update to the correct new version and will often downgrade packages many many many versions.
The error messages that Npm spits out have always frightened junior devs too.
I can’t wait for that whole ecosystem to be replaced.
Re: NPM stylus package contained malicious code and was removed from the registry
#23I have to say NPM packaging is terrible. I probably spend 1 month of the year fiddling with upgrading packages due to security issues. That is just the amount of time I spend on my repos alone. All of this extra effort to avoid code signing and making package owners accountable. It seems like every week there is a new security high sev ticket to fix some webpack dependency. Not to mention that even if you do successf…
The crazy thing is that `npm audit` doesn't even list `stylus` here, at least not in my repos. Despite them literally overtaking the damn package on the registry for a *security issue*.
Re: NPM stylus package contained malicious code and was removed from the registry
#24Earlier quoted context omitted.
That could track but people in the GitHub issue ( https://github.com/stylus/stylus/issues/2938#issuecomment-31... ) have found that no "other" version of Stylus has been released.
It may simply be Github and NPM going nuclear and just flagging everything just in case
Since the Github issue is turning into an unusable mess and I am currently experiencing emotions I don't have to unleash here...
There is an interesting comment by one of the older maintainers of stylus, Panya [1]. Taking this at face value, they claim to have published some malicious packages for research purposes about dependency confusion [2] (their link). This also fits with the comments of a few people claiming to be security researchers, [3] and [4], which at least say the same and point to three malicious packages published by Panya.
Based off of that, my own personal interpretation and simplest thesis is that Panya released some packages with questionable code. This triggered some security mechanism in npm and that system yanked packages they were a contributor of [5], because the account looked compromised or otherwise malicious. And then pipelines went red.
If this was an actual malicious act, or curiosity about security and security responses getting a fairly nuclear security response, I don't know. You need to apply your own security reasoning to this -- if you even want to trust this comment :)
I just wanted to collect the interesting comments in a place, because that ticket is getting impossible to navigate.
1: https://github.com/stylus/stylus/issues/2938#issuecomment-31...
2: https://medium.com/@alex.birsan/dependency-confusion-4a5d60f...
3: https://github.com/stylus/stylus/issues/2938#issuecomment-31...
4: https://github.com/stylus/stylus/issues/2938#issuecomment-31...
5: https://github.com/stylus/stylus/issues/2938#issuecomment-31...
5, also: https://github.com/stylus/stylus/issues/2938#issuecomment-31... (thanks to the sibling comment, I couldn't find that anymore)
Re: NPM stylus package contained malicious code and was removed from the registry
#25I have to say NPM packaging is terrible. I probably spend 1 month of the year fiddling with upgrading packages due to security issues. That is just the amount of time I spend on my repos alone. All of this extra effort to avoid code signing and making package owners accountable. It seems like every week there is a new security high sev ticket to fix some webpack dependency. Not to mention that even if you do successf…
The crazy thing is that `npm audit` doesn't even list `stylus` here, at least not in my repos. Despite them literally overtaking the damn package on the registry for a *security issue*.
It gets even better, Dependabot will spam you severities of it’s own that don’t appear in audit.
So you probably need to carefully audit the changes from two data sources and the security ticket ends up being 2+ merge requests.
Re: NPM stylus package contained malicious code and was removed from the registry
#26Man I thought I was going crazy. My staging build was failing and I saw that stylus was the culprit. Running `npm why stylus`, `npm ls --all stylus`, and other variants of these two commands consistently returned nothing, but I can see it in my lockfile if I run `grep -R stylus package-lock.json`. Even running `npm audit | grep stylus` returned nothing! Which I think is pretty crazy considering the package itself has…
[dead]
Re: NPM stylus package contained malicious code and was removed from the registry
#27I have to say NPM packaging is terrible. I probably spend 1 month of the year fiddling with upgrading packages due to security issues. That is just the amount of time I spend on my repos alone. All of this extra effort to avoid code signing and making package owners accountable. It seems like every week there is a new security high sev ticket to fix some webpack dependency. Not to mention that even if you do successf…
I have a question. I'm curious.
I see two comments here on this subject, complaining about the churn of dealing with security advisories. Sure, it's churn.
... but isn't this problem dwarfed by the implications of having used a compromised package? Presumably, if the project you work on has a compromised dependency, it means you've ran it on your development machine. Presumably, you might have a couple of secrets (private keys, AWS credentials and other whatnots) lying around, which might have leaked to a malicious actor.
Wouldn't you need to review all the development, staging and production machines for all your projects and rotate secrets everywhere?
Wouldn't it be, by far, the biggest churn involved, so much that mentioning "npm audit" difficulties not worth mentioning at all, because of the ridiculous comparison in effort magnitude?
Re: NPM stylus package contained malicious code and was removed from the registry
#28I have to say NPM packaging is terrible. I probably spend 1 month of the year fiddling with upgrading packages due to security issues. That is just the amount of time I spend on my repos alone. All of this extra effort to avoid code signing and making package owners accountable. It seems like every week there is a new security high sev ticket to fix some webpack dependency. Not to mention that even if you do successf…
I have a question. I'm curious. I see two comments here on this subject, complaining about the churn of dealing with security advisories. Sure, it's churn. ... but isn't this problem dwarfed by the implications of having used a compromised package? Presumably, if the project you work on has a compromised dependency, it means you've ran it on your development machine. Presumably, you might have a couple of secrets (pr…
No the biggest churn involved is now I’m another engineer that prefers to stay away from using, developing on, and recommending javascript platforms.
To your point I think you will find most companies stop at the upgrade high sev packages step and do not have any requirements or churn related to checking for fallout from sevs.
Re: NPM stylus package contained malicious code and was removed from the registry
#29My workaround: Add this on your package.json on the end of file bevor last }: }, "overrides": { "stylus": "0.0.1-security" }
It seems this doesn't work. The package is empty, it can't function. It makes the world stop, which is terrible!
Re: NPM stylus package contained malicious code and was removed from the registry
#30Earlier quoted context omitted.
I have a question. I'm curious. I see two comments here on this subject, complaining about the churn of dealing with security advisories. Sure, it's churn. ... but isn't this problem dwarfed by the implications of having used a compromised package? Presumably, if the project you work on has a compromised dependency, it means you've ran it on your development machine. Presumably, you might have a couple of secrets (pr…
No the biggest churn involved is now I’m another engineer that prefers to stay away from using, developing on, and recommending javascript platforms. To your point I think you will find most companies stop at the upgrade high sev packages step and do not have any requirements or churn related to checking for fallout from sevs.
That's what I suspect as well, but this means that we can assume that there's a giganormous amount of development machines being compromised around the world. If you're a gig worker, you might be exposing your other customers, including those with okay security practices.
It seems crazy to me that there's this ostrich culture about security. I'm guessing the vibecoding fashion doesn't help. Supply chain attacks can only grow exponential from there, flee for your lives.