不知道大家有没有看过这篇帖子关于 xz 被恶意开发者注入，导致 linux 发行版有漏洞，可 ssh 连接用户服务器？? https://boehs.org/node/everything-i-know-about-the-xz-backdoor
今天早上思考了一上午这种 xz 开发者恶意投毒的问题如何解决?，目前想到一个方案，去中心化存储，下载别人的发布的系统(例如 linux)需要支付一笔 gas(包含保险费)费，如果有恶意投毒，那么可以要到赔偿，我们将所有知名的项目都开发一条链，允许他们发一些 NFT 等，从而可以赔偿。?
这些链的的合约有保险触发机制，当大家投票都认为这个项目是恶意的，那么会自动触发这个项目不停生成 NFT 直到赔偿所有用户的损失，虽然这会导致这个项目的贬值，这样就达到了对开发者约束的目的，从而让他们不得不非常谨慎 review 代码?，因为这次 xz 攻击，攻击者看项目方去度假了，以及测试时间不充分。?
大家觉得如何？?
 |
1
lonelykid 37 天前  34
开源项目本来就是大家自备干粮全凭爱好在做，你整这些没人会跟你玩的。
解决方法也只有加强 review ，有任何疑点都要 commit 方解释清楚，最好引入 AI 审查代码。 |
 |
2
yumusb 37 天前 1
简单，不升级即可。
|
 |
3
Dynesshely 37 天前 5
不怎么样, 开源本身是不求回报的行为, 如果通过这种方式来约束开发者, 会极大地降低开发者地开发积极性
换句话说, 人家都免费给你用, 出了事情当然你自己负责, 当然, 大家对该项目的信任会大打折扣 我对这个事件的思考是: 我们应该重新思考开源行业中的信任链, 即我们是否应该完全信任第三方的代码 目前整个开源行业都是依靠信任维系的, 大家信任 Linux 发行版的发行商, 所以使用 Linux 发行版; 发行商信任第三方程序, 所以默认包含并依赖这些程序; 第三方程序库作者信任积极贡献者, 所以允许 TA 成为维护者 这就导致这次攻击几乎是非常成功而且影响极大 但鄙人见识浅薄, 并没有想出更好的办法来避免这类攻击事件的再一次出现 (毕竟就算防住维护者, 也不能保证库作者本人不会写出某些 bug 导致出现可被攻击的漏洞 |
 |
4
yolee599 37 天前 via Android
那干嘛不直接买商业系统呢？这样还有售后服务，出问题也是卖方负责赔偿
|
 |
5
xinbaoCode OP @lonelykid 如果这样呢，开发者成为有人气的项目后，可以铸造自己的链，这样就解决了开源者难赚钱的问题。而且激励了大家。?
|
 |
6
agagega 37 天前 via iPhone 30
不要试图用技术解决人的问题
|
|
7
xinbaoCode OP |
|
8
xinbaoCode OP @xinbaoCode #7
不好意思，刚刚点错了，发布为空 。 1. 对于激励开源，开发者成为有人气的项目后，可以铸造自己的链，这样就解决了开源者难赚钱的问题。而且激励了大家 2. 对于开源行业中的信任链，我们用区块链与信任链绑定，如果大家投票都认为这个项目是恶意的，那么会自动触发这个项目不停生成 NFT 直到赔偿所有用户的损失。这样就更深的加固了信任。 |
 |
9
james122333 37 天前
没想到我刚讲 systemd 就有人爆出来了...
要讲的话就是选技术很重要 首先虽然 xz 压缩率高但效能差本身就不是非常好的选择 过於开放的社区副作用也在此 每次看到有人在嫌社区不够开放我都在想是不是想搞事 好的东西自然会考虑合进去 |
 |
10
yankebupt 37 天前
二楼是指 LTS/LTSC?
不升级，只升级必要的包，打补丁而不是发新版本……一个版本用 10 年…… 两个问题： 一个是编译脚本被 review 忽视掉了。一般人谁看那个啊 一个是测试用二进制数据并不是真的随机数据而且也没有公布生成用的随机/处理算法导致被挂马 综上应该做一次清查用 AI 扫所有的编译脚本有疑虑的提交人工 review ，然后要求所有直接提供的二进制提供来源或生成算法或签名 头疼医头脚痛医脚 |
 |
11
ihuotui 37 天前
0day 没有人发现怎么都没有知道，这些是国家级的行动钱只是数字
|
 |
12
vcn8yjOogEL 37 天前
持续审核配合可复现构建, 审核完毕才会进入核心系统仓库
需要快速迭代的用户程序用 SELinux 等技术套沙箱, 尽可能缩小受击面 |
 |
13
ericFork 37 天前 12
为啥什么都要往链上靠
|
 |
14
GeekGao 37 天前 3
技术无法解决人性问题。
要想防安全风险，就要有个负责任的法律实体来兜底，这也是为啥很多国企和政府采购商业公司的产品而非部署开源代码搞平替。 |
 |
15
Rrrrrr 37 天前
这不是你要考虑的问题
|
 |
16
cdlnls 37 天前 via Android 10
实名制提交代码，实名制开源，再加上公安局备案机制。手动狗头
|
 |
17
onion83 37 天前 23
楼主玩币玩到魔怔了。。
|
 |
18
leonshaw 37 天前 via Android
每个项目一条链，项目崩了还有人给你的链接盘？
|
 |
19
adoal 37 天前 1
这是餐桌上的人玩的游戏。菜单上的化石生死看淡，听天由命吧。
|
 |
20
skies457 37 天前
"如果有恶意投毒，那么可以要到赔偿"
呃。。 |
 |
21
nrtEBH 37 天前 2
举着锤子看啥都像钉子 你们 b 圈那一套就别硬凑上来吧
开源软件本质上都用爱发电的 开源项目的使用者似乎没有什么特别好的办法杜绝这种情况 对于商业项目的 security admin , 从类似事件里学点经验多做点技术加固手段咯 |
 |
22
gamexg 37 天前
项目的钱来源是 用户付的费用,然后赔偿就是这个费用?
那么意味着出问题时赔偿是当时付的使用费? 另外如果项目出现这种恶意 bug,那么这个项目的虚拟币是不是会直接暴跌? 赔付的虚拟币还有意义吗? 我看有说法是投毒人为项目贡献了 2 年代码,才干的投毒. 有这个毅力,我是觉得别指望常规手段能够防的住, 甚至我可以说,有这个能力/精力,即使是商业公司项目一样能做到投毒. 而且可能比开源项目还难以发现问题. |
 |
23
wweerrgtc 37 天前 via iPhone
我用过开源软件 但我没玩过虚拟货币
|
 |
24
0o0O0o0O0o 37 天前 2
|
 |
25
mikewang 37 天前
这次其实还好，不是还没有正式发行版受影响嘛。
开源就是这样的，投毒难免，需要有人检查测试。这次就是 postgres 的一个贡献者在测试过程中发现的。 以 Debian 为例，需要经过 Unstable -> Testing -> Stable 虽然上游已经 release 了，但是还是需要社区在 Testing 阶段做各种测试。 在 Stable 之前拦截住都算可控，不过这次事件确实很恶劣。 |
 |
26
HUZHUANGZHUANG 37 天前 1
小孩子杀人怎么解决？ 解决不了，这是人性问题，不是法律不给力
|
 |
27
forgottencoast 37 天前
@cdlnls
结案了，散会。 |
 |
28
hello2090 37 天前
你这完全是把基于信任的一个系统改成一个默认人人都是罪犯的系统啊
|
 |
29
levelworm 37 天前 via Android
大厂不肯出钱，那就没办法了。
|
 |
30
XIVN1987 37 天前
解决方法就是别用免费软件，，只用超级大公司巨贵的软件，，这样出了问题可以通过诉讼获得巨额赔偿，，大公司就有巨大的动力保证软件的安全，，
既想免费白嫖，，还想出了问题让人赔偿，，天下哪有这样的好事儿。。 |
|
31
0o0O0o0O0o 37 天前 via iPhone
@levelworm #29 不但不肯出钱。还有巨头集成了开源软件后，用户遇到了问题找客服，客服让用户去找开源项目寻求解决方案。以及 https://pigsty.cc/zh/blog/db/redis-oss/
|
 |
32
zoumouse 37 天前
想起了 Kangjie Lu 的文章 https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf
可惜被撤稿了 |
 |
33
OldCarMan 37 天前 1
之前我提过类似的问题，可以参考下：
/t/920810 不过个人觉得，可能对于大部分人，只是看看相关的库在开源社区的数据表现，以此作为使用的判断条件，有时间和能力当然在使用前 review 一下最好，反之，如果有这个担心，可以先在隔离环境先跑一下，观察存不存在使用异常，或者做好环境监测，尽量做到快速反馈和现场保护。 |
 |
34
cosette 37 天前
保险可以一定程度上分散风险造成的损失，但不能规避风险，同样的，也不能阻止风险的扩散，风险本质是不可预知的。
保险公司依然知道需要精巧的设计所需分担的风险的种类，近可能将其限制在一个狭窄的范围，即便如此保险公司依然不可能给自己买保险，遇到意料之外的情况，也只能破产。 而软件工程是风险最具有扩散性的地方，大量的项目互相交错依赖，层层叠叠，你甚至不知道你所依赖的某个项目究竟是谁在提交代码。这里是信任不应该发生的地方，而你能做得也只有信任，你只能相信开发者是有道德感的，同时还有大量的人在做 review ，同样富有道德感，并且有足够的能力和精力发现问题。 没有任何出于理性的方案能够防范这种原初风险，正如没有任何理性的兜底方案能够创造出美好无痛的生活。 |
 |
35
shinyzhu 37 天前 1
看到 gas 就知道你们爱搬出那一套机制来保护数据咯保护所有权咯，扯淡，除了你们炒作的那些空气之外没有任何价值。
|
 |
36
hez2010 37 天前 via Android
其实今天几乎所有主流的开源软件背后都是大厂在主导，哪怕是 Linux ，大多数代码也都来自各商业厂商为了添加对自己产品的支持才有的所谓的贡献，理想中的自由的开源世界早已经名存实亡了。
|
|
37
yankebupt 37 天前
一定要不靠 review 靠事后处罚么？有点晚，不过也可以讲讲
楼主这个方法，用非链上的方法讲，就是数字签名保证制度 几个人数字签名保证一个新人入伙，他的数字签名才有效，如果这个新人是贼，上溯下挖好几级，数字签名全部作废，这些人签的包全都不再被系统信任，想重新入伙？看谁愿意保你吧。你看 PT 不是在用么，比签名简陋点，什么邀请码…… 用旧时的术语讲就是保甲连坐制。后来为什么没了？一个人也能造反，指不定谁造反，造反的诱惑大上天，把项目 NFT 赔干净了也没有在*几乎所有*主流发行版放一个任意 ssh 级别漏洞的利益大，没人愿意互相保了啊。（狗头 |
 |
38
moudy 37 天前
这个问题显然是质量控制体系有漏洞。如果有相关的固定场景功能测试，就能在第一时间发现基础功能没 enable 。与其纠结代码是否可信，不如强化项目规则，相关 feature 都得有 negative test
|
 |
41
mizuhashi 37 天前
https://www.solidot.org/story?sid=77741
Solidot: xz 后门事件凸显了维护者在维护一个基本上不会得到多少外界帮助的开源项目时所面临的挑战，当别有用心的人热情提供帮助，你真的难以分辨对方是真心还是假意。对于 xz 项目原唯一维护者 Lasse Collin 邮件列表交流的分析显示，这位维护者早就筋疲力尽了，他承认如果有 bug 会去修，但开发新功能基本上不可能了。这种情况在 JiaT75(Jia Tan)积极提供帮助后发生了变化，Jia Tan 是少数或者可能是唯一一位愿意“帮助”而不是抱怨开发停滞的人。Lasse Collin 表示考虑让 Jia Tan 扮演更重要的角色，甚至让其接手维护。对于不断抱怨和提出要求的用户，他强调这是一个无薪水的业余项目。在“用户”不断的要求之下，Jia Tan 成为了项目的共同维护者。 |
 |
42
cnt2ex 37 天前 1
@yankebupt #37
各大发行版的官方包维护者已经是类似的机制了。要成为官方的包维护者，必须要得到一个甚至多个 sponsor 的支持才能让你加入。 然而这套方案在开发者身上显然不适用，开发者并没有必要非要让某个软件加入到你信任关系里。更直白一点就是，我写的代码你爱用不用，我又没求你用干嘛还要申请入伙。 这次的问题是，各大发行版的包维护者都无条件地信任了上游的代码，导致带后门的包进入了官方仓库，还好在进入 stable 之前被人发现了，从而限制了影响范围。 真要说解决这类问题的方案，估计也就只能增加包维护者的责任了。但实际上，很多包维护者和开源软件作者一样，本来就是志愿工作。以前成为了某个包的维护者，但是现在没太多精力 review 代码，导致后门悄悄溜进了下游。 |
|
43
levelworm 36 天前
@0o0O0o0O0o 开源社区早就应该这样了。自己不注意，被别人白嫖就是活该，这就是我的态度。
|
 |
44
cr3bit 36 天前 via Android 1
@xinbaoCode 你是不是忘了 openssl/faker.js&color.js 。有人气可未必等于会有人送钱，往往都是实在受不了掀桌子/出事了才会被关注
|
 |
45
Imindzzz 36 天前 via Android 1
区块链骗子别来沾边了
|
 |
46
Lanzhijiang 36 天前 via Android 1
不是很认同开源就是不求回报，免费的，用爱发电的。开源的出发点可能是这个，而且也有这个心理预期，但是开源要持续下去是不可能一直维持这个状态的。开源只是一种软件开发的方法。
B 圈在理想情况下是建立分布式的可信任系统，实际上是符合开源软件供应链的模型的。 |
 |
47
jstony 36 天前
op 没理解一点，人家本来就是恶意投毒，赔偿什么的无所谓啊。
|
 |
48
Dragonphy 36 天前
本身就是一腔热血，愿意被人白嫖，邮电部诗人了
|
 |
49
zbinlin 36 天前
你这是站在使用者的角度看还是站在开发者的角度看？
|
 |
50
shyrock 36 天前
信任问题，目前似乎是无解的。
基于信任的系统极度高效，同时也极度脆弱。 只要遇到一次恶意攻击，整个系统就可能因为负反馈而轰然崩塌。 想一下 911 导致的全球安检系统永久升级和延长旅客安检时间； 以及部分用户恶意售后导致的厂商售后服务缩水和提高门槛。 都是同类的例证。 然而基于人性根本的自私和猜疑链，这理论上无解。 |
 |
51
linhua 36 天前
提交代码 实名制
|
 |
52
Hephaistos 36 天前 via iPhone
@hez2010 大多用爱发电的一年半载就差不多心凉放弃了，人是需要利益来驱动行为的。正好大厂需要名，开发者需要资金
|
 |
53
raptor 36 天前 5
这是炒币炒傻了吧？这明显不是解决问题而是制造问题。
反正我从这个事件上得到的感受是：开源还是很安全的。 毕竟这个投毒人为了下手花了两年半的时间，精心规划了这么一条极端路线才能差一点实现。 如果是闭源软件呢？稍微管理不善，混进个坏人，怕是两天半就得手了…… |
 |
54
ben666 36 天前 1
都从开源项目吸血，没人向开源项目贡献资金，自然就出现人手不足，项目质量只会下降。这就是开源项目本来的弊病，短时间内没有办法。
维护 dperf https://github.com/baidu/dperf/ 深有体会，维护项目主要靠兴趣，花时间，花精力，都是自掏腰包发电，没有稳定的机制来保证项目的稳定发展。 |
 |
55
jfcherng 36 天前
我的某個 php 庫也被在 stackoverflow 上問過安不安全，不過最終我沒上去回答，因為我心裡想的就是 愛用不用 ...
|
 |
56
nothingistrue 36 天前
所有开源协议，第一要素永远都是免责。你搁这搞收费担责，请自己意会各种粗俗的攻击。
|
 |
57
lstz 36 天前 via Android
不是针对楼主，只是想说有些闭源软件别来碰瓷
开源软件审查不到位，也只是偶然情况。但不代表闭源软件就很安全不会有同样的情况出现。 除了微软谷歌这种大公司可能会自己造轮子，绝大部分(甚至 100%)的闭源软件都依赖开源生态。也许你会说人家收费了就会负责到底，但很遗憾的是，闭源软件并不都有完整的 cyber security 的概念和流程 |
 |
58
jim9606 36 天前 via Android
用闭源软件方便啥都不懂的用户获得虚假的安全感，不知道就是不存在。大团队的产品可能愿意公开透明做安全通报也有内部审计内部质控，小团队的你猜会不会否认三连+堵用户口。
我是个人用户，我就是穷，我相信 review 和使用的人越多的开源软件越可靠，因为更好的安全审计我请不起。而且，能看到公开复盘，那不就说明这套审查机制有用嘛。 |
 |
59
mokiki 36 天前 2
@Lanzhijiang 并不需要用去中心区块链这么复杂的东西。
就像上面转载的 solidot 说的那样，问题出在原维护者筋疲力尽，没有钱财激励才会如此。 开发名为 finf 的软件，意为：Freedom is not free 。finf 从文件系统的打开读取等调用以及 Linux 系统的包管理的依赖系统分析软件包的使用情况，定时生成报表。用户根据自我感受自由选择整体价格，并且可以调整 finf 报表出具的分成，把分成报表和总价一起发送给开源基金会。开源基金会负责化零为整和收付款整合。 Make Open Source Great Again ！ |
 |
60
perfectlife 36 天前
多想想人性 ，问题不是机制，而是人性
|
 |
61
iseki 36 天前 via Android 2
改进构建系统，抛弃 M4 Makefile 这种依赖大量难懂的 shell 的方案。
你看 Gradle 虽然更复杂，但是只要你肯看代码，留这种后门是很容易发现的。但 shell 就不行了，一个 expansion 指不定变成什么样，就像 C 的 macro 一样复杂。 |
|
62
xinbaoCode OP @iseki 很好的主意，从编程语言上入手去解决～?
|
|
63
xinbaoCode OP @cr3bit 完全基于热情而无利益，对于开发者是有损的，可能哪天郁闷就删库，所以该如何解决 faker.js 这样的问题呢？?
|
|
64
xinbaoCode OP @OldCarMan 也是个不错的 idea?
|
 |
65
nuk 36 天前
有啥好担心的，这还是源码的后门，二进制的后门都不知道多少，感觉没必要操心，别人用啥我用啥，顶多一起毁灭了。
|
 |
66
boatrain1111 36 天前
对对对，去中心化能解决所有问题，币圈
|
|
67
xinbaoCode OP @ben666 大佬 优秀！
|
|
68
xinbaoCode OP @ericFork 因为想快速解决很多知名开发者没有收益的问题?
|
|
69
xinbaoCode OP @0o0O0o0O0o #24 好文当顶！专业！?
|
|
70
james122333 36 天前 via Android
@iseki
m4 根本就不是 shell 调用命令任何语言工具都做的到 况且你搞错一件事 xz 的构建用的是 cmake 和 autotools 并不是纯 makefile old school makefile 是原始简单的 我倒是希望他们都用 shell 这样我可以少学很多东西 shell 本身也够强 现在太多了 基本上 gradle 这种依赖 java 非 unix 系方案就不要讲了 要选也不会选 gradle 我心裏就有 safe 的方案 不知道为什么总有人整天想把自己工作开发的複杂一套引进 不会其它东西？ |
 |
71
bianhui 35 天前
让你老板融资，扩大规模自己造轮子。
|
 |
72
realJamespond 35 天前
建议实名制，写恶意代码的直接抓起来
|
|
73
Lanzhijiang 34 天前
@mokiki 嗯，刚刚也有类似的想法，就是要分析依赖链，让用户能付费。但我认为开源的结构就是分布式的，采用开源基金会这种中心化的方案可能不合适。但也许眼下，最快能实施且效率高的方案就是这个了。
|
|
74
Lanzhijiang 34 天前
@mokiki 贡献一点 idea ，我认为用户也应该知道自己付出去的钱被用到哪里、有什么成果等。而且 FINF 可以鼓励用户对项目维护、贡献，这些行为也应该可以视为一种"货币"
|
|
75
mokiki 33 天前 1
@Lanzhijiang 赞同，应该由项目管理者提供贡献值比例这样的文件。FINF 根据贡献比例值给出分成报表，用户有最终的调整权力。
现在想到的是像 Linux 内核这样的项目有不同的驱动模块，有些模块可能用户用不到，这时就需要 Linux 内核在自身运行时能给出动态的贡献值。 因为目前没有项目给出贡献比例值，只能靠外部分析。所以第一阶只能靠包管理依赖和正在运行的程序以及文件系统的读取等数据粗略地分析。 |
|
76
xinbaoCode OP |
Select Language