@yankebupt #37

各大发行版的官方包维护者已经是类似的机制了。要成为官方的包维护者，必须要得到一个甚至多个 sponsor 的支持才能让你加入。

然而这套方案在开发者身上显然不适用，开发者并没有必要非要让某个软件加入到你信任关系里。更直白一点就是，我写的代码你爱用不用，我又没求你用干嘛还要申请入伙。

这次的问题是，各大发行版的包维护者都无条件地信任了上游的代码，导致带后门的包进入了官方仓库，还好在进入 stable 之前被人发现了，从而限制了影响范围。

真要说解决这类问题的方案，估计也就只能增加包维护者的责任了。但实际上，很多包维护者和开源软件作者一样，本来就是志愿工作。以前成为了某个包的维护者，但是现在没太多精力 review 代码，导致后门悄悄溜进了下游。

局域网能正常连的那台机器和你从公网连的机器是同一台吗？

不是同一台的话估计是你没开密码认证，只开了公钥认证，而局域网的机器有公钥，公网机器没公钥。

我更喜欢加密的，因为中间可能有 CDN ，虽然 CDN 是可信中间人，但是多一层保险比没有好。

试试蓝牙？

不如作为一个使用 linux 的程序员，反过来思考为什么不喜欢 windows 。

在 windows 上遇到问题，搜索问题得到的解决方案通常是图形化的步骤，虽然有步骤，但你不知道你在做什么，为什么这么做，你只是重复着别人给你的过程。比如有时候遇到网络问题，无法打开网页之类的，如果在 windows 上，通常会让你点某个界面，然后重置一下网络。至于问题的原因出在哪，为什么这么做，根本一无所知。这种做法对计算机不熟悉的用户来说，是很合适的。但是对于程序员来说，这就让人难受了，作为程序员，你总会想知道是 DNS 问题还是路由问题又或者是其他什么原因导致的。

在 linux 系统上，即使不是每一方面都理解，但整体上你有掌控这台计算机的感觉。而在 windows 上，完全没有这样的感觉。所以我是无论如何都不会觉得所谓的 WSL 能提供任何 Linux 的体验的，因为 windows 无法掌控的那部分过于巨大完全无法忽略。

把身份调换一下，为什么一般用户没法适应 linux 。由于 linux 的用户大都是有基础知识的，并且相较于图形化界面，更愿意使用命令行来解决问题，加上碎片化的各种发行版，你搜索到的解决方案有时候还需要你根据实际情况修改一些参数。一个毫无相关知识的小白很难顺手使用 linux 。

看看 https://matrix.org/cdn-cgi/trace 显示的地址，看看是不是代理的地址。

了解一下 SPF/DKIM/DMARC 这几个机制是怎么工作的，然后手动检查邮件里一些重要的 header ，比如 Return-Path 、DKIM-Signature 、Authentication-Results 。如果这几个 Header 都没有，多半就是伪造的。

除了一些特殊情况，Return-Path 是表示邮件是从哪个邮件服务器发送过来的，这个地址有可能和 From 不是同一个地址。RFC 5321 要求 Return-Path 是最后一跳邮件服务器加上的，也就是你的邮件服务提供商。

一般来说，你的邮件服务提供商会通过 SPF 机制验证 Envelope From ，然后把 Envelope From 的地址填到 Return-Path 里。要注意的是，Envelope From （ SMTP 协议通信时使用的地址）和邮件里的 From header （邮件里的 header ，客户端显示的就是这个地址）是两个东西，因此一封信即使通过 SPF 验证，仅仅能保证 Return-Path 写的是真的，而不能保证 From 是真的。

DKIM-Signature 是这封邮件的签名，里面通常带有哪个域名给这封邮件签过名，来保证邮件的完整性。但也要注意的是，签名域名和 From 也可以是不同的。比如 DKIM-Signature 里签名的域名可以是 outlook.com ，而 From 的地址却是 [email protected] 这种毫不相关的地址，这种情况下，DKIM-Signature 只能保证邮件是由 outlook.com 这个域名签名过的，不能保证 From 就是真的。

SPF/DKIM 和 DMARC 结合一起使用，才能保证 From 的真实性。DMARC 有 Alignment 要求，要求 SPF 和 DKIM 里的域名和 From 对齐。

Authentication-Results 则包含了以上几种机制 spf 、dkim 、dmarc 的验证结果。

以上只是理论上，但实际上，我发现很多邮件服务提供商，都缺少相关的东西。比如 qq 邮件收到的邮件，偶尔就会少 Return-Path 这种重要的 header ，很多学校使用的 Coremail 邮件系统则是没有一封邮件会有 Return-Path 信息。

这封邮件缺少很多重要的 Header ，比如 Return-Path ，而且 Received 这个 Header 里甚至出现了 1.45.182.097 这种地址里 0 开头的 IP 。

感觉是 163 邮箱自己 SPF 检查之类的反垃圾邮件机制不过关导致这封伪造邮件送到了你邮箱里。

@beryl #3 感觉这篇博客一本正经的胡写反而有点搞笑🤣

tk 域名还活着，cf 域名是 pending 状态

@debuggerx
@Yadomin
不是漏洞多少的问题，而是在上游没有的，但在下游有的漏洞。因为这会让人担心下游能否提供更好更安全的用户体验。

很多时候上游不是你可控的，但下游却会根据你的选择是否更安全（比如避免使用这个发行版来避开这个漏洞）。

@yanqiyu 可能是吧，就是希望能找到相对详细的说明。