如何解决我们到底要维护没有安全漏洞的package-lock.json文件?为什么不删除它们或让它们过时呢?
package-lock.json
为上次运行npm update
时安装的所有依赖关系和可传递依赖关系存储一组精确版本。鼓励您将package-lock.json
提交回您的仓库。
我可以找到的package-lock.json
的唯一真实使用者是npm ci
,它准确地再现了package-lock.json
中定义的状态,因此您可以确保在同一CI上运行CI您在最后写入package-lock.json
的开发机上拥有的依赖项。
package-lock.json
似乎用来做的另一件事是产生大量的安全警告。我已经对已提交的package-lock.json
文件进行了Github的Dependabot PR-ing更改,并抱怨说package-lock.json
是它“发现”了无法自动为我修复的其他漏洞的地方。我怀疑这些无法解决的问题是我的或依赖项的package.json
中的问题,由最高版本要求(不包括违规模块的固定版本)引起,但这不是Dependabot所说的:
如果package-lock.json
仅使用npm ci
,那么在那里引用过时且易受攻击的程序包版本怎么会在我的CI系统之外的任何地方创建漏洞?实际安装软件包的人是否不会使用package.json
来解决依赖关系,并因此在所有漏洞可用时自动获得修复(除非我自己有违规的最大版本限制)?我的回购中的这些PR真的只是我和我的所有用户/协作者在我们的计算机上运行npm update
的建议吗?如果是这样,那么Dependabot的作者是谁通过拉取请求来完成此操作的?
如果我从源代码管理中删除了package-lock.json
,这是否可以正确解决package-lock.json
所示的漏洞(因为该文件不再存在,无法诱使某人安装我的依赖项的旧版本)?还是只会使漏洞扫描程序无法扫描我的存储库(即它们是否依靠package-lock.json
而不是自己package.json
来解决依赖关系),并让我不知道何时需要npm update
?
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。