npm 构建启动前端项目后，自动在桌面创建了 WITH-LOVE-FROM-AMERICA.txt

[simbaCheng]

结论先行 npm 构建前端项目，启动后在桌面自动创建《 WITH-LOVE-FROM-AMERICA.txt 》文件。

过程：

• 在 gitHub 上下载vue-element-admin
• 按照 readme 中进行安装，npm install
• 启动项目 npm run dev
• 系统弹窗需要访问桌面的权限（手抖点的太快，没看清是哪个程序需要权限）
• 桌面出现《 WITH-LOVE-FROM-AMERICA.txt 》文件

观察： 已经有其他网友也出现此情况，桌面突然出现奇怪 txt 文件！ 好像是今天才出现这个情况

怀疑是不是 npm 依赖项被恶意篡改了。 PS：难道是因为最近的国际时局？

非常感谢大家的帮助，已经解决了。

解决方式：

• 按照readme正常install
• 构建结束后，用编辑器全局搜索'peacenotwar'，将其全部删除
• 然后项目的node_models目录下，将'peacenotwar'目录删除
• '项目/node_modules/node-ipc/node-ipc.js'这个文件中引用'peacenotwar'的代码注释掉
• 然后正常启动项目，就可以了。

=======

有朋友提到使用yarn的解决方式，我并没有测试，遇到此问题的其他朋友可以试下。

用 yarn 的话，可以在 package.json 里添加 "resolutions": { "node-ipc": "9.2.1" }

[dcsuibian]

node_modules 搜搜看？

[Love4Taylor]

https://github.com/RIAEvangelist/peacenotwar

[learningman]

查找一下依赖树里哪来的这个包

[caocong]

vue-cli 里有 node-ipc
node-ipc 里有 peacenotwar

[0o0O0o0O0o]

这算供应链攻击吗？

[simbaCheng]

@Love4Taylor 感谢，也在 github 上找了，眼拙没注意

[simbaCheng]

@caocong
感谢，迫不得已当回伸手党（前端新人，平时做后端）；
想问下，怎样把这个依赖去掉？

[weichengwu]

@simbaCheng #7 找到谁依赖它的，然后 fork 一份，把那个依赖换掉😂

[ahwwh1994]

@simbaCheng 用 yarn 的话，可以在 package.json 里添加
"resolutions": {
"node-ipc": "9.2.1"
}

[simbaCheng]

@caocong
再次感谢，自己已经将这个依赖删除了。

[simbaCheng]

@ahwwh1994
感谢帮助

[ChaosesIb]

github.com/RIAEvangelist/node-ipc/issues/233
好恶心的行为，有空的可以去和作者对线

[vacnt7]

刚才我也遇到了，重装依赖过后多了这个 txt ，还以为中毒了

[iseki]

@ChaosesIb 看一遍开源协议，要么 fork 要么忍着

[FrankHB]

@iseki 要么 fork 要么忍是什么义务？开源协议可没本事阻止用户婊 adware （物理），更何况那个项目用的协议根本就没提。

[ChaosesIb]

@iseki #14 正是因为作者有权利那么做，才需要靠跟他沟通来解决。不过现在 issue 里那些直接人身攻击的我觉得就有些过了，开骂的话作者就更难退让了

[iseki]

@ChaosesIb 当然，我针对的是你话中的“对线”，对线可不是沟通～

@FrankHB 如果你认为跑到对应 issue 区域开骂是合理的，请自便

[Trim21]

“美国全方位针对，国产知名开源软件遭美国开发者供应链攻击!”

不过这种行为真的挺恶心的，拉资助好歹还是为了项目本身活下去。

[ChaosesIb]

github.com/RIAEvangelist/node-ipc/issues/233#issuecomment-1068182278
被人挖出真恶意代码了，本机如果是俄或者白俄的 IP 会直接覆写所有文件，有依赖的赶紧换下吧

[gadfly3173]

vuecli 发了新版本，可以直接升级

[v2gg]

PS: 恶意代码受影响的 node-ipc 版本为 v10.1.3 ，已经被作者删除或被 npm 撤下（不知道原因）了，而「 WITH-LOVE-FROM-AMERICA.txt 」文件是由 v11.0.0 版本引入的

[ChaosesIb]

有关恶意代码的 comment 已经都被作者删了，我存了张截图，想看的可以看下
s1.ax1x.com/2022/03/16/bzADMD.png

[ChaosesIb]

github.com/vuejs/vue-cli/issues/7054
后续对话在 vue 这里

[FrankHB]

@iseki 我先前可没评论谁具体应该说什么。我关心的是公众场合行为被容许的边界。
你回复的 @Chaoseslb 原话里说的是“可以”，隐含具体应该怎么做各人自担后果。
相对地，你直接使用了没有后退余地的祈使句，仿佛你表达的意见已经是天经地义的共识，这就串味得厉害了。
我之前都还没对项目的作者进行评论。现在我仍然认为这个案例至此还不值得我去 issue 针对（至少我不是直接受害者），但我倒是可以拿来举例说明为什么我同样会有意见：和你类似，这个项目的作者僭越了道德评价的有效范围，把私货传播到了公共领域。
区别是你也许只是无意间这么做罢了。不过这也不使你显得相对更高尚；相反，该项目作者起码（看上去）知道自己是在做什么，并且在 issue 里明确指出了下游可以消除影响的变通（尽管没事找事让用户凭空受到无妄之灾仍然很欠骂），这点理应比你的直线条惯性思维更应该受到褒扬。
“如果你认为跑到对应 issue 区域开骂是合理的，请自便”实质上回避你被指出的问题，这种跑题行径直觉上容易引起另外的不满。不过更直接的问题是你的“如果”就是妄自揣测，事实上等于没说。
我敦请停止无意义的道德评价。确定不应该在 issue 里做什么事情，ToS 应该够完善了。

[joyqi]

开始以为只是个恶作剧，后来发现这个提交者太邪恶了，如果是俄罗斯的 IP 运行，文件内容就会全部被替换为❤️？太可怕了。

[0o0O0o0O0o]

@0o0O0o0O0o #5 一语成谶

[agdhole]

真恶心，流氓软件行为

[DOLLOR]

看到 WITH-LOVE-FROM-AMERICA 蚌埠住了。
醜國人反戰是我聽過最好笑的笑話。

[SongGG3]

今天被恶心到了，今天新起了个项目，竟然依赖 peacenotwar ，下载失败提示 451 。赶紧指定版本绕过去了。马丹

[43529]

我又想起了前段时间 fakejs 那件事。开源社区的建立来之不易，希望大家都能有一份起码的尊重：作为一个受益者我当然要去尊重作者，去提 bug 贡献代码；但是我也希望作者们能尽量不有意地去向代码里加恶意代码（这是一份请求而非要求，我当然没有要求作者的权力）

[villivateur]

建议大家都去 npm 官方 report spam 吧

[t2jk4000]

唉……又是 npm 啊……

[shadows]

WITH-LOVE-FROM-AMERICA

可以参选年度最佳笑话

[sujin190]

@ChaosesIb 这往桌面这这种东西，显然作者没权利这么干吧，就算我们接受用他的开源软件包他就能想干嘛就干嘛，更不用说清空文件这种叫犯罪，但是不能不能从依赖链中从外部强行下架确实是个坑，毕竟世界总有那么几个傻缺

[murmur]

这个比阿里圣诞更恶劣，看来以后逼人自建仓库，全代码审查了

[murmur]

那个 peacenotwar ，小学生水平，md 该格式化补格式化，空格补空格，一堆 var ，大小写开头混用，就一坨 shi

[Torpedo]

@simbaCheng 这和新人、伸手党没关系。纯粹这个作者坑人

[wangxin13g]

我愿称之为开源恐怖主义

[Danswerme]

@wangxin13g 这六个字太贴切了，总不能去审查每一行开源代码吧。

[dingyx99]

@Danswerme 这么做其实是在破坏人们对开源建立的信任，只能说是这份信任被滥用了

[xiaojun1994]

坐等有人说‘这是开源，这是人家的自由，人家爱干啥干啥’

[MiketsuSmasher]

西方前端娱乐圈又整了个毁灭性花活

[matrix67]

摘录一下 Google 选择引入一个依赖时的决策条款，用于对任何技术做还是不做的评估都有用：

- 是不是有测试，并且使用者可以自己跑起来测试
- 测试是不是通过的
- 谁开发的这个库
- 承诺怎么样的兼容性
- 作者有没有详细地说清楚这个库期望用在什么场景下
- 这项目有多流行
- 我们大概会有多长时间要依赖这个包
- 在历史上这个包搞出来破坏性变更的频率是怎么样的
- 我自己来实现这个依赖的功能的话有多复杂
- 让这个依赖保持版本跟进是不是必要的
- 以后谁来更新依赖的版本
- 这个依赖的版本更新难不难

#94 就《 Software Engineering at Google 》这本书

O'Reilly 官网地址： https://learning.oreilly.com/library/view/software-engineering-at/9781492082781/
原书第 436 页，第 21 章依赖管理

第三条就是，“谁开发的这个库”。看来人品更重要

[cwyalpha]

github.com/zlw9991/node-ipc-dependencies-list/ 受影响的库

[CL]

非常恶劣的行为