开源软件 node-ipc 投毒事件分析，我们真的在乎过开源软件的安全吗？

3 月 16 日，在程序员圈子里著名的 V2EX 上有人反馈了开源软件 vue-element-admin 在构建前端项目的时候，桌面上会生成一个 txt 文件，名字为《WITH LOVE FROM AMERICA》。

程序员是一个特别有自省意识的一群人，面临这样的异常情况，第一反应是「是不是我那个地方搞错了？」

所以这位工程师在帖子中特别清晰的将异常复现的步骤写了下来，可以看得出，这就是一位前端程序员的正常的项目构建流程，并不是他本人操作不当。

这位工程师提出了造成这种问题的两个可能性：

• 第一，npm 的依赖项被恶意篡改了。
• 第二，软件作者为乌克兰隔空投送来自美国的爱心。

在经过一系列的刨根问底之后，发现造成这种异常的原因是因为 Vue CLI 引用了一个名为 node-ipc 的软件包。它是一个英特尔进程间通信模块的软件包，支持 UNIX、TCP、TLS、UDP 协议，为 Mac、Linux、Windows和神经网络提供高速的套接字需求。

node-ipc 作者为什么要这么做

node-ipc 的作者 Miller 是一位反战人士，他在自己的 Github 仓库中建立了一个 peacenotwar 的软件包来表明自己的反战立场，而这次 node-ipc 的功能异常，也是他反战立场的体现。

这位老哥还尝试过更加狠毒的投毒方式，他通过第三方的网络服务探测用户的 IP 地址，如果你的 IP 在俄罗斯或者白俄罗斯，那么这个软件会用红色小心心覆盖你软件项目所在的当前目录、父级目录和根目录的所有文件。

更具有戏剧性的一点是，Miller 是一位俄罗斯人，至于他为什么会这么做，欢迎你去看一下知乎大佬贺师俊的文章，写的很详细。

简单来说就是，他反对普京的任何政策，所以他去了美国，而他的反战立场，给我的感觉更多是反俄罗斯反普京，而不是希望世界和平。

当然，这哥们在发布这个版本后被其他开发者发现了，他自己觉得这个事情搞的太大了，所以就改成了现在这个在桌面显示《来自美国的爱》的 txt 的温和版本。

后续进展

为了避免 node-ipc 影响使用 Vue 的开发者，VUE CLI 将 node-ipc 版本锁定到了 9.2.1

虽然这个事情过去一个月了，但是并没有消停，在我写稿子的时候去看了一下 node-ipc 的 issue 页，发现一位来自韩国的开发者的关于政治正确的留言，说 Miller 的行为是在使用符号来发动战争，而这种行为是对俄罗斯人和乌克兰人的侮辱。

而他自己也被人肉网暴了，他和他老婆的信息被人肉出来，详细到手机号和居住地。

大家怎么看？

我虽然对国际关系一窍不通，但是基本常识告诉我，反战应该是希望两边都不用战争的方式解决问题。你支持打架两方的任何一方，那不叫反战，那叫拱火。

开源软件投毒很稀奇

其实开源软件投毒本身就是一个挺稀奇的事儿，在我短暂的人生经历中，有听到的开源软件投毒事件包括：

• Ant Design 圣诞节彩蛋事件
• 明尼苏达大学向 Linux Kernel 提包含漏洞的代码事件
• fakerjs 投毒事件
• node-ipc 投毒事件

这些事件各有各的特点.

像 Ant Design 圣诞节彩蛋，那是 Ant Design 团队给程序员的惊喜，结果却获得了适得其反的效果，暴露出来的问题是 Ant Design 项目团队缺乏国际化开源项目的运营经验。宗教本身就是一个复杂的问题，放在一个国际性的开源项目中作为彩蛋显然不不合适。

像明尼苏达大学向 Linux Kernel 提交包含漏洞的代码事件，研究漏洞代码是否会被开源社区发现。明尼苏达大学的这种研究导致了 Linux Kernel 社区将其所有的 IP 地址封禁，从此不能向 Linux Kernel 社区提交任何代码贡献。

而 fakerjs 事件本质是一个被商业公司剽窃创意的个人开发者的打击报复。

我们真的在乎开源软件的安全问题么？

我们作为普通大众真的非常注意开源软件的安全问题吗？

我问了我身边的程序员朋友，问他们在项目开发过程中，在需要引入一款开源软件的时候，如何确保该款开源软件是安全的。

他们说在引入的时候会看源代码。

我说那你怎么确认原代码是安全的？

他说人工智能。

我说这么高级吗？

他补充说就是人工+智能

我说那你怎么确认每一行代码都是安全的

他问我你故意找茬是不是？

……

我说那你除了看代码还会看什么

他说会看看开源许可证。

我的这个朋友曾经在大厂做前端开发，说白了这种工作流程在某种程度上就代表着目前互联网大厂一般的前端开发流程，当然不能以偏概全，欢迎各位在评论区分享贵司在引入一款开源软件时确保软件安全的方法。

我和这位朋友的聊天内容,说白了就是目前前端开发在引入软件包的时候几乎没有什么安全措施.

那么造成这种问题的原因是什么呢？

我个人觉得有三点原因.

「首先，NodeJS 软件生态中有很多小型软件包。」 有多小呢？left-pad 有 17 行代码。根据哈佛大学创新实验室和Linux基金会的一份报告中提供的数据：平均每个 npm 软件包中有 112 行物理代码，47% 的 npm 软件包中只包含 0 或 1 个函数。作为对比，PyPI 中 Python 模块的平均有 2232 行物理代码 。

软件包小就意味着需要花费更多的维护成本和检查成本。

「第二点，NodeJS 模块之间存在互相引用关系。」 你以为的引用关系是井然有序的树形结构，而实际上的引用关系是则是蜘蛛网的关系，在进行安全检查的时候，复杂的依赖关系不但让人头大，也让负责检查的软件头大。毕竟相比于你女朋友在想什么，node_nodules 心思你更难猜的透。这也目前 NodeJS 生态中面临的一个重要的问题，虽然有些解决方案，像 pnpm。但是还有很大的进步空间。

「第三点，是心态上的。」 大家都用的是同一个开源软件，不出漏洞相安无事，出了漏洞大家一个也逃不了，所以大家就开始摆烂了。

那么业界为了保证开源软件的安全正在做哪些努力呢？

关注开源青年，下次文章推送告诉你。