微软封禁2个顶级开源账号，开发者：连申诉入口都没有

3月30日，加密工具VeraCrypt的开发者Mounir Idrassi在社交媒体上发了一条消息：他的微软开发者账号被无预警封禁，无法为驱动程序签名。这意味着全球数百万用户可能收不到安全更新。

几乎同一时间，VPN工具WireGuard的开发者Jason Donenfeld也遭遇了同样的命运。两个在网络安全领域举足轻重的开源项目，在同一个月被微软切断了更新通道。

账号消失：没有邮件，没有解释，没有人工客服

Idrassi的遭遇堪称荒诞。他在帖子里写道：「微软没有发送任何邮件或事先警告。我没有收到任何终止解释，他们的消息显示无法申诉。」

他尝试了各种渠道联系微软，得到的只有自动回复和机器人。两周过去，依然没有人类员工与他对接。

被封禁的是IDRIX公司的开发者账号——这家公司不仅维护VeraCrypt，还承接其他客户的项目。Idrassi说：「我无法通过硬件仪表板为VeraCrypt驱动程序或引导加载程序签名。这也阻止我为不同项目的客户签名驱动程序和组件。」

Donenfeld的经历如出一辙。他在Hacker News上描述：「完全没有警告，没有通知。有一天我登录发布更新，结果——账号被暂停了。」

这位WireGuard创始人向The Register透露，事件始于大约两周前。此前他花了数周时间改进WireGuard的用户应用程序和内核驱动程序，包括重建后者的基础设施以通过Windows硬件实验室套件（WHLK）测试——他称之为「一个 neat 的项目」，但「极其痛苦」。

准备工作就绪后，他购买了新的扩展验证（EV）代码签名证书——「这种微软要求本身就像一种 racket」，然后登录合作伙伴门户，准备提交签名的WHLK包和驱动程序进行微软的自动化检查。

结果看到一条消息：账号已停用。

安全悖论：封禁开发者等于制造零日漏洞窗口

Donenfeld的担忧直指核心。如果WireGuard团队发现漏洞，他现在无法签署补丁更新。他在Hacker News上引用了另一位用户的评论：「如果有人是恶意攻击者，现在会是开始利用WireGuard零日漏洞的好时机。希望WireGuard没有零日漏洞。但如果有的话——Jiminy Cricket！」

Jiminy Cricket是《木偶奇遇记》里的 conscience（良心/良知）化身，这里是一种克制的咒骂表达。

这种困境揭示了Windows驱动程序生态的结构性矛盾。微软要求所有内核驱动程序必须经过其签名才能加载，这本身是一种安全机制。但当微软单方面切断开发者的签名能力，且不提供申诉渠道时，这套机制就变成了单点故障。

Idrassi和Donenfeld都不是无名之辈。VeraCrypt是TrueCrypt的继承者，被全球用户用于磁盘加密；WireGuard则是近年来最受欢迎的VPN协议之一，已被Linux内核、Android和iOS采纳。他们的项目影响着数亿设备的安全。

微软的回应姗姗来迟。在事件发酵后，公司表示将改进与开发者的沟通方式，但未解释具体封禁原因，也未说明如何恢复这两位开发者的账号。

昂贵的信任税：EV证书与WHQL的门槛游戏

Donenfeld提到的「racket」值得拆解。微软要求内核驱动程序开发者必须购买EV代码签名证书，这种证书价格通常在数百到上千美元不等，且需要严格的身份验证流程。

但这只是开始。开发者还需要通过WHQL（Windows硬件质量实验室）测试，这是一套复杂的自动化测试套件。Donenfeld花了数周重建基础设施才通过。

整个流程的设计初衷是确保驱动程序质量。问题在于：当开发者完成了所有合规步骤，购买了证书，通过了测试，却在最后一步被平台方无理由封禁，且无法申诉——这套系统的信任基础就出现了裂缝。

Idrassi的账号关联着IDRIX公司的多个项目。封禁不仅影响VeraCrypt，还波及他的商业客户。这种「连坐」机制在平台治理中常见，但缺乏透明度和救济渠道，让合规开发者承担了不成比例的风险。

微软的合作伙伴门户设计也加剧了问题。两位开发者都提到，他们无法联系到人类客服。在关键基础设施的维护中，这种「自动化孤岛」模式正在制造新的系统性风险。

开源与平台的张力：当守门人变成黑箱

这不是微软第一次与开源社区产生摩擦，但时机耐人寻味。近年来，微软大幅拥抱开源——收购GitHub、将Linux子系统融入Windows、贡献Chromium项目。但在驱动程序签名这个关键控制点上，它依然保持着封闭平台的做派。

WireGuard和VeraCrypt的特殊之处在于，它们都是安全工具。用户依赖它们保护数据传输和存储安全。当这些工具的更新渠道被切断，用户实际上暴露在潜在风险中，却浑然不觉。

Donenfeld的零日漏洞担忧并非危言耸听。安全软件的更新机制本身就是攻击目标。2020年，SolarWinds供应链攻击就利用了软件更新渠道。如果攻击者知道某个广泛使用的安全工具无法发布补丁，这个时间窗口的价值会大幅上升。

微软的声明承诺改进沟通，但未触及更深层的问题：驱动程序签名的中心化模式是否可持续？当平台守门人同时扮演裁判和唯一申诉渠道，开发者的救济权利如何保障？

Idrassi仍在等待。Donenfeld也在等待。他们的项目代码是开源的，但让代码在Windows上运行的能力，却掌握在微软手中。

两个账号，两个项目，数百万用户。当平台方的自动化系统决定切断关键安全工具的更新通道，且不提供解释和申诉途径时，谁来判断这是安全机制的正常运转，还是系统故障的误伤？