Github告诉我,package-lock.json文件中的依赖项容易受到攻击并且已经过时。问题是,如果我做的npm install
还是npm update
,他们都没有更新程序包lock.json文件的依赖。
我对此进行了很多搜索,还删除了文件并完成了npm install
。
如果有人可以解决这个问题,我将不胜感激。有问题的软件包是Hoek,我的package.json文件中实际上没有该软件包。
提前谢谢了。
Github告诉我,package-lock.json文件中的依赖项容易受到攻击并且已经过时。问题是,如果我做的npm install
还是npm update
,他们都没有更新程序包lock.json文件的依赖。
我对此进行了很多搜索,还删除了文件并完成了npm install
。
如果有人可以解决这个问题,我将不胜感激。有问题的软件包是Hoek,我的package.json文件中实际上没有该软件包。
提前谢谢了。
Answers:
听起来Hoek是您的一个依赖项的依赖项(因此,您package.json中有一个包需要从它自己的package.json中获取它)。
您已经尝试删除/重新安装和更新项目依赖项而没有成功,因此似乎所涉及的软件包依赖项指定了显式或最大版本。
如果没有看到每个依赖项的package.json,就很难进一步建议如何强制进行更新。
编辑:
为了帮助您确定哪些软件包正在使用哪些依赖项,可以使用NPM的ls
命令:https : //docs.npmjs.com/cli/ls
例如,查看使用Hoek的软件包:
npm ls hoek
编辑2:
正如Ulysse BN正确指出的那样,如果您具有NPM版本6或更高版本,则可以npm audit fix
用来要求NPM尝试为您修复漏洞。
编辑3: 阅读此书的人还应该在下面查看JBallin的答案。它扩展了我在此处提供的信息,并且(我认为)是一种结构更合理的答案,可以更好地解决OP的问题。但是-如果您想快速解决-该答案就足够了。
package.json
具体取决于Growl的特定(脆弱)版本。您的答案是在正确的轨道上,如果您可以共享一条命令,该命令将显示哪个软件包package.json
依赖于中显示的易受攻击的软件包,那么您可能会确定答案package-lock.json
。
TLDR:使用来更新父包npm i $PARENT_PKG_NAME
。
注意
更新依赖项时,应查看CHANGELOG中是否有任何重大更改。
诊断
npm audit
将同时揭示易受攻击的软件包(请注意,您需要为此使用package-lock.json文件,因此您需要运行npm i
),以及它所依赖的软件包(如果适用)。请注意,您还可以npm ls $CHILD_PKG_NAME
用来查看其父项依赖项。
快速修复尝试
npm audit fix
并且npm audit fix --force
都值得一试,但有时修复将需要手动完成(见下文)。
手动修复
父程序包很可能已经修复了它们的依赖关系(您可以通过转到其GitHub并查看最近的提交进行验证,或者只是查看是否能解决此问题),因此您可以运行npm i $PARENT_PKG_NAME @$NEW_VERSION
并更新程序包锁.json。
如果父母尚未修复漏洞
如果维护者似乎没有响应,则可以考虑使用替代软件包来完成相同任务,或者分叉该软件包并自行更新漏洞。
验证修复
现在,您可以通过运行npm audit
并确保没有漏洞显示来验证它是否有效。提交您的更改,将其推送到GitHub,刷新您的通知/警报,它们应该消失了!
如果您具有npm @ 6或更高版本,则可以使用它npm audit fix
来解决安全问题。
要检查易受攻击的npm软件包,只需使用以下命令:
npm audit
要修复易受攻击的npm软件包,只需使用以下命令即可修复package-lock.json:
npm audit fix
package-lock.json
手动编辑并将易受攻击的软件包版本更新为固定版本,然后使用
npm ci
这将package-lock.json
通过package.json
首先忽略来安装软件包。然后使用
npm audit fix
再次确认是否正确完成。如果这样做没有帮助,请使用其他给定的解决方案。
此处更多信息:
https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable
或这里:https : //docs.npmjs.com/auditing-package-dependencies-for-security-vulnerabilities