New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security issue: React is vulnerable to supply chain attacks #27748
Comments
I have mixed feelings about this:
So, I disagree with the security reasoning, but I agree that React shouldn't list |
It is the case. That’s why there supply chain attacks are so effective in js: of popularity of version ranges and the fact ppl blindly update their dependencies to every new version. Consider a simple scenario: the persons npm token is leaked by virus and 1.1.1 is published; with the ability to steal other peoples npm tokens. Would a simple locking to 1.1.0 mitigate this? Sure. There are other ways to make packages resilient. For example, with ethereum-cryptography package, the dependency state is locked down, there have been an audit. Every time a dependency bump is done, it is reviewed by at least one other person, we check version diff, etc. It is not possible for packages such as typescript, but there are few of these. Moreover, the recent rewrite, reduced the amount of authors who can publish a sub-dependency update from 33 to just 1. |
@paulmillr : yeah, I follow that. My question is more about why it's worth singling out one dep here in this repo specifically. What makes this situation special? again, to be clear, I do support removing |
Also, since npm has started to require two-factor auth for publishing popular packages, a token stolen by a virus does not pose a significant threat of a supply-chain attack. |
Has anyone looked into how it's actually used? I believe we only have it to support browserify, so if you don't run browserify, the code in the package isn't executed, right? Should it be moved to a dev dependency anyway? |
@rickhanlonii : yeah, it's purely a Browserify thing. If you intend it to be used, it has to be listed as a dependency as far as I know. I think the intended usage sequence is:
So, moving it to a dev dep breaks that, because installing My take is that this is not React's job at this point. It's up to the user to configure their own build tool properly. (And doubly so given that Browserify is a relatively legacy build tool today.) |
@markerikson a person in other repo randomly told me “even react does this”, then i’ve did the researched and while it seemed like the dep is not really up-to-date, or “not devdep”, i’ve opened the issue. |
I don’t believe this mitigates the risk. They just enforced 2fa for auth. Not for publish — otherwise CI publish tokens would have stopped working. I have published popular packages through CI recently, all is fine. Tokens can still be stolen. |
Removing
It's at about 5% of the downloads of React today. When this dependency was introduced in 2016 ecf824c, it was a much different landscape: https://npm-stat.com/charts.html?package=browserify&package=react&from=2015-02-24&to=2017-02-24, Browserify had more downloads than React.
|
@oliviertassinari not sure what you mean with the " and bundlers already handle |
@markerikson I would expect "browserify": {
"transform": [
"loose-envify"
]
} Otherwise, the benefit is limited to have it in react in the first place. |
Closed in #28480 |
react
depends on"loose-envify": "^1.1.0"
, a package which owned by one person. Last update of it was 5 years ago.If the persons NPM credentials or token are leaked, and a new malwared version of loose-envify is published, all react users will instantly receive malware.
Moreover, same can happen to envify's dependency:
js-tokens
.Ways to mitigate:
1.1.0
The text was updated successfully, but these errors were encountered: