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

@bitdepth #79 还有，你是不是以为只有法律负责才是负责？那你这道德感也太低下了。受害者诉求很简单，github 封号+必须公开道歉。到你这成了可以装作没事？天哪，道德低劣至此

CI 不应该接受*任何*不信任的 PR，如果我在 CI 的 build script 里面有引用到 secret variable，恶意 PR 加入一个读取所有的环境变量并发到自己的邮箱的命令，密钥很可能就泄露了。

三点反思：
协议里的免责条款非常有必要
几千个 star 的项目的代码仍然可能没有很好的 review
项目已经有 60 多个 pr，按照这个流程，可能有用户受到之前其他有问题的 pr 的影响，但开发者并没能得到有效反馈，说明收集反馈真的很难

@minami 自己定的規則自己玩去。自己不看代碼怪別人？
某些開發者的能力不見得高在哪裡。
我建議凡在 script 中寫中文的都該死

真是傻逼祸害人

我的观点：
项目拥有者，顶多技术有点瑕疵，但是他 no warranty 。
攻击者上传恶意代码，代码本身也是 no warranty 的，但是对于代码托管平台和发布平台来说是有 warranty 的，用户条款里一定会有不能上传恶意软件，用 key 需要授权什么的说法。所以只有项目拥有者受到了真正的损失，一般也追责追不到，所以会自己用技术来避免这种事情。
收多大钱承担多大责任，和让恶意者付出成本并不矛盾吧。

法律是底线，结果有些人真就把违法当人生底线了。

虽然是 dev 自己的疏忽，但是利用这个疏忽和漏洞，要是造成大损失，至少在国内肯定有罪的

所以，各打五十大板吧。

这个问题似乎没有当初 bumblebee 严重，不过一个是出于主观恶意，一个是失误。利用 edxposed 漏洞的人实在是可耻。

这是明显的主观破坏

也好，使用 canary 本来就是有风险的，这算是给用户上了一课。

https://ex.noerr.eu.org/t/646108

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

我没有贬低这个项目的任何意思，EdXposed 挺好的，就是结合这次事件，感慨一下，开源跟商业化的战争还远远没有结束啊

如果前面的参数值不存在就是另外一个故事了

@bitdepth #84 原来还是种族歧视者啊，失敬失敬

@jy02201949 我不知道你在这时候搬出这话题是什么意思。商业软件里没有经过良好测试然后发布造成给用户毁灭打击的事件并不少

夺损呐！

一个没脑子的用户利用一个开源项目的漏洞向所有人证明了使用 Canary 通道是有风险的，虽然这是一个原本不应存在的风险。普通用户还是用稳定 relase 版吧，如果真的是开发人员也最好拿专门的设备来做测试...

看了底下回复 就..... 觉得好丢脸......

@hakono #96 商业做不好，不代表开源就能做好，一味指责别人商业化的不对，但自身也需要加强自己开源的安全性，我抛出这个话题不是指责谁，只是说这两者之间没有绝对的对错，麻烦带着脑子看别人说的话