[讨论] 如何减少 Xz Backdoor 类似问题的发生

[xinbaoCode]

不知道大家有没有看过这篇帖子关于 xz 被恶意开发者注入，导致 linux 发行版有漏洞，可 ssh 连接用户服务器？🐶 https://boehs.org/node/everything-i-know-about-the-xz-backdoor

今天早上思考了一上午这种 xz 开发者恶意投毒的问题如何解决🤔，目前想到一个方案，去中心化存储，下载别人的发布的系统(例如 linux)需要支付一笔 gas(包含保险费)费，如果有恶意投毒，那么可以要到赔偿，我们将所有知名的项目都开发一条链，允许他们发一些 NFT 等，从而可以赔偿。🐶

这些链的的合约有保险触发机制，当大家投票都认为这个项目是恶意的，那么会自动触发这个项目不停生成 NFT 直到赔偿所有用户的损失，虽然这会导致这个项目的贬值，这样就达到了对开发者约束的目的，从而让他们不得不非常谨慎 review 代码🤔，因为这次 xz 攻击，攻击者看项目方去度假了，以及测试时间不充分。🤔

大家觉得如何？🤔

[nrtEBH]

举着锤子看啥都像钉子 你们 b 圈那一套就别硬凑上来吧
开源软件本质上都用爱发电的 开源项目的使用者似乎没有什么特别好的办法杜绝这种情况
对于商业项目的 security admin , 从类似事件里学点经验多做点技术加固手段咯

[gamexg]

项目的钱来源是 用户付的费用,然后赔偿就是这个费用?
那么意味着出问题时赔偿是当时付的使用费?
另外如果项目出现这种恶意 bug,那么这个项目的虚拟币是不是会直接暴跌?
赔付的虚拟币还有意义吗?


我看有说法是投毒人为项目贡献了 2 年代码,才干的投毒.
有这个毅力,我是觉得别指望常规手段能够防的住,
甚至我可以说,有这个能力/精力,即使是商业公司项目一样能做到投毒.
而且可能比开源项目还难以发现问题.

[wweerrgtc]

我用过开源软件 但我没玩过虚拟货币

[0o0O0o0O0o]

推荐阅读：
- https://news.ycombinator.com/item?id=32902938
- https://xkcd.com/2347/

[mikewang]

这次其实还好，不是还没有正式发行版受影响嘛。
开源就是这样的，投毒难免，需要有人检查测试。这次就是 postgres 的一个贡献者在测试过程中发现的。
以 Debian 为例，需要经过 Unstable -> Testing -> Stable
虽然上游已经 release 了，但是还是需要社区在 Testing 阶段做各种测试。
在 Stable 之前拦截住都算可控，不过这次事件确实很恶劣。

[HUZHUANGZHUANG]

小孩子杀人怎么解决？ 解决不了，这是人性问题，不是法律不给力

[forgottencoast]

@cdlnls
结案了，散会。

[hello2090]

你这完全是把基于信任的一个系统改成一个默认人人都是罪犯的系统啊

[levelworm]

大厂不肯出钱，那就没办法了。

[XIVN1987]

解决方法就是别用免费软件，，只用超级大公司巨贵的软件，，这样出了问题可以通过诉讼获得巨额赔偿，，大公司就有巨大的动力保证软件的安全，，

既想免费白嫖，，还想出了问题让人赔偿，，天下哪有这样的好事儿。。

[0o0O0o0O0o]

@levelworm #29 不但不肯出钱。还有巨头集成了开源软件后，用户遇到了问题找客服，客服让用户去找开源项目寻求解决方案。以及 https://pigsty.cc/zh/blog/db/redis-oss/

[zoumouse]

想起了 Kangjie Lu 的文章 https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf

可惜被撤稿了

[OldCarMan]

之前我提过类似的问题，可以参考下：
https://www.v2ex.com/t/920810

不过个人觉得，可能对于大部分人，只是看看相关的库在开源社区的数据表现，以此作为使用的判断条件，有时间和能力当然在使用前 review 一下最好，反之，如果有这个担心，可以先在隔离环境先跑一下，观察存不存在使用异常，或者做好环境监测，尽量做到快速反馈和现场保护。

[cosette]

保险可以一定程度上分散风险造成的损失，但不能规避风险，同样的，也不能阻止风险的扩散，风险本质是不可预知的。

保险公司依然知道需要精巧的设计所需分担的风险的种类，近可能将其限制在一个狭窄的范围，即便如此保险公司依然不可能给自己买保险，遇到意料之外的情况，也只能破产。

而软件工程是风险最具有扩散性的地方，大量的项目互相交错依赖，层层叠叠，你甚至不知道你所依赖的某个项目究竟是谁在提交代码。这里是信任不应该发生的地方，而你能做得也只有信任，你只能相信开发者是有道德感的，同时还有大量的人在做 review ，同样富有道德感，并且有足够的能力和精力发现问题。

没有任何出于理性的方案能够防范这种原初风险，正如没有任何理性的兜底方案能够创造出美好无痛的生活。

[shinyzhu]

看到 gas 就知道你们爱搬出那一套机制来保护数据咯保护所有权咯，扯淡，除了你们炒作的那些空气之外没有任何价值。

[hez2010]

其实今天几乎所有主流的开源软件背后都是大厂在主导，哪怕是 Linux ，大多数代码也都来自各商业厂商为了添加对自己产品的支持才有的所谓的贡献，理想中的自由的开源世界早已经名存实亡了。

[yankebupt]

一定要不靠 review 靠事后处罚么？有点晚，不过也可以讲讲
楼主这个方法，用非链上的方法讲，就是数字签名保证制度

几个人数字签名保证一个新人入伙，他的数字签名才有效，如果这个新人是贼，上溯下挖好几级，数字签名全部作废，这些人签的包全都不再被系统信任，想重新入伙？看谁愿意保你吧。你看 PT 不是在用么，比签名简陋点，什么邀请码……

用旧时的术语讲就是保甲连坐制。后来为什么没了？一个人也能造反，指不定谁造反，造反的诱惑大上天，把项目 NFT 赔干净了也没有在*几乎所有*主流发行版放一个任意 ssh 级别漏洞的利益大，没人愿意互相保了啊。（狗头

[moudy]

这个问题显然是质量控制体系有漏洞。如果有相关的固定场景功能测试，就能在第一时间发现基础功能没 enable 。与其纠结代码是否可信，不如强化项目规则，相关 feature 都得有 negative test

[moudy]

@cosette 再保险了解一下。

[moudy]

@yankebupt 放人进去可以收费了，拼车