linux 社区新增大量无法忍受 MS 各种喂💩的新用户，还得感谢这些“让中国创新走向世界”的中国团队。

@0o0O0o0O0o 没有必要啊，你都可以向客户端推送任意代码了，整个 xz 那样的后门，直接从下载日志拿到肉鸡 ip 连探针都不用。

@taoky 很多 repo 的签名是基于 web of trust 的，只要 compromise 任意一个 key 就等同 compromise 了全部的验证机制。或者你随便安装哪个软件带签名的 repo 需要信任对应开发者的 key 。也有一些包管理器根本就不支持镜像，使用镜像等于使用第三方 repo,root of trust 也是直接从镜像拉。
更理想的分发方式应该是 content addressed ，如 ipfs 。不过使用 p2p 网络那就不止镜像站了，任何 peer 都可以知道你下载了什么包什么版本，并可以以此进行 exploit 。

@dasenlin 你搞错了，这个不是反审查的项目，和 clash 一样认为自己尊重支持审查和法律，只是为看剧/查资料等正经用途设计，他们不认为自己违法，自然没有理由当作违法行为来做。
不过比起代理，这种通过分片等方式构造请求绕过过滤系统的行为（十年前就玩烂的技术），技术上更符合入侵计算机系统。

libreoffice
那些所谓预览插件大概率是调用的 MS office 的 dll,仍然需要你安装 MS office.

镜像应该是 trustless 的，不然就是严重的安全问题。
这甚至无关“不可抗力”，任何一个能接触到镜像服务器的人，或者任何能够 compromise 镜像服务器的人，随便给哪个服务或者库植入个后门顷刻间就能拥有一大堆肉鸡。

@ShadowPower https://www.qualcomm.com/developer/blog/2024/05/upstreaming-linux-kernel-support-for-the-snapdragon-x-elite
这个平台可以说很好，再等两个内核版本就可以买了。但你要想整个设备所有硬件都能驱动的话，还是买支持 linux 的型号比较好。

直接用 bottles https://usebottles.com/ 开箱即用不需要手动进行任何配置。

@tool2dx 分布式不是说你想随便横向扩容就能随便扩的。
多个核心/单元/节点之间的同步/协同/共享/通信都需要架构上的考虑。不是说你把 45 张 10W 的芯片堆到一起就能当 450W 的多核心计算单元了。多个节点之间的开销大于核心的算力的时候你越堆性能越差。
作为一个参考，记得几年前华为鲲鹏的 ARM 服务器几十上百个核心，单核主频也好几 G ，参数看起来非常强劲，然而实际跑起来编译个内核这种并行化非常高的场景，速度还没有 mbp 快。

要不你整 45 台 10W 的设备组集群，是不是就能当 4090 用了？

@EVANGELIONAir 现在正常版本的 Windows 好像不止是内置一些应用把，像什么联网帐号、新闻、copilot 等乱七八糟的垃圾一打开就到处都是。

@BeautifulSoap 所以你偏题了，这里讨论的不是不信任中间件，而是不信任服务端，中间件的攻击面只是服务端不被信任的原因之一。
后端不应该能够得知密码原文因为后端不需要得知密码原文也能实现完整的功能。而前端多进行一步加盐 hash ，也就是不让后端得知不需要的隐私信息的行为，你称之为“没有开发经验，连基本 it 知识和安全思维的没有的逆天”。

据我观察在 v 站发帖需要 NAS 的绝大多数需求都不是 NAS, 而是 seedbox.

你应该把标题改成“服务端能够得知密码原文”。
使用了 https ，其实就已经不是明文而是是加密传输了，在这之上再进行额外多少层的对称还是非对称加密，只要服务端有能力解密得知密码原文，那就都是一回事。
前端进行 hash 的目的只有一个：让后端对密码原文保持 zero knowledge ，其他的安全策略于此是正交的。

@BeautifulSoap 你的论点完全偏题了。无论是密码也好，还是其他信息也罢，只要服务器知道的信息，那就都是一样的，没人关心你要怎么 secure 你的中间件。
They can do whatever they want with your data, and you have no way to know what they did. What else do you expect ?

至于“xxx 所以和明文没区别”这纯属滑坡谬误，假设我在 V2EX 的密码是`mypasswordforv2ex.com`，看到明文之后你能不能猜到我在其他网站的密码？更不用说很多人的密码文本本身就包含个人信息，如姓名拼音/生日等。

@BeautifulSoap 是的，当你提交姓名/住址/银行卡号等个人信息给某个网站的时候，你应该知道你的信息会被任何包括员工在内有权限的人，以任意方式访问/传输/存储/使用/共享，并且你全都无法验证。
这就是为什么要在前端对密码加盐 hash ，使服务端对密码原文保持 zero knowledge 的原因。

@BeautifulSoap 有没有一种可能，我只是一个负责中间件/负载均衡或者其他什么根本不需要接触数据库的组件的开发，我发现某个组件有 bug ，于是就加了几条 log 把部分请求打到日志里。回头我把这些日志收集清洗一下，我就掌握了大量用户的密码了。

或者你认为任何公司的任何员工都做不到/不会做这样的事情？

有没有一种可能，那一万种变相搞到你明文密码的方式，其实都是一种：以后端能够得知原文的方式传输密码。

你如果要只有目的地址为 10.10.10.10 的流量转发给 10.10.10.20 ，那你可以在写规则的时候匹配目的地址。网卡和 ip 没什么关系，从 eth0 进来的目的地址为 10.10.10.10 的包也会被接受，但匹配不到你的规则。

如果你的需求是由 B 向 C 发起请求但是要经过 A ，那你直接在 B 添加静态路由，ip route add <dest_C> via <ip_of_A>，然后在 A 上配置规则决定谁能发给谁。

@FTLIKON
@tsanie
@BeautifulSoap
是的，后端能够得知密码原文是合理的需求，前端加盐 hash 都是逆天。因为这样我可以在哪天倒闭跑路之后把用户的用户名和密码 dump 出来卖给黑客拿去撞库。哦，如果哪个用户跟我 dispute ，我可以直接拿他的用户名密码去其他网站登陆他的帐号给他开盒。

或者你相信任何人都不会做这样的事情？