-
-
Notifications
You must be signed in to change notification settings - Fork 26.8k
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
Report High severity vulnerability in react-scripts 3.4.3 dependencies #9842
Report High severity vulnerability in react-scripts 3.4.3 dependencies #9842
Comments
Thanks for the report. The issue should be filed against facebook/create-react-app. facebook/react is concerned with packages listed in https://github.com/facebook/react/tree/HEAD/packages |
Note there is no actual vulnerability here for Create React App users. This is a false positive. |
Shouldn't the fix be to update the dependency |
@gaearon While a false positive for create react app users, there is not always a means to flag it as such in various security tooling. Sometimes security scans are done by an entirely different team. The reality is devs are going to be required to do something about this vuln. I don't know about others, but I would very much appreciate frequent patch releases for create-react-app. |
As explained in the other issue, we can’t just easily cut patches for something that’s resolved upstream with a major version. Ideally what should happen is that the “vulnerable” project itself cuts a patch. Then everyone gets it automatically. It’s not sustainable for the projects deep in the tree to only fix these problems with major versions, putting the pressure on the projects above in the stack — which are neither truly affected nor have the means to do the update safely (because it is transitive). |
In other words. Say we have What should happen instead is that you should go to the Now, of course, if the vulnerability is real, it deserves our energy to go to the |
Yeah I understand that those situations are not ideal and difficult to deal with, but I don't know if that's the case for this one. Doesn't bumping In this situation, the I completely empathize with the difficulty of keeping up with all the transitive dependency updates in node.js project and not introducing breaking changes because maintainers don't update old versions. I'm kind of exhausted by it myself. Do realize though that telling users of create-react-app its their problem to get a 4-levels-deep dependency updated isn't going to be ideal either. At some point the effort required to work around the resistance to keep react-scripts updated will be larger than forking react-scripts, ejecting, or moving off to some other solution. |
I haven’t looked at that yet. My question is — is the patch to it really necessary? Why can’t it be solved at the lower |
In other words the patch should always be done at the deepest level possible. Then as long as the next layer above it is permissive (accepts patch differences) there is no extra churn for everyone above. So patching |
Ideally, yes the fix would be deep in the tree. Realistically though, the immediate dependency is something the create-react-app project has control over. If there's a patch update to a library react-scripts directly depends on, why hesitate to pull it in? |
Each release is an extra fixed amount of work and each patch risks breakages. I’m not strongly opposed to cutting another one but this sets a bad precedent because each next time we’re going to refer to a previous decision (“we cut a patch that time, why not this time?”). Since the tree is very deep this centralization is unsustainable. And I want to bring attention one more time that we’re talking about false positives rather than real issues. We are literally wasting each other’s time because we don’t have a strong ecosystem convention about how to correctly resolve this issue, and because tools like Snyk mislead users about their severity. |
Have you tried moving |
Seems like that only helps with Snyk but not with |
OK, it looks like |
That said, I think we also need to introduce an explicit policy going forward that we're not going to take patches for false positives until all the means upstream have been exhausted. |
Thanks Dan! I know node dependency management is never ending and frustrating, and I really appreciate it! |
In Berlin, we can find painted berlin wall with paintings by spray-dose gang or some kinda offical place like the "east side gallery". The prev one are normally much much more creative & vivid then those officals'. Thing around node are those spray-dose gangs'. |
@gaearon good point. I've updated #9841 to unpin the dependency, so the PR now is 2 characters big 😄 Beside from that I've created a PR at bholloway/adjust-sourcemap-loader#18 which does nothing beside updating the |
I bumped just |
After auditing my app a high vulnerability is detected in the package
object-path
dependency ofreact-scripts
.I tried to run an audit fix however I still got the issue
1 vulnerability requires manual review. See the full report for details.
.I tried to fix it manually but
react-scripts
is forcing the use ofversion 0.11.4
and I need to update it toversion 0.11.5
to fix the vulnerability.React version:
![image](https://user-images.githubusercontent.com/52570855/96562576-999f1c00-12c9-11eb-8287-58ec04ff44f1.png)
npm version: 6.14.8
current version of react-scripts: 3.4.3
The text was updated successfully, but these errors were encountered: