在开源代码中 rm -rf 是为了什么？

[runze]

https://github.com/ElderDrivers/EdXposed/blame/7e0d8439e48fea20e51ed997d03ad06a1664ed7c/edxp-core/template_override/customize.sh#L351

[onehero]

这也。。。。太

[czar]

@HughZadora 我给你水里下药，我下了仅是放在那里，你喝了就意味着你要承担风险

[zxcslove]

技术圈法盲真多啊，是个蓝海啊

[zxcslove]

还有皈依者狂热的，真开眼

[ColoThor]

@jy02201949 #100 block +1

[jy02201949]

@ColoThor #105 傻子 block

[leafShimple]

不爽可以不用

[runze]

@leafShimple #107 又一个只看标题的杠精？

[HankAviator]

写博客！上 github ！
要维权！上 github ！
搞破坏！上 github ！
抄（已经烂大街的）教程！上 github ！
凑（ issue&PR ）热闹！上 github ！
青史留名 （ https://github.com/ElderDrivers/EdXposed/pull/542/commits/f40ab4c42cd7c392af877a8ae89fa1e079ad1999 ）！上 github ！

另外现在做事下限都低到只考虑违法不违法了吗，做个正常人不好吗🥴

[sobigfish]

@zsdroid #22 别闹，是同一个人 gpg 签名 key 4AEE18F83AFDEB23 是一样的

[sobigfish]

@sobigfish #110 错了，这个 key 是 GitHub 的 key 😂

[2kCS5c0b0ITXE5k2]

经典受害者有罪论.

[NeilWang]

@mariotaku 我记得 github actions 里是不允许第三方 pr 读取 secret 变量的，其他 CI 应该也有类似的设置吧

[Yvette]

罗老师讲过，这种情况属于间接正犯

[tairan2006]

主要还是维护者把 ci 配置错了…要是别人弄段木马，情况就更严重了

[hakono]

@jy02201949 所以请问你在这个这个时机，这个帖子里，说出 93 楼的用意何在呢？

“项目主手撕太极现场，让大家放弃商业化，拥抱开源，然后……”

这次的事件和项目主与太极的争论有任何关系吗？和开源与商业的争端有任何关系吗？

如果你觉得有关系，那么就是我说过的商业公司也搞出过这种事还不少。

如果你觉得没有，那么我就请问你在有人恶意利用漏洞破坏他人系统的这个话题和帖子下，在这个时机，挑起了一个和话题毫不相关的开源闭源之争，你是何用意？说你其心可诛过不过分？你以为说出这句话后加上后面那段一副理中客的言论我是没理解？但是同志，我想问你，你在说出那话的时候"你人在哪"？

[hakono]

通过这个帖子的确第一次让我理解到程序员群体里到底多少法盲啊。。。。做技术做久了连漏洞和恶意利用漏洞的性质都分不清了
明明就是一次彻底的犯罪行为，受害者维权意识高一点，就可以把这次搞事的人送进监狱，结果居然还有人能洗地。

楼上说得很对啊，这里面真可能是个蓝海。

[rannnn]

没合并的 PR 就推给用户，还怪别人 PR 有问题？什么逻辑

[LokiSharp]

@tairan2006 #115 没有配错 CI 就是这样用的。。。

[dreampet]

@tairan2006 正常 CI 就是对所有推送的分支进行自动编译、集成，自动集成通过才运行合并分支。
这里的问题不是 CI 配置错误，而是推送通道配置错误，不应该将所有分支的自动集成推送的客户端。

[liangch]

主观故意，就差造成重大影响了。不是犯罪是什么。

[jy02201949]

@hakono #116 这能是没关系？代码作者小心一些能注重安全一些，能出这事？上传恶意代码负主要责任，作者这 CI 没管好就能没关系了吗？ App Store 有漏洞被恶意开发者利用，上传了木马应用，导致一批用户数据、财产损失，苹果就不背责了。

再用你的眼睛看好，我说的是作者不要一边大喊别人的应用不安全，一面在自己应用里面犯错，商业跟开源两者的对立关系，你跟 105 楼没脑子没眼睛的，别在跟我争论了

[runze]

@rannnn #117
"没合并的 PR 就推给用户": 这是安全漏洞
"别人 PR 有问题": 这个恶意 PR 是在利用漏洞

[tairan2006]

@LokiSharp
@dreampet 嗯…反正项目维护者是有锅的

[947211232]

那个前端圣诞彩蛋事件，证明人总是重复历史的错误。

[vhwwls]

清空了数据目录或者文件，然后设置了不允许更改其中的内容，应该是拿来用作 Demo 用的，应该没啥恶意，而且人家的文件名也不是说了 customize.sh 了嘛

[longaiwp]

@chinvo 意思就是你这个东西存在明显的错误，明明你可以避免的，但你没有尽到避免的义务，结果有人有意或者无意破坏，造成了用户的损失，你说主要责任是提交 PR 的人？还给我扣一个洗地的帽子？你哪根葱？

[longaiwp]

@batkiz 道理就是这么个道理，但是有些人就是分不清责任主次

[datou]

不折腾手机才是正道

[momocraft]

删文件肯定不是最温和的, 但也远不是最坏的
为了警告或为了玩都说得通

[yanqiyu]

@longaiwp 除了极少数特殊情况, 不作为的责任始终小于作为的责任. 更何况维护推送机制以及 CI/CD 的人并无保护其软件无漏洞的法定义务(GNU, NO WARRANTY), 再加上维护者不一定对此漏洞知情. 开源软件开发者也不应该为了它的非故意的错误(漏洞, 恶心 BUG 等)而负责, 不然一众大型开源项目作者就危险了.

项目维护者在整个事件中只有道义的责任的前提下, 恶意 PR 的作者却有明确的法定责任 (可惜损害金额难以确定, 现在数据损失定罪有困难, 要是他直接一个 dd 命令盖掉了分区表的话那么铁定进局子了), 因为恶意 PR 的作者明知他的行为会导致他人的损失而发布之, 并实际造成了部分用户的损失, 如果相关损失被认定达到入刑标准, 应该按照破坏计算机信息系统罪论处.

NO WARRANTY 条款这个时候不能给恶意 PR 的作者开脱, 因为他的行为是故意损坏用户数据, 按照 GNU 开源的病毒依然是病毒, 被用于破坏目的的情况下法定责任不会减少.

维护者不知情, 无主观恶意, 无破坏行为, 在整个过程中是完全没有责任的, 虽然这个 CI/CD 机制确实把我雷到了, 稍加思考就可以避免, 但是考虑到主要作者还是高一学生, 一心专注功能本身而忘记了安全是有可能的, 也希望这次事件能成为他维护开源软件安全意识的一个教训.

而破坏者知情, 有主观恶意, 实行了破坏行为, 主要责任显然在他.

[realkun]

还是这个人啊，搞上瘾了？

[Love4Taylor]

这种案例建议非法律专业或者不了解法律的人就不要想当然的给任何一方乱定责了。

[Eltrac]

利用项目漏洞提交恶意代码，项目维护者没 merge，所以不能把责任归结到维护者上，只能说这个项目的维护者做事不太谨慎，没注意到安全性问题，也是受害者... 主要责任应该是在这个提 pr 的傻逼身上吧，自己做错了不认账，嘴还硬着呢，毫无诚意地道个歉再叫别人别去烦他。这么多受害者，以及 commit 的证据（还有道歉的帖子），多找些证据能直接出警了吧，破坏计算机系统罪（（（

[lslqtz]

严重性的问题在于 /data/data 下真的有重要数据吗
如果没有的话很难说他造成了严重后果，我觉得他既然主动道歉有可能会说明一些情况
我个人觉得他描述的部分情况是可信的，他确实是看了 #537 （这个更严重，rm -rf /data/*） 后发起的 pr

[lslqtz]

@yanqiyu 这个 pr 的作者的自我描述是知情，但无主观恶意却因自动合并实行了破坏行为

[LokiSharp]

@Eltrac 建议建一个 repo 号召受害者提供损失信息，收集证据

[sliveryukilee]

@longaiwp 主观恶意和客观不作为主次责任分不清？路上看见有人拿刀砍人警察没来得及阻止主要责任在警察？

[ruanimal]

找到正主了

https://qingxu.ga/2020/05/17/%E5%85%B3%E4%BA%8E-EdXposed-%E4%BA%8B%E4%BB%B6%E8%87%B4%E6%AD%89%E4%B9%A6/

[francis5192]

1.没事儿别乱刷 canary 版，beta 版，dev 版等。
2.随时处处备份数据。建议 onedrive 搭配钛备份或 migrate 或 switf backup 。
3.看更新日志。看更新日志。看更新日志。