surface book/Mac 的设计, 中间有个凹槽, 引导用户从中间开盖子

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

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

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

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

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

CI 环境都是容器，并且有明确的权限限制，这次问题是恶意代码进入了编译产物，发布了

现在好几个 Linux 发行版都开始大搞去 Python2 了， 应该快了

@cedoo22 不一定，开源代码的不附加保证并不代表恶意行为可以被开脱。

这灵魂 CI/CD，我觉得恶意 pr 不但可以破坏用户文件，还可以偷走项目的一些 secret

能在你不知情的时候更新的只有可能是来自于应用商店，热更新也改变不了设置里面的版本

有趣，小组作业可以丢给不会用 git 的同学
接下来就是等一个 AI 处理合并冲突了（不是

要我来设计可能会设计成 1,2,4,8,16
还能表达淘宝+拼多多--->1|2
算是被 C/C++给荼毒了吧，见不得额外开销

Verilog 也能, 写很长的二进制可以这么做
0010_1110_0010'b
为了方便阅读

对，贼烦，因为这个卸载了网易云