今天是 2026 年 2 月 1 日,一大早,想给我的 Debian 笔记本做个升级,结果一回车,报错了:

命中:1 http://linux.dropbox.com/debian sid InRelease
错误:1 http://linux.dropbox.com/debian sid InRelease
Sub-process /usr/bin/sqv returned an error code (1),
error message is: Signing key on 1C61A2656FB57B7E4DE0F4C1FC918B335044912E is not bound:
No binding signature at time 2026-01-08T18:18:02Z
because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance
because: SHA1 is not considered secure since 2026-02-01T00:00:00Z

上网一搜,原来大家都在骂,顺藤摸瓜找到了这个讨论帖。看完之后,差点没把我气乐了。

那个官方客服回复得那是相当理直气壮,说什么“如果您不符合最低系统要求,出现这类问题是预料之中的”。字里行间,满脸都写着“傲慢”和“不懂行”。

咱们来捋捋这事儿有多“草台班子”。首先这逻辑就硬伤。人家用户 steinarb 说得清清楚楚,是你们 Dropbox 还在用老掉牙的 SHA1 签名,Debian 13 (Trixie) 为了安全已经不认这种不安全的算法了。结果客服倒好,反手甩过来一句“请检查系统要求”。

这就好比你家防盗门换了更高级的锁芯,结果物业跑过来说:“那是你的问题,你应该换回三十年前那种一捅就开的老锁,这样我们发的传单才能塞进来。”听听,这叫人话吗?难道支持过时的 SHA1 算法反而是你们的“最低系统要求”?

再说这大厂的反应速度,更是让人无力吐槽。2026 年 2 月 1 日,这可是全球安全社区早就定好的 SHA1 弃用“死线”。Debian 官方文档里写得明明白白(参考 apt-secure(8)GnuPG 文档),我也不是没给你们时间。堂堂 Dropbox,养了那么多顶级工程师,居然直到死线当天还没更新密钥,留着客服在前线跟用户打太极练推手。

最讽刺的是这剧情的发展:半年前就开始预警了,说早点换锁吧,不然明年 2 月门打不开;18 天前官方还信誓旦旦地宣布“解决”了,说大家放心,锁我们修好了。结果呢?今天 2 月 1 日,门还是死活打不开。我前天刚跑过 dist-upgrade,今天照样过期。

这大概就是典型的“大公司病”吧。傲慢,觉得 Linux 用户是少数派,优先级永远排在最后。再加上严重的层级断层,报 Bug 的是极客,处理 Bug 的是外包,最后回复你的,是只会对着话术脚本念经的客服。中间的信息传递,活脱脱就像是在玩“传声筒”游戏,传到最后,啥也不是。

1 2026-02-04 后记

今天闲着没事,又去他们官网上瞄了一眼。咦,还真有个惊喜,居然悄咪咪地发布了一个新版本,版本号 2026.01.15。所以到头来还是得去官网下载那个 2026.01.15 版本的 deb 包,手动 dpkg -i 安装。装完了一看,好家伙,它把签名算法更新了,这时候再跑 apt dist-upgrade,apt 终于又能连上仓库了,甚至还立马又从仓库里拖下来一个“更新”的版本。

我不禁陷入了沉思。既然你们仓库里其实是有修复好的版本的,为什么不在 2 月 1 日死线之前推送给用户呢?偏偏要等到死线过了,用户的 apt 已经拒绝信任你们的旧签名了,你们才想起来把新包挂上去?这就像是把钥匙锁在了屋里,然后在屋外拼命敲门问为什么打不开。因为你们没在门锁死之前把新钥匙送出来啊!结果现在好了,所谓的“平滑升级”彻底断档,逼着所有用户必须手动去官网下载安装包来“救活” apt 仓库 。这就好比物业终于承认锁坏了,也发了新锁芯,但他们不给你上门换,甚至不通知你,就偷偷把新锁芯扔在物业大厅的角落里。你自己眼神好发现了那是你运气好,发现了还得自己扛回家自己装。对于那些没发现的住户?不好意思,你们就在门外冻着吧。