npm 构建启动前端项目后，自动在桌面创建了 WITH-LOVE-FROM-AMERICA.txt
simbaCheng 2022-03-15 18:17:19 +08:00 7203 次点击这是一个创建于 1305 天前的主题，其中的信息可能已经有所发展或是发生改变。
结论先行 npm 构建前端项目，启动后在桌面自动创建《 WITH-LOVE-FROM-AMERICA.txt 》文件。
过程：
- 在 gitHub 上下载vue-element-admin
- 按照 readme 中进行安装，
npm install - 启动项目
npm run dev - 系统弹窗需要访问桌面的权限（手抖点的太快，没看清是哪个程序需要权限）
- 桌面出现《 WITH-LOVE-FROM-AMERICA.txt 》文件
观察： 已经有其他网友也出现此情况，桌面突然出现奇怪 txt 文件！ 好像是今天才出现这个情况
怀疑是不是 npm 依赖项被恶意篡改了。 PS：难道是因为最近的国际时局？
第 1 条附言 2022-03-15 19:57:45 +08:00
非常感谢大家的帮助，已经解决了。
解决方式：
- 按照readme正常install
- 构建结束后，用编辑器全局搜索'peacenotwar'，将其全部删除
- 然后项目的node_models目录下，将'peacenotwar'目录删除
- '项目/node_modules/node-ipc/node-ipc.js'这个文件中引用'peacenotwar'的代码注释掉
- 然后正常启动项目，就可以了。
=======
有朋友提到使用yarn的解决方式，我并没有测试，遇到此问题的其他朋友可以试下。
用 yarn 的话，可以在 package.json 里添加 "resolutions": { "node-ipc": "9.2.1" }
 | 1 dcsuibian 2022-03-15 18:33:23 +08:00 via Android node_modules 搜搜看？ |
 | 2 love4taylor PRO |
 | 3 learningman 2022-03-15 19:01:02 +08:00 via Android 查找一下依赖树里哪来的这个包 |
 | 4 caocong 2022-03-15 19:03:59 +08:00 vue-cli 里有 node-ipc node-ipc 里有 peacenotwar |
 | 5 0o0O0o0O0o 2022-03-15 19:29:19 +08:00 via iPhone 这算供应链攻击吗？ |
 | 6 simbaCheng OP @Love4Taylor 感谢，也在 github 上找了，眼拙没注意 |
| 7 simbaCheng OP |
 | 8 weichengwu 2022-03-15 19:37:01 +08:00 @simbaCheng #7 找到谁依赖它的，然后 fork 一份，把那个依赖换掉 |
 | 9 ahwwh1994 2022-03-15 19:46:05 +08:00 |
| 10 simbaCheng OP @caocong 再次感谢，自己已经将这个依赖删除了。 |
| 11 simbaCheng OP @ahwwh1994 感谢帮助 |
 | 12 ChaosesIb 2022-03-15 21:25:51 +08:00 github.com/RIAEvangelist/node-ipc/issues/233 好恶心的行为，有空的可以去和作者对线 |
 | 13 vacnt7 2022-03-15 22:31:11 +08:00 刚才我也遇到了，重装依赖过后多了这个 txt ，还以为中毒了 |
 | 15 FrankHB 2022-03-15 23:22:28 +08:00 @iseki 要么 fork 要么忍是什么义务？开源协议可没本事阻止用户婊 adware （物理），更何况那个项目用的协议根本就没提。 |
| 16 ChaosesIb 2022-03-15 23:53:27 +08:00  1 @iseki #14 正是因为作者有权利那么做，才需要靠跟他沟通来解决。不过现在 issue 里那些直接人身攻击的我觉得就有些过了，开骂的话作者就更难退让了 |
 | 17 iseki 2022-03-16 00:11:45 +08:00 via Android |
 | 18 Trim21 2022-03-16 00:18:29 +08:00 “美国全方位针对，国产知名开源软件遭美国开发者供应链攻击!” 不过这种行为真的挺恶心的，拉资助好歹还是为了项目本身活下去。 |
| 19 ChaosesIb 2022-03-16 00:26:25 +08:00 4 github.com/RIAEvangelist/node-ipc/issues/233#issuecomment-1068182278 被人挖出真恶意代码了，本机如果是俄或者白俄的 IP 会直接覆写所有文件，有依赖的赶紧换下吧 |
 | 1 vuecli 发了新版本，可以直接升级 |
 | 21 v2gg 2022-03-16 01:23:44 +08:00 2 PS: 恶意代码受影响的 node-ipc 版本为 v10.1.3 ，已经被作者删除或被 npm 撤下（不知道原因）了，而「 WITH-LOVE-FROM-AMERICA.txt 」文件是由 v11.0.0 版本引入的 |
| 22 ChaosesIb 2022-03-16 01:40:25 +08:00 有关恶意代码的 comment 已经都被作者删了，我存了张截图，想看的可以看下 s1.ax1x.com/2022/03/16/bzADMD.png |
| 23 ChaosesIb 2022-03-16 01:52:03 +08:00 github.com/vuejs/vue-cli/issues/7054 后续对话在 vue 这里 |
| 24 FrankHB 2022-03-16 02:02:42 +08:00 4 @iseki 我先前可没评论谁具体应该说什么。我关心的是公众场合行为被容许的边界。 你回复的 @Chaoseslb 原话里说的是“可以”，隐含具体应该怎么做各人自担后果。 相对地，你直接使用了没有后退余地的祈使句，仿佛你表达的意见已经是天经地义的共识，这就串味得厉害了。 我之前都还没对项目的作者进行评论。现在我仍然认为这个案例至此还不值得我去 issue 针对（至少我不是直接受害者），但我倒是可以拿来举例说明为什么我同样会有意见：和你类似，这个项目的作者僭越了道德评价的有效范围，把私货传播到了公共领域。 区别是你也许只是无意间这么做罢了。不过这也不使你显得相对更高尚；相反，该项目作者起码（看上去）知道自己是在做什么，并且在 issue 里明确指出了下游可以消除影响的变通（尽管没事找事让用户凭空受到无妄之灾仍然很欠骂），这点理应比你的直线条惯性思维更应该受到褒扬。 “如果你认为跑到对应 issue 区域开骂是合理的，请自便”实质上回避你被指出的问题，这种跑题行径直觉上容易引起另外的不满。不过更直接的问题是你的“如果”就是妄自揣测，事实上等于没说。 我敦请停止无意义的道德评价。确定不应该在 issue 里做什么事情，ToS 应该够完善了。 |
 | 25 joyqi 2022-03-16 02:06:21 +08:00 开始以为只是个恶作剧，后来发现这个提交者太邪恶了，如果是俄罗斯的 IP 运行，文件内容就会全部被替换为？太可怕了。 |
| 26 0o0O0o0O0o 2022-03-16 06:40:35 +08:00 via iPhone @0o0O0o0O0o #5 一语成谶 |
 | 27 agdhole 2022-03-16 10:30:45 +08:00 真恶心，流氓软件行为 |
 | 28 AV1 2022-03-16 11:22:13 +08:00 7 看到 WITH-LOVE-FROM-AMERICA 蚌埠住了。 人反是我最好笑的笑。 |
 | 29 SongGG3 2022-03-16 11:32:02 +08:00 今天被恶心到了，今天新起了个项目，竟然依赖 peacenotwar ，下载失败提示 451 。赶紧指定版本绕过去了。马丹 |
 | 30 43529 2022-03-16 11:47:41 +08:00 via Android 3 我又想起了前段时间 fakejs 那件事。开源社区的建立来之不易，希望大家都能有一份起码的尊重：作为一个受益者我当然要去尊重作者，去提 bug 贡献代码；但是我也希望作者们能尽量不有意地去向代码里加恶意代码（这是一份请求而非要求，我当然没有要求作者的权力） |
 | 31 villivateur 2022-03-16 13:32:51 +08:00 建议大家都去 npm 官方 report spam 吧 |
 | 32 t2jk4000 2022-03-16 13:48:59 +08:00 唉……又是 npm 啊…… |
 | 33 shadows 2022-03-16 14:02:58 +08:00 2 WITH-LOVE-FROM-AMERICA 可以参选年度最佳笑话 |
 | 34 sujin190 2022-03-16 14:04:16 +08:00 via Android @ChaosesIb 这往桌面这这种东西，显然作者没权利这么干吧，就算我们接受用他的开源软件包他就能想干嘛就干嘛，更不用说清空文件这种叫犯罪，但是不能不能从依赖链中从外部强行下架确实是个坑，毕竟世界总有那么几个傻缺 |
 | 35 murmur 2022-03-16 14:09:26 +08:00 这个比阿里圣诞更恶劣，看来以后逼人自建仓库，全代码审查了 |
| 36 murmur 2022-03-16 14:11:29 +08:00 那个 peacenotwar ，小学生水平，md 该格式化补格式化，空格补空格，一堆 var ，大小写开头混用，就一坨 shi |
 | 37 Torpedo 2022-03-16 14:14:37 +08:00 @simbaCheng 这和新人、伸手党没关系。纯粹这个作者坑人 |
 | 38 wangxin13g 2022-03-16 16:25:42 +08:00 7 我愿称之为开源恐怖主义 |
 | 39 Danswerme 2022-03-16 20:16:56 +08:00 via iPhone @wangxin13g 这六个字太贴切了，总不能去审查每一行开源代码吧。 |
 | 41 xiaojun1994 2022-03-16 23:53:07 +08:00 坐等有人说‘这是开源，这是人家的自由，人家爱干啥干啥’ |
 | 42 MiketsuSmasher 2022-03-18 09:53:40 +08:00 西方前端娱乐圈又整了个毁灭性花活 |
 | 43 matrix67 2022-03-18 11:35:19 +08:00 摘录一下 Google 选择引入一个依赖时的决策条款，用于对任何技术做还是不做的评估都有用： - 是不是有测试，并且使用者可以自己跑起来测试 - 测试是不是通过的 - 谁开发的这个库 - 承诺怎么样的兼容性 - 作者有没有详细地说清楚这个库期望用在什么场景下 - 这项目有多流行 - 我们大概会有多长时间要依赖这个包 - 在历史上这个包搞出来破坏性变更的频率是怎么样的 - 我自己来实现这个依赖的功能的话有多复杂 - 让这个依赖保持版本跟进是不是必要的 - 以后谁来更新依赖的版本 - 这个依赖的版本更新难不难 #94 就《 Software Engineering at Google 》这本书 O'Reilly 官网地址： https://learning.oreilly.com/library/view/software-engineering-at/9781492082781/ 原书第 436 页，第 21 章依赖管理 第三条就是，“谁开发的这个库”。看来人品更重要 |
 | 44 cwyalpha 2022-03-19 08:31:10 +08:00 via iPhone |
 | 45 CL 2022-03-21 02:42:37 +08:00 非常恶劣的行为 |
Select Language