加载失败
Forgejo（一个开源的 Git 代码托管平台，常被当作自托管 GitHub 替代品）上有篇题为 “Carrot Disclosure” 的文章，作者声称自己发现了安全问题并通过 PR 推动修复。评论区争议不在于是否有普通 bug，而在于这些问题是否真的能被远程利用到 RCE，还是只是本地演示、兼容性争议或小修补。Forgejo 的安全披露和治理文档也被拉进来讨论，因为它要求先按流程私下披露、避免把 zero-day 公开扩散。整场讨论反映了开源项目里常见的拉扯：安全研究者想快速推进修复，维护者则要兼顾测试、兼容性、沟通方式和社区信任。
不少评论认为文章并没有拿出足够强的远程利用证据。被提到的演示更像是在本地实例上跑 python 脚本，甚至默认有主机 shell 或物理访问，这不足以证明真正的远程攻击面。另有评论指出，所谓“严重安全问题”里，一个 PR 只是给 HTML 属性补引号，另一个只是建议停用较弱的 OAuth 方式。大家因此要求先看到能打到远程服务器的实际利用，再把它叫做 RCE。
另一组评论聚焦在维护者要求测试和先讨论变更是否合理。有人认为，对“给 HTML 属性补引号”这种很小的改动要求测试有点过于强硬，但也有人指出作者反复用“本地测过，相信我”来替代测试，这让 PR 可信度更低。针对 OAuth 那个 PR，评论普遍承认方向可能是对的，但它会破坏旧客户端，因此先讨论再合并是正常流程。还有人反问，如果某个项目自己还在依赖那个安全洞，难道就必须为了报告者保留漏洞吗。
评论区也在争论 Forgejo 的披露流程到底是保护用户，还是对安全研究者施压。有人觉得所谓“coordinated disclosure”带着一点 extortion 的味道，反而更喜欢直接把问题摊开说。另一边则强调，安全研究者本来就是专门找漏洞的人，不必对某个项目保持忠诚；关键是尽快让用户免受影响。Forgejo 的治理文档里那句“不同意规则会被公开批评并停止协作”的措辞，也因此被拿来当作过于强硬的例子。
很多评论最终落到了作者本人的语气和姿态上。有人觉得帖子充满敌意，像是在抱怨 Forgejo“很烂”而不是认真协作修复问题；也有人直接把这种公开发文说成是“sore loser”式反应。反过来，维护者一方也并不被视为特别温和，评论里承认双方的沟通都不够有合作精神。整个讨论因此变成了信任危机：社区既怀疑作者的动机，也怀疑维护者处理安全反馈的方式。
RCE（Remote Code Execution，远程代码执行）: 攻击者能在目标系统上执行任意代码的高危漏洞，通常需要明确的远程利用证据。
coordinated disclosure（协调披露）: 先私下通知维护者并留出修复窗口，再公开漏洞细节的安全披露流程。