Security issue: React is vulnerable to supply chain attacks about react

[markerikson]

I have mixed feelings about this:

• It seems like a pretty big stretch to claim that React is "vulnerable to supply chain attacks" because of the existence of one particular dependency. Why wouldn't that be the case for every dependency on NPM ever? That's an awfully hypothetical situation.
• Agreed that the fact that the package hasn't been updated for a number of years is in one sense something to think about, but it's also a tooling-related package that has no reason to change at all anyway
• That said, we dropped loose-envify from Redux a while back, per reduxjs/redux#3567 (although we are just now getting ready to release that in a new major version). It was designed for Browserify users to help that tool do search-and-replace on process.env.NODE_ENV when used to build an app that used a given library like React. Browserify is rarely used today, and that should really be an app-level configuration concern. (Related, see #9641 where this was added to some of the addon packages)

So, I disagree with the security reasoning, but I agree that React shouldn't list loose-envify as a dependency because it's not useful any more.

[phryneas]

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.

[eps1lon]

Closed in #28480

[paulmillr]

Why wouldn't that be the case for every dependency on NPM ever

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.

[markerikson]

@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 loose-envify as a dep entirely, but for non-security related reasons. I just don't understand the urgency for filing a security-claim issue about one random dep.

[rickhanlonii]

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?

[markerikson]

@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:

• User installs react, which drags along loose-envify as a dep so it's available
• Browserify tries to build the app
• Browserify looks at react's package.json, sees the transforms section, pulls in loose-envify, and automatically uses that as part of its transformation process

So, moving it to a dev dep breaks that, because installing react wouldn't automatically install loose-envify too.

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.)

[paulmillr]

@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.

[paulmillr]

@phryneas

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.

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.

[oliviertassinari]

Removing loose-envify makes a lot sense to me:

• Browserify downward trend: https://npm-stat.com/charts.html?package=browserify&from=2022-02-24&to=2024-02-24.

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.

• Slow down a bit the installation process of React https://packagephobia.com/result?p=loose-envify

• Could look cleaner: https://npm.anvaka.com/#/view/2d/react

• react-is would need to have the dependency to make https://unpkg.com/browse/[email protected]/index.js work

[markerikson]

@oliviertassinari not sure what you mean with the "react-is would need this" comment. That's the exact same dev-vs-prod import idiom that react and react-dom already use:

• https://unpkg.com/browse/[email protected]/index.js

and bundlers already handle NODE_ENV as an idiom indicating dev vs prod.

[oliviertassinari]

@markerikson I would expect react-is to reproduce the loose-envify setup than react has:

  "browserify": {
    "transform": [
      "loose-envify"
    ]
  }

Otherwise, the benefit is limited to have it in react in the first place.